AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Smartgit takes took long5/1/2023 ![]() Instead of an obscure series of four to six commands, you simply go to SmartGit's log view and drag the branch markers to where you want them. Take "I accidentally committed something to master that should have been on a brand new branch!" or "I accidentally committed to the wrong branch!" for example. I've been using SmartGit for years and would never go back to the weak sauce of the command line, except for a few odd things that SmartGit doesn't cover (like bisect).Įvery one of the tasks in the article is a simple, straightforward operation in SmartGit. At this point - I never reach for the git cli over gitup (except when cloning a new repo). There are good keyboard shortcuts for everything in gitup so most everything I do doesn't even involve the mouse.Īlso - I'm the kind of person who's always got a set of terminal windows open and definitely uses them often (almost never use Finder, hate taking my hands off the keyboard to reach for the trackpad). Honestly I'm not aware of any common repo tasks that I could more efficiently complete via the command line vs gitup. Once I have the most useful buffers in the right windows, with maybe some reasonable things in the editor navigation stack - changing the editor views at that point comes with a pretty high risk of straying off task - or operating for awhile with the non optimal set of editor windows in front of my face - which at some point I'll realize is dumb/wastes energy and fix - but energy was already spent in the meanwhile. More often than not navigating to most relevant diffs within the ide would actually involve more expensive context switching - for me I'm discovering that it's always somewhat high risk to switch editor contexts - editing text is just such a powerful interface that it tends to easily lead down rabbit holes that take me further from the most relevant info for my current task context. I regularly use three editors when working on different platforms - Xcode, android studio, atom - sometimes it's convenient to use in ide repo-driven features (blame, sometimes historical diffs for a single file), however very often I'm actually more interested in quickly seeing diffs for files other than the one(s) I'm currently editing - so switching to a separate app context that's all about showing repo info tends to be the fastest way to see the relevant info I want side by side without changing away from the editing context I want. ![]() In reality though - i really like having the separate window - it's always there, does one thing and does it well, and it's easy to switch to when I want to take a look at the state of my repo/upstream branches/any dirtiness in my checkout (what exactly have I done recently?). ![]() I imagined that the ideal place for featureful visualization/interaction with the repo would be in the text editor/ide. It wasn't about switching window context away from the terminal but rather switching away from the text editor. I actually used to think similarly before I found git up - although to me Ive taken designers from "never used git" to confidently pushing, pulling, rebasing, and resolving conflicts in less than a day (and most of it after the first 10 minutes without outside help). And with the graphical reflog history rollback view - it's always really easy to back up however far you want if you mess up which gives great confidence as you explore the ui's features. I love this tool - it's honestly one of the best graphical tools I've ever used - rock solid reliable - intuitive, not leaky in the abstractions it represents - and not limited to only "simple" operations. The value of having a graphical depiction of the state that's changing as you invoke operations should not be underestimated. Distributed vc is conceptually nuanced, but not overly complicated - the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that you actually can't easily see from the command line. Its true - and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line.
0 Comments
Read More
Leave a Reply. |