From: Michael J Gruber <git@drmicha.warpmail.net>
To: Asheesh Laroia <asheesh@asheesh.org>
Cc: git@vger.kernel.org, nathan@creativecommons.org
Subject: Re: Short "git commit $file" syntax fails in the face of a resolved conflict
Date: Wed, 21 Jan 2009 22:35:29 +0100 [thread overview]
Message-ID: <49779521.9040208@drmicha.warpmail.net> (raw)
In-Reply-To: <alpine.DEB.2.00.0901211549070.15860@vellum.laroia.net>
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
next prev parent reply other threads:[~2009-01-21 21:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 21:00 Short "git commit $file" syntax fails in the face of a resolved conflict Asheesh Laroia
2009-01-21 21:35 ` Michael J Gruber [this message]
2009-01-21 21:46 ` Nathan Yergler
2009-01-22 7:28 ` Johannes Sixt
2009-01-23 0:45 ` Nanako Shiraishi
2009-01-23 2:55 ` Asheesh Laroia
2009-01-23 6:15 ` Junio C Hamano
2009-01-23 6:17 ` [PATCH 1/3] Add "partial commit" tests during a conflicted merge Junio C Hamano
2009-01-23 7:09 ` Johannes Sixt
2009-01-23 7:16 ` Junio C Hamano
2009-01-23 7:32 ` Johannes Sixt
2009-01-23 7:39 ` Junio C Hamano
2009-01-23 6:19 ` [PATCH 2/3] builtin-commit: shorten eye-sore overlong lines Junio C Hamano
2009-01-23 6:21 ` [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge Junio C Hamano
2009-01-23 9:51 ` Pieter de Bie
2009-01-23 17:01 ` Junio C Hamano
2009-01-22 9:17 ` Short "git commit $file" syntax fails in the face of a resolved conflict Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49779521.9040208@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=asheesh@asheesh.org \
--cc=git@vger.kernel.org \
--cc=nathan@creativecommons.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.