On Thu, Mar 10, 2011 at 12:54:29PM -0800, Junio C Hamano wrote:
> Forgetting for now the implementation, I _think_ what you would want is
> for "git add -p" to notice that you are resolving conflicts, and do not
> bother you about cleanly merged parts (I take it is a given that you would
> always want to add them to the index without even inspecting when running
> "add -p"), and make the per-hunk selection loop ask only about the parts
> that originally had conflicts.
Yes, I don't want to see cleanly merged parts. And "--cc" already does
what I want by not showing them. But of course they still need to be
added to the index.
So my thinking was more along the lines of:
1. Get "git diff HEAD file" and store its hunks.
2. Get "git diff --cc file" and stores its hunks.
3. For each hunk in (1), if it does not have an analagous hunk in (2),
mark it for staging without asking the user.
4. For the remaining hunks in (1), show the user the analagous --cc
hunk from (2), and mark the hunk from (1) for staging if requested.
5. Create the final patch from the marked hunks, apply it to
HEAD:file, and put that in the index.
There are two issues (and I think you know this, but it took me
reasoning out why this wouldn't work to quite understand what you were
saying in your email, so I'll elaborate here for the benefit of other
readers):
a. Step (3) glosses over the definition of "analagous hunk". In simple
cases the hunk headers match up (i.e., they start at the same
offsets). But the --cc diff is actually a diff against the merge
base, and the diff in step (1) is against HEAD. So actually we
would want step (1) and (5) to deal not with the file in HEAD, but
the file in the merge-base.
Or we can use "-c" in the first place, which gives us interesting
and uninteresting parts, and then suppress the uninteresting ones.
b. You can't stage part of a resolution. This is the "adding a path
collapses stages to #0" that you mentioned. So either you need an
index extension, or you need to make it all-or-nothing.
> [discussion of how this could be done right]
That description makes sense to me, but is way overkill for my workflow.
I think at its simplest, what I would like is to be shown the entire
--cc diff, have it say "do you want this and all of the cleanly merged
bits added?" and then either stage the whole thing or not.
Which really I could do with:
for i in `git diff-files --name-only --diff-filter=U`; do
git diff --cc $i
echo 'OK?'
read r
test "$r" = y && git add $i
done
It would just be a little nicer to have it integrated into the "git add
-p" loop.
Even though it is obviously a less featureful solution than what you
proposed, I am tempted to implement it anyway because the current
behavior is so bad (it shows the diff but doesn't consider it a
selectable hunk at all, so it just skips it, exiting immediately if
there are no other files).
And then if somebody wants to spend time allowing partial resolution
selection, it would be a nice improvement on top of that.
-Peff
--
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