Unfortunately, not everyone I work with reads their code (yep, they write-commit-push-and-forget!) which sometimes makes code review a not so nice experience.
Please, please, read your diffs before sending code for review.
I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.
> I also consider `git add -A` to be horrible
> practice. Adding files manually makes you tons more
Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
The fact that `git` makes changing your history around easy make this workflow work fairly well without too much extra overhead to achieve a clean history. I don't disagree that doing it right the first time is really the best way to do it, I just don't find that it really works out that way in practice.
The tricky thing is that when doing several things without committing, sometimes you can end up in a state of the repo where you can't split the work done into nice commits anymore (because you might have modified same part of code multiple times).
Maybe this step-by-step working scheme was influenced by svn that cannot commit partial changes, but it seems a good practice on its own, especially in total refactoring.
> and avoid doing more than one thing in the first
> place (which would make me want to use `git add -p`)
Maybe your better at avoiding it than I am, but I find it to be easily done.
git add -A
Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
If a bug is found, the invalid state of the intermediate commits might make it harder to isolate the change that caused the bug.
That being said, I generally use "git add -p". I've gotten accustomed to trying to have clean commits. Although, sometimes the changes have enough complexity that breaking them up becomes too painful and I end up with a few messy commits. Such is life.
Then, `git show` before you do `git push`.
Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong.
Just use a GUI.
I use SourceTree and often find myself committing individual lines or chunks in my files instead of the whole file. I'm confident the average git CLI user doesn't even know this is possible. I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.
I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.
I'm much more productive using a couple of git commands that I can type in a few seconds, rather than hunting for things in menus and dialogs for ages.
> committing individual lines or chunks in my files instead of the whole file
That's really git 101. I'd expect if you haven't learned to do that via the CLI then maybe you gave up too soon and jumped straight to GUI? `git add -p .` is very easy to use.
Whereas in the CLI, complex operations are difficult but possible; trivial operations are also difficult but possible. :)
Maybe it is of limited use for non-emacs users, but imho it's a fantastic way to use git with a perfect balance between making simple things very easy to do and allowing (almost) anything you can do with the CLI while providing excellent visual feedback.
That said, since I discovered Spacemacs, I'm also enjoying using Magit - the "evil" control scheme for it is great, too.
But yeah, I picked it up after quite some time working in Emacs, and the keybindings feel natural. Perhaps it would be very different for somebody new to Emacs.
1. gitk is the handiest way to undo the occasional accidental commit ("reset index, leave working tree untouched"). yes, i know there's bound to be a CLI way; no, i can't be bothered to look it up and remember it when i have gitk right there and it's not a mainstream use case.
2. git-cola does interactive commits way better than the console interface does.
You mean `git diff`? I'm sure it comes down to a matter of preference, but claiming that using git from a command line slows you down or limits your capabilities only makes sense if you rarely touch a command line (a bit strange for a developer). Plain old git from the command line is functional and actually quite user friendly. Add your own aliases and some kind of git shell and you can fire off a complicated commit as fast as you can sensibly review your diff — all without lifting a finger from the keyboard.
GUI git tools are nice for visualizing feature branches, but for the basic day-to-day workflow the CLI is much more productive.
Surely the exact comment, with the roles of 'CLI' and 'GUI' switched, could be made without anyone necessarily noticing. The anecdotal evidence of what works, and doesn't work, for you should not, I think, be regarded as any particular evidence of what does work for anyone else, much less what can work for everyone else. (As has already been pointed out, your child posts are full of responses from people with other experience.)
There are definitely people out there (I've seen them) that would be better served with a GUI because they really can't be bothered to learn how to use the `git` CLI well (Or just use `git` well in general). But at the same time I'm tons more productive with the CLI vs. GUI.
That's fine, but on the other hand, a typical GUI limits both your capabilities and your productivity.
About the only interface I prefer over git CLI is magit in Emacs. It's unlike your typical GUI, because you don't have to click at anything (keyboard-operated), and it exposes like 99% of git inside a well-thought-out text-based UI that adds just the right amount of interaction and editor integration. Using magit is incredibly efficient, much faster than even using CLI git.
> I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.
If you don't know your way around git, chances are you're going to seriously screw things up via GUI and you'll have no idea what happened or how to fix it. Starting from CLI is a good way to actually learn the tool, which I believe is crucial regardless of what interface you'll eventually be using.
Your sibling commenters disagree.
That said, there's a lot you can't do easily or at all from the GUI. Rebases, surgically reverting a series of commits from a bad merge, re-writing branches, blame, bisect, reviewing the history of a single file, checkout of a specific version of a file from a previous revision; there are a lot of things that I can do easily from the CLI that I don't know how to do or don't care to do from a GUI.
Use the right tool for the job. The GUI is great for common tasks and the CLI is great when you need more power.
the rest is command line git.
With command line completion is pretty good and fast.
Then what happens when they update their GUI? Oh you have to learn it all over again.
That being said, I do on occasion open a GUI if I have to do a complicated merge or something like that but for basic operations why would you need it.
I use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.
Side note: `git status` is not a good means of "knowing what was changed". I see others use it constantly (doing git status -> git add . -> git commit) and it'a sloppy IMO.
One of my colleagues uses PyCharm, while at the same time using Vim somewhere
else (for both Python and not Python). This frustrated me a little every time
he asked me to his terminal in a similar fashion I'm annoyed by somebody using
GUI for the simplest task I could do in a single command. In both cases I try
to keep comments to myself, at least now that I'm a little wiser than I was
five-to-ten years ago.
It takes a lot of patience not to throw such "good-natured crap" if one is
proficient with more-basic-yet-powerful tools. It needs wisdom to recognize
that people do things their own way because it's more effective for them at
the moment, and it's hard to change one's habits on a whim at arbitrary times.
It gives me much better results to call others to my terminal to show them
some interesting thing; they are in much better condition to learn a new Vim
command or CLI tool (this way I successfully exposed two colleagues to AWK,
what I planned for a long time).
...alas, some projects require 1 commit per pr, max...
...then again, if you do a 1:1 commit:change as default the rebase msg is much easier to structure :)
I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
You get the diff in the editor when you write commit message.
Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.