On Wed, 19 Apr 2006 15:48:22 -0700, Junio C Hamano wrote: > Carl Worth <cworth@xxxxxxxxxx> writes: > > > Meanwhile, I still think it's worth re-considering the original > > problem. > > Maybe you are misunderstanding something in a major way,... It's possible, but it's also possible I'm just failing to express myself clearly. > > After a failed merge, I get a multi-parent diff from "git > > diff". However, after updating the index, I can't find any way to get > > multi-parent diffs anymore. > > ... and that is exactly what this "unmerge to re-populate higher > order stages" does. The multi-parent diff you have been looking > at failed merge _is_ generated by comparing the higher order > stages and your working tree file. But unmerging puts my index back into a not-ready-to-commit state, right? If so, then that's what I don't like from this proposal. > > I'd still like to be able to do that, even when I know that what I > > have in the index is good, and I don't want to undo it. > > You cannot it have both ways. Either you want to have the unmerged > entries (so that you *can* view the combined diff), or you do > not want to have them (then you obviously cannot view the > combined diff between the working tree file and these stages). I don't understand. Why would the entire diff operation have to happen inside the index? As soon as I'm done with the merge commit I can do "git show" and see a multi-parent diff. That doesn't have to muck with my index, does it? By, example, (using the merge from the git tutorial), just before updating the index I get a lovely multi-parent diff: $ git diff diff --cc hello index 06fa6a2,cc44c73..0000000 --- a/hello +++ b/hello @@@ -1,3 -1,3 +1,4 @@@ Hello World It's a new day for git +Play, play, play + Work, work, work then I can update the index: $ git update-index hello and at this point I know I can see a single-parent diff before committing: $ git diff --cached diff --git a/hello b/hello index 06fa6a2..8798bdc 100644 --- a/hello +++ b/hello @@ -1,3 +1,4 @@ Hello World It's a new day for git Play, play, play +Work, work, work But what I want to do instead is at this point get the multi-parent diff. Finally, after I commit, it's easy to get multi-parent diff again: $ git commit -m "Resolved merge conflict" $ PAGER= git show commit 547599946cf5dfb04af804e9d5451beb17662dca Merge: 35e0e9b... 698ac13... Author: Carl Worth <cworth@xxxxxxxxxxxxxxx> Date: Wed Apr 19 16:51:55 2006 -0700 Resolved merge conflict diff --cc hello index 06fa6a2,cc44c73..8798bdc --- a/hello +++ b/hello @@@ -1,3 -1,3 +1,4 @@@ Hello World It's a new day for git +Play, play, play + Work, work, work So why can't I get that same result before committing without changing my index? If the answer is that current implementation doesn't provide for that, (that is, it provides either an in-index multi-diff for files in multiple stages, OR it provides a multi-parent diff for a multi-parent commit object), then that's fine. But that doesn't seem like any fundamental limitation preventing what I'd like to have. Am I making more sense now? Or am I still missing something? -Carl
Attachment:
pgpJVEuyeXDsf.pgp
Description: PGP signature