6 ms·

I mean this is only a problem if your commit work flow is "git add . && git commit". A bad habit, in my opinion.

by alex_smart 4y ago

TowerTall 4y ago
This is what I do. Is there a "better" habit?
- Hamuko 4y ago
  I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.
  - kilroy123 4y ago
    Agreed. This is the only way I ever add anything.
- muhbaasu 4y ago
  Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file. This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.
  - sgammon 4y ago
    came here to say this, git add -p is such a brilliant thing. alias ga="clear ; git add -p" is an alias i always seem to keep
  - fgeiger 4y ago
    For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`" Edit: The flag is -N or --intent-to-add
    - thefilmore 4y ago
      This is cool, wasn't aware of it.
    - j16sdiz 4y ago
      You can use `git add -i` to pick files to add interactivelly
  - nyuszika7h 4y ago
    I use `git add -p` regularly, and it's one of my major pet peeves that it doesn't include new files. I constantly forget to include those in commits because of that.
  - Merad 4y ago
    What type of workflow do you use where you regularly want to commit only some of your changes to a file? I honestly don't think I've ever had that need.
    - gertlex 4y ago
      While some might be more rigorous about working on a commit at a time, a couple other helpful bits are: - Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc. This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things. My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.
    - mdtusz 4y ago
      It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite. Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful. If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.
- martopix 4y ago
  Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get added without you realising it; or you added a breakpoint() that you shouldn't commit, etc. Second, for meaningful commit messages, the commit should include changes that are related to each other. In summary `git add --all` or `git add .` should be used only after a careful inspection of `git status` or `git diff` showed you indeed need all changes, and that they belong to the same commit message.
  - formerly_proven 4y ago
    Just use git-gui
  - throwawaylinux 4y ago
    Logical changes aren't necessarily partitioned by file. Very often I find they are not. I might make a feature or fix or cleanup that is say 10 related changes that each affect some subset of say half a dozen files, often even the same code multiple times. Adding individual files can help partition out some changes, but it's very rare for me, it's much more often I have to go back and manually shuffle sub-file changes around if I didn't get the splits right the first time.
    - naavis 4y ago
      You could use `git add -p` It lets you stage individual changes inside files instead of the whole file.
      - throwawaylinux 4y ago
        Right, I can do those things and sometimes do. Similarly to per-file I generally don't need to because I try to write and commit a logical change at a time. I have no problem with people who do it some other way, it just seems odd to hear people proclaim a particular way to work with git is wrong, because it does not match how they work. Not sure if it's because they can't imagine any other way of working, or they just think all other ways are also wrong.
- alex_smart 4y ago
  Even if you don't want to go the whole "git add -p" route, at the very least: 1. Use "git add <filename>" manually for the files you want to add. 2. Do a "git status" and "git diff --cached" to review what you are about to commit before committing it.
- thefilmore 4y ago
  `git add -u` for changes to existing files, and manually `git add` new files. `git diff --staged` to review what's staged. You can use `git gui` to do all this using a GUI.
- rjmunro 4y ago
  git gui Add hunks, write the message, add more hunks, write more message. Once you are happy commit it, close the window. Don't try to use the CLI only because you are a power user who only uses the command line. If you really can't use the gui (like your on a remote SSH session or something), the non-gui equivalent is git add -p, write your message in another editor, then git commit -F message.txt
  - zelphirkalt 4y ago
    Magit also makes this easy. One of the main features of magit, I think.
- ekimekim 4y ago
  To add to sibling comments which describe various uses of `git add`, I'll also recommend `git commit -a`, which adds all changes from tracked files (but unlike `git add .`, not untracked files) before committing.
- bloopernova 4y ago
  I use fzf in multi-select mode fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add" That lets you interactively choose which files to stage.
- hibbelig 4y ago
  I've started using lazygit and/or tig, these present a UI in the terminal and easily allow staging files. Lazygit also easily allows staging parts of a file; not quite sure about tig.
- hibbelig 4y ago
  What's also useful is to set "commit.verbose" to true; then you get the diff in your editor when composing the commit message. This allows reviewing the diff and you can abort the commit if it's wrong.
ekimekim 4y ago
There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it. This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files). Every single time I find myself with an untracked file, I can either add it because I want it tracked, put it in .gitignore if it's something generated that I want my whole team to ignore, or put it in .git/info/exclude if it's something I've done locally that doesn't fit either of the above.
- alex_smart 4y ago
  >There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it. I would argue that you should decide between explicitly adding it or ignoring it, or deliberately doing neither. >This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files). If you intend to keep untracked files in your directory, choose a PS1 that does not bother you about untracked files. You are losing important information from git status when you exclude untracked files that you are actually working on and not just some random junk your ide generated. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently! I honestly don't understand why the presence of untracked files in your git status is such a bother to you!? Like how exactly does it hurt?
  - Hackbraten 4y ago
    Cognitive clutter. Some people don’t care but it distracts me to no end. I want `git status` to tell me things that matter. I certainly don’t want a meaningful code change sandwiched between an open editor swap file and some for-my-eyes-only temporary design scratch pad. > then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently! Correct, and that’s one of the reasons why the `-f` switch might be a poor fit. I use `-i` instead.
    - alex_smart 4y ago
LinAGKar 4y ago
It also keeps them from polluting git status
- alex_smart 4y ago
  How is the git status "polluted" by reporting untracked files that you don't intend to commit? If anything, I would say that such tricks make git status lie to you. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? Sounds like an easy way to lose work. Why is presence of untracked files in git status bothersome to anyone, especially when that is exactly what they are intentionally doing?
  - properdine 4y ago
    if you do a `git clean -f`, untracked files get deleted. Ignoring files that should stick around helps ensure that command can be used nicely. I've never used `git clean -fdx`, not sure why you would use the `-x` flag at all. (but agreed if you use `-fdx` that doesn't work)
sph 4y ago
Disagree. How is that a bad habit? My workflow is "git status" to check what I've changed, "git add --all" and then "git commit". "git status" needs to be clean. I don't want to see any untracked temporary files. If it's untracked either it needs to be ignored or it's a new source file to add to the index. Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit. I've seen both things from junior developers, that do not know of .gitignore.
- alex_smart 4y ago
  >"git status" needs to be clean. I don't want to see any untracked temporary files. Why do you not want to see any untracked files? What harm does it cause? What is the problem that you are trying to solve? > If it's untracked either it needs to be ignored or it's a new source file to add to the index. Or it is a file that stores your notes or experiments that don't necessarily belong in a branch, do not want to include in your next commit, but you also don't want to be invisible to ".gitignore" aware tools - and increasingly many modern tools are (vscode, ripgrep, emacs's projectile to name a few). >Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit. Neither of those are a factor if you consciously check what you are committing using "git status" and "git diff --cached". This is the habit you want to inculcate in your junior developers, that they should consciously think about the commit they are sending for code review, not that they should meticulously manage and be completely dependent on .gitignore (and i presume you also mean .git/info/exclude - because of course they would also have local files that they don't want to commit but are not worthy of being put into the repo's .gitignore).

I mean this is only a problem if your commit work flow is "git add . && git commit". A bad habit, in my opinion.

TowerTall 4y ago

This is what I do. Is there a "better" habit?

Hamuko 4y ago
I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.
- kilroy123 4y ago
  Agreed. This is the only way I ever add anything.
muhbaasu 4y ago
Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file. This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.
- sgammon 4y ago
  came here to say this, git add -p is such a brilliant thing. alias ga="clear ; git add -p" is an alias i always seem to keep
- fgeiger 4y ago
  For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`" Edit: The flag is -N or --intent-to-add
  - thefilmore 4y ago
    This is cool, wasn't aware of it.
  - j16sdiz 4y ago
    You can use `git add -i` to pick files to add interactivelly
- nyuszika7h 4y ago
  I use `git add -p` regularly, and it's one of my major pet peeves that it doesn't include new files. I constantly forget to include those in commits because of that.
- Merad 4y ago
  What type of workflow do you use where you regularly want to commit only some of your changes to a file? I honestly don't think I've ever had that need.
  - gertlex 4y ago
    While some might be more rigorous about working on a commit at a time, a couple other helpful bits are: - Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc. This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things. My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.
  - mdtusz 4y ago
    It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite. Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful. If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.
martopix 4y ago
Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get added without you realising it; or you added a breakpoint() that you shouldn't commit, etc. Second, for meaningful commit messages, the commit should include changes that are related to each other. In summary `git add --all` or `git add .` should be used only after a careful inspection of `git status` or `git diff` showed you indeed need all changes, and that they belong to the same commit message.
- formerly_proven 4y ago
  Just use git-gui
- throwawaylinux 4y ago
  Logical changes aren't necessarily partitioned by file. Very often I find they are not. I might make a feature or fix or cleanup that is say 10 related changes that each affect some subset of say half a dozen files, often even the same code multiple times. Adding individual files can help partition out some changes, but it's very rare for me, it's much more often I have to go back and manually shuffle sub-file changes around if I didn't get the splits right the first time.
  - naavis 4y ago
    You could use `git add -p` It lets you stage individual changes inside files instead of the whole file.
    - throwawaylinux 4y ago
      Right, I can do those things and sometimes do. Similarly to per-file I generally don't need to because I try to write and commit a logical change at a time. I have no problem with people who do it some other way, it just seems odd to hear people proclaim a particular way to work with git is wrong, because it does not match how they work. Not sure if it's because they can't imagine any other way of working, or they just think all other ways are also wrong.
alex_smart 4y ago
Even if you don't want to go the whole "git add -p" route, at the very least: 1. Use "git add <filename>" manually for the files you want to add. 2. Do a "git status" and "git diff --cached" to review what you are about to commit before committing it.
thefilmore 4y ago
`git add -u` for changes to existing files, and manually `git add` new files. `git diff --staged` to review what's staged. You can use `git gui` to do all this using a GUI.
rjmunro 4y ago
git gui Add hunks, write the message, add more hunks, write more message. Once you are happy commit it, close the window. Don't try to use the CLI only because you are a power user who only uses the command line. If you really can't use the gui (like your on a remote SSH session or something), the non-gui equivalent is git add -p, write your message in another editor, then git commit -F message.txt
- zelphirkalt 4y ago
  Magit also makes this easy. One of the main features of magit, I think.
ekimekim 4y ago
To add to sibling comments which describe various uses of `git add`, I'll also recommend `git commit -a`, which adds all changes from tracked files (but unlike `git add .`, not untracked files) before committing.
bloopernova 4y ago
I use fzf in multi-select mode fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add" That lets you interactively choose which files to stage.
hibbelig 4y ago
I've started using lazygit and/or tig, these present a UI in the terminal and easily allow staging files. Lazygit also easily allows staging parts of a file; not quite sure about tig.
hibbelig 4y ago
What's also useful is to set "commit.verbose" to true; then you get the diff in your editor when composing the commit message. This allows reviewing the diff and you can abort the commit if it's wrong.

ekimekim 4y ago

There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it. This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files). Every single time I find myself with an untracked file, I can either add it because I want it tracked, put it in .gitignore if it's something generated that I want my whole team to ignore, or put it in .git/info/exclude if it's something I've done locally that doesn't fit either of the above.

alex_smart 4y ago
>There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it. I would argue that you should decide between explicitly adding it or ignoring it, or deliberately doing neither. >This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files). If you intend to keep untracked files in your directory, choose a PS1 that does not bother you about untracked files. You are losing important information from git status when you exclude untracked files that you are actually working on and not just some random junk your ide generated. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently! I honestly don't understand why the presence of untracked files in your git status is such a bother to you!? Like how exactly does it hurt?
- Hackbraten 4y ago
  Cognitive clutter. Some people don’t care but it distracts me to no end. I want `git status` to tell me things that matter. I certainly don’t want a meaningful code change sandwiched between an open editor swap file and some for-my-eyes-only temporary design scratch pad. > then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently! Correct, and that’s one of the reasons why the `-f` switch might be a poor fit. I use `-i` instead.
  - alex_smart 4y ago

LinAGKar 4y ago

It also keeps them from polluting git status

alex_smart 4y ago
How is the git status "polluted" by reporting untracked files that you don't intend to commit? If anything, I would say that such tricks make git status lie to you. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? Sounds like an easy way to lose work. Why is presence of untracked files in git status bothersome to anyone, especially when that is exactly what they are intentionally doing?
- properdine 4y ago
  if you do a `git clean -f`, untracked files get deleted. Ignoring files that should stick around helps ensure that command can be used nicely. I've never used `git clean -fdx`, not sure why you would use the `-x` flag at all. (but agreed if you use `-fdx` that doesn't work)

sph 4y ago

Disagree. How is that a bad habit? My workflow is "git status" to check what I've changed, "git add --all" and then "git commit". "git status" needs to be clean. I don't want to see any untracked temporary files. If it's untracked either it needs to be ignored or it's a new source file to add to the index. Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit. I've seen both things from junior developers, that do not know of .gitignore.

alex_smart 4y ago
>"git status" needs to be clean. I don't want to see any untracked temporary files. Why do you not want to see any untracked files? What harm does it cause? What is the problem that you are trying to solve? > If it's untracked either it needs to be ignored or it's a new source file to add to the index. Or it is a file that stores your notes or experiments that don't necessarily belong in a branch, do not want to include in your next commit, but you also don't want to be invisible to ".gitignore" aware tools - and increasingly many modern tools are (vscode, ripgrep, emacs's projectile to name a few). >Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit. Neither of those are a factor if you consciously check what you are committing using "git status" and "git diff --cached". This is the habit you want to inculcate in your junior developers, that they should consciously think about the commit they are sending for code review, not that they should meticulously manage and be completely dependent on .gitignore (and i presume you also mean .git/info/exclude - because of course they would also have local files that they don't want to commit but are not worthy of being put into the repo's .gitignore).