Re: git add -p and unresolved conflicts

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Mar 28, 2012, 15:33 UTC
Message-ID: <CABPQNSYp7k82mjzNqZmBX+7Dh6R7rgjQ3ZNqikZyM71GshMqqg@mail.gmail.com>
In-Reply-To: <7vbongyd67.fsf@alter.siamese.dyndns.org>

On Wed, Mar 28, 2012 at 5:10 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> I'm running git version 1.7.9.msysgit.0.390.g01fca.dirty, and I've
>> noticed a puzzling behavior with "git add -p" on a conflicted file: it
>> seems to simply spew the diff and exit the process.
>
> Yeah, when I wrote the 'p'atch mode in "add--interactive", I wasn't
> interested at all in letting it be used on a conflicted path, so that is
> not a designed-in behaviour but merely whatever it happens to do.

OK, that's pretty much what I suspected ;)

> So at
> least it should not allow the user to pick a path that has conflicts in
> it.

So, the options are:
 1) Keep the current behavior
 2) Abort with an error immediately if one of the picked paths are in
a conflicted state
 3) Abort with an error when first encounter a path that is in a
conflicted state
 4) Warn and skip any paths that are in a conflicted state
 5) Implement "git add -p" for conflicted files (if we can agree on a behavior)

1) and 3) makes little sense to me. 5) only makes sense if we can
agree on what should have happened.

Show 6 quoted lines

> What the behaviour for people who *do* want to use the patch mode for
> conflicted paths should be is a separate matter.  As I said, I am not
> interested in it, so I wouldn't be the best person to design it.
>
> I mildly suspect nobody would come up with a sane behaviour, but what
> would I know...

Well, I can explain what I expected to happen:

I had stashed away some of my "hacking"-code to rebase a branch to the current master. I was going to stage parts of the stashed changes as a commit on top. However after rebasing, "git stash pop" lead to a conflict. So I manually resolved the conflicts, but only wanted to stage some of the hunks to be committed.

Now, what is obvious in hindsight, is that I should simply have done "git reset" after resolving the conflicts manually. When I do "git add -p", I add hunks to the index. But for a conflicted file, the index isn't in a well-defined state (or, the contents of the file is in a not-yet-defined state).

However, as it happened it made me confused (and a little bit frustrated). I suspect this could confuse other users as well. Perhaps we should implement 1) or 3) and come up with a helpful error/warning message? I don't have a very strong opinion on which one is better, but I suspect 3) is easier.