22 ms·

I stopped pretending as if I know what I am doing and instead use visual Git tools, such as SmartGit or the one that comes with IntelliJ. Being a Git "command-l

I stopped pretending as if I know what I am doing and instead use visual Git tools, such as SmartGit or the one that comes with IntelliJ. Being a Git "command-line hero" is for show offs. Porcelain can be just infuriatingly confusing. For example, "Yours and Theirs" can mean the opposite in different contexts. The whole user interface has no common style or theme - it needs a new "visual" layer in order to not drive one up the wall.

al_borland 3y ago
Same. Having the diff all the time is nice, and a visual check at a glance of what is about to happen is very nice, without the need to run a bunch of extra commands. I know enough about the app, and git in general, to get my job done. On the rare occasion I need more, I can look it up. I think I’ve only had to do that once or twice in all the years I’ve been using it.
olvy0 3y ago
Same here. Personally for everyday tasks I always use a visual Git tool, specifically Tortoise Git. For complex tasks, like fixing someone else's mess (or my own), I always start with a visual tool to look at the history and the commits, also look at the reflog (again, in a visual tool, it's much faster for me), understand what the mess is and if I can find anything to salvage, look at some diffs. Then if it's just a commit I need to return to, I do a reset --hard. If I need to combine stuff from several commits, then I usually use the commandline.
barreira 3y ago
These are not mutually exclusive. I share your sentiment in that I only use visual tools for diffs and conflicts and stuff, but I’ve gained a lot from learning about commit objects, reflogs, what a rebase does in the background, interactive rebases, hard/soft resets, etc
- renegade-otter 3y ago
  Oh, I do that as well. "reset --hard origin/trunk" for the win, if you know what I mean. But, will I venture out to stage only a few chunks of local changes into a single commit using the command line interface? Hells to the no.

al_borland 3y ago

Same. Having the diff all the time is nice, and a visual check at a glance of what is about to happen is very nice, without the need to run a bunch of extra commands. I know enough about the app, and git in general, to get my job done. On the rare occasion I need more, I can look it up. I think I’ve only had to do that once or twice in all the years I’ve been using it.

olvy0 3y ago

Same here. Personally for everyday tasks I always use a visual Git tool, specifically Tortoise Git. For complex tasks, like fixing someone else's mess (or my own), I always start with a visual tool to look at the history and the commits, also look at the reflog (again, in a visual tool, it's much faster for me), understand what the mess is and if I can find anything to salvage, look at some diffs. Then if it's just a commit I need to return to, I do a reset --hard. If I need to combine stuff from several commits, then I usually use the commandline.

barreira 3y ago

These are not mutually exclusive. I share your sentiment in that I only use visual tools for diffs and conflicts and stuff, but I’ve gained a lot from learning about commit objects, reflogs, what a rebase does in the background, interactive rebases, hard/soft resets, etc

renegade-otter 3y ago
Oh, I do that as well. "reset --hard origin/trunk" for the win, if you know what I mean. But, will I venture out to stage only a few chunks of local changes into a single commit using the command line interface? Hells to the no.