Can you elaborate on why doing -i automatically is a bad idea in this case? [It may really be, I don't pretend to have enough knowledge about git's internals to make a reasoned argument.] This was unexpected behavior for me as I'd always experienced "git add path && git commit" and "git commit path" as being equivalent and so I assumed they would work equivalently in this situation. Nathan On Wed, Jan 21, 2009 at 1:35 PM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Asheesh Laroia venit, vidit, dixit 01/21/09 22:00: >> I have found what seems to be a bug in the short "git commit $file" mode >> of interaction with git. To reproduce it, you can: >> >> 1. Create a repository with some content. >> >> $ (mkdir a ; cd a ; git init ; echo hi > file ; git add file ; git commit -m 'initial commit') >> Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/a/.git/ >> Created initial commit 276d6eb: initial commit >> 1 files changed, 1 insertions(+), 0 deletions(-) >> create mode 100644 file >> >> 2. Clone that repository. >> >> $ git clone a b >> Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/b/.git/ >> >> 3. Create changes in "a" that are not yet cloned into "b". >> >> $ (cd a ; echo ho > file ; git add file ; git commit -m update) >> Created commit 91deff9: update >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> 4. Make changes in "b", the clone. >> >> $ echo lol > file >> $ git add file ; git commit -m 'Some changes' >> Created commit 5d74b5b: Some changes >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> 5. Fetch and merge (AKA pull) from the first repo. >> >> $ git pull >> remote: Counting objects: 5, done. >> remote: Total 3 (delta 0), reused 0 (delta 0) >> Unpacking objects: 100% (3/3), done. >> From /tmp/playground.2009-01-21.w15613/a/ >> 276d6eb..91deff9 master -> origin/master >> Auto-merged file >> CONFLICT (content): Merge conflict in file >> Automatic merge failed; fix conflicts and then commit the result. >> >> 6. Resolve the conflict (in our case, by discarding the changes in the "b" >> clone). >> >> $ echo ho > file >> >> 7. Commit the resolved conflict. >> >> NOTE: The normal way to do step 6 is to "git add file ; git commit -m >> yay". But I will now try to use the "git commit file" shorthand: >> >> $ git commit file -m 'Resolved conflict' >> fatal: cannot do a partial commit during a merge. >> >> 8. Declare a bug. >> >> I believe that the "git commit file" command issued in step 6 should have >> worked as well as the "git add file ; git commit" that us old-time git >> users do. >> >> 9. Discuss on the git list. >> >> Do y'all agree that the git behavior is strange and unnecessarily >> user-impeding here? >> >> Cheers! >> >> -- Asheesh. >> >> P.S. I'm not the one who ran into the bad behavior here; Nathan (CC:d) is >> the one who did. You don't have to keep him CC:d, though. >> > > You want git commit -i: > > -i, --include > Before making a commit out of staged contents so far, stage > the contents of paths given on the command line as well. > This is usually not what you want unless you are concluding a > conflicted merge. > > Without -i, git commit path ignores the index, which would be bad in the > middle of a merge, which is why git refuses to do so. You may argue for > git commit to use -i automatically here, but I don't think it's a good idea. > > So, out of > 1) git add path && git commit > 2) git commit path > 3) git commit -i path > only 1) and 3) are always equivalent. > > Michael > -- 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
