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
