On Wed, Mar 28, 2012 at 5:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Erik Faye-Lund <kusmabite@xxxxxxxxx> 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. > 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. -- 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