Re: Summer of Code project ideas due this Friday

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 10, 2011, 22:58 UTC
Message-ID: <7v8vwm37nk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110310214206.GA15828@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Yes, I don't want to see cleanly merged parts. And "--cc" already does
> what I want by not showing them.

Are you sure about that?

What "--cc" would show largely depends on what you have in your working tree. If your two branches fixed the same bug with very different approaches, you may resolve the conflict favouring what one side did while discarding everything the other side did. The file in your work tree might be the same as "git checkout --ours $that_path" after a mergy operation. "diff --cc" won't show anything to you in such a case.

Show 14 quoted lines

> 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.

Actually, the largest problem I see in the above approach is _when_ you perform the first two steps, not the details of the later steps.

The user has complete freedom outside our control between the time the mergy operation leaves conflicts in the index and the time "add -p" is invoked (except obviously the user cannot do any "add" to register the resolution for the whole file to the index, as there won't be any per-hunk resolution recording left to do by "add -p").

And as I repeatedly said, grabbing "--cc file" must be done before the user starts mucking with the file in the working tree for the approach to be any useful.

>> [discussion of how this could be done right]
>
> That description makes sense to me, but is way overkill for my workflow.

Obviously I don't think so. I'd rather consider what it does an absolute minimum (not the part that it stores in an index extension, but the part that the reference it uses to compare against the working tree file is a original, mechanical merge result). By the way, I just relized that an index extension similar to PRSF might be a way to properly give index log similar to the reflog you wanted to have the other day---every time you "git add", you record the previous state of the index entry there, so that it can be replayed in reverse.

Show 5 quoted lines

> Which really I could do with:
>
>   for i in `git diff-files --name-only --diff-filter=U`; do
>     git diff --cc $i
>     echo 'OK?'

As you already know, I disagree the usefulness of this approach (see the "Are you sure about that?" discussion), hence I doubt the usefulness of "have it integrated into the "git add -p" loop".