7 ms·

I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actu

by DSMan195276 10y ago

I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. 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.

OJFord 10y ago
> I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. 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.
- jakub_g 10y ago
  I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
  - msarchet 10y ago
    > because you commit a state of the repo that (probably) never existed 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.
    - dwaltrip 10y ago
      What the commenter means is that one might accidentally select some invalid or non-sensical set of partial changes (that won't compile or run) in an effort to create a logical progression between state A, "no feature", and state B, "feature is complete". 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.
    - deleted 10y ago
      [deleted]
  - qznc 10y ago
    Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?
    - manicdee 10y ago
      That's a scenario for branch-then-cherrypick :) Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
      - majewsky 10y ago
        Or just `git rebase -i origin/master` and delete the unnecessary commits without additional branching.
    - pYQAJ6Zm 10y ago
      I have these in my WIP branches. When I’m ready to merge, I squash out some of the smaller commits, and then merge without fast-forward. Reduces noise and keeps a clear history of groups of work, at the expense of very cheap branching and local rebasing operations.
  - OJFord 10y ago
    > and avoid doing more than one thing in the first > place (which would make me want to use `git add -p`) Yep, I still _avoid_ it, but I'm often surprised by something that slips through - e.g. a typo in a comment that I just changed as I read through - but a comment somewhere totally unrelated to the present commit. Maybe your better at avoiding it than I am, but I find it to be easily done.
    - vog 10y ago
      If I do such minor corrections, I usually commit them immediately (via `git add -p` or better `git commit -p`), so they are out of my way.
  - DSMan195276 10y ago
    I understand what you're getting at, but unfortunately I just don't write code that way (And I'm not really sure I know tons of people that do). I always end-up making changes or realizing things halfway into working on something. That said I do understand your point, generally what I do is commit 'logical' parts of my work (Generally using `git add -i` to commit individual chunks), and then when I'm done I checkout each commit to test it compiles on its own. 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.
    - jakub_g 10y ago
      True, sometimes I realize I need to do something half-way when doing something else, then I do a "WIP commit", do another thing and commit that thing (sometimes in a separate branch forked off master), then perhaps reorder commits if needed, and go back to continue working on the previous thing (and amend the "WIP commit" once done) 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).
    - wruza 10y ago
      I usually have a paper and pen at hand, all non-current work goes there — empty circle and todo text. It was my bad habit to patch things immediately at sight. That way I sometimes missed part of context, either of main task, or secondary, depending on complexity of both. 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.
  - slowmovintarget 10y ago
    git status ... Yep, those are the things I changed git add -A git status Yep... git commit ...editing in VI... :wq Mischief managed.
    - gregpardo 10y ago
      Yep that's the way to do it. Assume that you want to add all files (which is usually the case) and then just double check before. This is my practice.
- theptip 10y ago
  I think this is a good practice; it's always easy to let your attention lapse and skim over a line when you're reading the full diff. `git add -p` is nice in that it explicitly requires you to ack each change.
- vog 10y ago
  I recommend using `git commit -p`, which is a shorthand for `git add -p` followed by `git commit`. Then, `git show` before you do `git push`.
halisaurus 10y ago
I use `git add . -p` which allows me to 1) selectively create my commit, and 2) re-read what I've changed to understand it all better. I agree about wholesale adding, but of course there are exceptions when you already did `git diff` Or something. 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.
iLoch 10y ago
I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity. 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.
- pault 10y ago
  > I'm confident the average git CLI user doesn't even know this is possible. Your sibling commenters disagree.
  - wallacoloo 10y ago
    In that case, I'll support his conjecture by admitting that I didn't know that was possible. I'm a pretty average git user, if not actually using it slightly more than my peers (many of whom are only switching from subversion to git within the last 3-4 years). But the rate at which I become more proficient in git is extremely slow - you have to go out of your way to learn more about git most of the time. Maybe a GUI would help in that particular aspect, since I could see unknown options and experiment with them.
    - james-skemp 10y ago
      As someone in pretty much the same boat, try SourceTree or the like. I still use Git from the command line, but it really opened my eyes on what Git can do.
- gfunk911 10y ago
  Agree with this 100%. If you can do everything you want on the CLI then more power to you, but in my experience people using the CLI for diffs/staging include unrelated code in their commits at a much higher rate. I checkout/branch/pull/push in the CLI, and use Git Tower to diff and stage.
jimktrains2 10y ago
I always do `git add -p` and `git commit -e -v` so that I know exactly what's in the commit
TazeTSchnitzel 10y ago
> On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.
- mdahlstrand 10y ago
  Those two A's have completely different meanings though (add all, commit amend), not sure I understand how it's relevant to the parent?
  - majewsky 10y ago
    Grandparent is correct: "git commit -a" is --all, not --amend.
baddox 10y ago
I get a lot of (good-natured) crap from other developers because I always use a graphical tool to view my git diffs and make commits. I realize that there are console tools like git interactive staging that provide similar functionality, but honestly I just like having a dedicated windowed application always running that is always the gateway for my code.
- dozzie 10y ago
  > I get a lot of (good-natured) crap from other developers because I always use a graphical tool to [...] 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).

OJFord 10y ago

> I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. 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.

jakub_g 10y ago
I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
- msarchet 10y ago
  > because you commit a state of the repo that (probably) never existed 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.
  - dwaltrip 10y ago
    What the commenter means is that one might accidentally select some invalid or non-sensical set of partial changes (that won't compile or run) in an effort to create a logical progression between state A, "no feature", and state B, "feature is complete". 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.
  - deleted 10y ago
    [deleted]
- qznc 10y ago
  Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?
  - manicdee 10y ago
    That's a scenario for branch-then-cherrypick :) Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
    - majewsky 10y ago
      Or just `git rebase -i origin/master` and delete the unnecessary commits without additional branching.
  - pYQAJ6Zm 10y ago
    I have these in my WIP branches. When I’m ready to merge, I squash out some of the smaller commits, and then merge without fast-forward. Reduces noise and keeps a clear history of groups of work, at the expense of very cheap branching and local rebasing operations.
- OJFord 10y ago
  > and avoid doing more than one thing in the first > place (which would make me want to use `git add -p`) Yep, I still _avoid_ it, but I'm often surprised by something that slips through - e.g. a typo in a comment that I just changed as I read through - but a comment somewhere totally unrelated to the present commit. Maybe your better at avoiding it than I am, but I find it to be easily done.
  - vog 10y ago
    If I do such minor corrections, I usually commit them immediately (via `git add -p` or better `git commit -p`), so they are out of my way.
- DSMan195276 10y ago
  I understand what you're getting at, but unfortunately I just don't write code that way (And I'm not really sure I know tons of people that do). I always end-up making changes or realizing things halfway into working on something. That said I do understand your point, generally what I do is commit 'logical' parts of my work (Generally using `git add -i` to commit individual chunks), and then when I'm done I checkout each commit to test it compiles on its own. 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.
  - jakub_g 10y ago
    True, sometimes I realize I need to do something half-way when doing something else, then I do a "WIP commit", do another thing and commit that thing (sometimes in a separate branch forked off master), then perhaps reorder commits if needed, and go back to continue working on the previous thing (and amend the "WIP commit" once done) 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).
  - wruza 10y ago
    I usually have a paper and pen at hand, all non-current work goes there — empty circle and todo text. It was my bad habit to patch things immediately at sight. That way I sometimes missed part of context, either of main task, or secondary, depending on complexity of both. 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.
- slowmovintarget 10y ago
  git status ... Yep, those are the things I changed git add -A git status Yep... git commit ...editing in VI... :wq Mischief managed.
  - gregpardo 10y ago
    Yep that's the way to do it. Assume that you want to add all files (which is usually the case) and then just double check before. This is my practice.
theptip 10y ago
I think this is a good practice; it's always easy to let your attention lapse and skim over a line when you're reading the full diff. `git add -p` is nice in that it explicitly requires you to ack each change.
vog 10y ago
I recommend using `git commit -p`, which is a shorthand for `git add -p` followed by `git commit`. Then, `git show` before you do `git push`.

halisaurus 10y ago

I use `git add . -p` which allows me to 1) selectively create my commit, and 2) re-read what I've changed to understand it all better. I agree about wholesale adding, but of course there are exceptions when you already did `git diff` Or something. 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.

iLoch 10y ago

I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity. 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.

pault 10y ago
> I'm confident the average git CLI user doesn't even know this is possible. Your sibling commenters disagree.
- wallacoloo 10y ago
  In that case, I'll support his conjecture by admitting that I didn't know that was possible. I'm a pretty average git user, if not actually using it slightly more than my peers (many of whom are only switching from subversion to git within the last 3-4 years). But the rate at which I become more proficient in git is extremely slow - you have to go out of your way to learn more about git most of the time. Maybe a GUI would help in that particular aspect, since I could see unknown options and experiment with them.
  - james-skemp 10y ago
    As someone in pretty much the same boat, try SourceTree or the like. I still use Git from the command line, but it really opened my eyes on what Git can do.
gfunk911 10y ago
Agree with this 100%. If you can do everything you want on the CLI then more power to you, but in my experience people using the CLI for diffs/staging include unrelated code in their commits at a much higher rate. I checkout/branch/pull/push in the CLI, and use Git Tower to diff and stage.

jimktrains2 10y ago

I always do `git add -p` and `git commit -e -v` so that I know exactly what's in the commit

TazeTSchnitzel 10y ago

> On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.

mdahlstrand 10y ago
Those two A's have completely different meanings though (add all, commit amend), not sure I understand how it's relevant to the parent?
- majewsky 10y ago
  Grandparent is correct: "git commit -a" is --all, not --amend.

baddox 10y ago

I get a lot of (good-natured) crap from other developers because I always use a graphical tool to view my git diffs and make commits. I realize that there are console tools like git interactive staging that provide similar functionality, but honestly I just like having a dedicated windowed application always running that is always the gateway for my code.

dozzie 10y ago
> I get a lot of (good-natured) crap from other developers because I always use a graphical tool to [...] 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).