On Thu, May 06, 2010 at 04:45:44PM -0400, Eli Barzilay wrote: > 1. False belief: After you edit and `git add' a file, you will need to > commit it to make the change part of your history. > > Obvious counter example: edit a file and `git add' it; undo the > edit in the file and `git add' again -- you now have nothing to > commit. > > A way that I think will solve this: make `git add' notify you that > the changes that you just added canceled earlier changes and you're > back to a clean state. I don't understand how this is a false belief. You _haven't_ made anything a part of your history. It was already there, and you've done nothing to the history. But I thought your original question started out with a conflicted merge: > mkdir /tmp/r1; cd /tmp/r1; git init > echo foo > file; git add file; git commit -m first > cd /tmp; git clone r1 r2 > cd /tmp/r1; echo abc > file; git commit -m abc file > cd /tmp/r2; echo xyz > file; git commit -m xyz file > git fetch > git merge origin > echo xyz > file > git add file > git status -s In that case you _do_ have to commit, or your history will not contain the merge! Even though you happened to reject the other sides changes, you still want to generate a merge commit showing that in your history you have examined and rejected the other side's changes. The only failing here, if any, is that "git status" does not say "you are in the middle of a merge, and should commit it". > 2. False belief: If you have a completely clear working directory and > index, then there's nothing for you to commit. (At least without > forcing an empty commit.) > > Counter example: run this (simplified example) > > rm -rf /tmp/test; mkdir /tmp/test; cd /tmp/test; git init > echo foo > file; git add file; git commit -m first > git branch a-branch; echo abc > file; git commit -m abc file > git checkout a-branch; echo xyz > file; git commit -m xyz file > git merge master; echo xyz > file; git add file > git status > > That last `status' will happily tell you that "nothing to commit > (working directory clean)" -- but `git commit' *will* commit the > merge. Yeah, probably it should detect the presence of .git/MERGE_HEAD and print a different message. > 3. False belief: if your working directory and your index are dirty, > then there *is* something for you to commit. > > Obvious counter example: edit a file and `git add' it; undo the > edit in the file but *don't* `git add' again -- `git status -s' > will now say: > > MM file > > And now: > > $ git commit . > # On branch master > nothing to commit (working directory clean) > > but the status is still not cleared. Trying to checkout a > different branch gives me the barf. I think you misunderstand how "git commit ." works. It already means "git add . && git commit". So you are actually _removing_ the thing to commit in the first step. Running "git commit" would work. Which is what you suggest: > A way that I think will solve this: make `git commit <path>' add > the paths before committing -- and if `add' says something, it will > say that here and clarify what happened. But this is probably too > much of a change, so alternatively `git commit' would notice that > there was nothing to commit because of this state, and `add' the > right files to clear out the status (after saying something about > it). Except that I guess you want the add process to say "the thing you added is the same as HEAD, so you just reverted the original thing you added". Personally I would find such a notification annoying. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html