Re: [PATCH 00/33] object id conversion (grep and diff)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 2, 2017, 23:35 UTC
Message-ID: <xmqqpoemx8t4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170602182215.GA57260@google.com>

Brandon Williams <bmwill@google.com> writes:

Show 13 quoted lines

> On 06/02, Junio C Hamano wrote:
>> 
>> I lied.  This also conflicts somewhat with Peff's diff-blob topic.
>> I think I resolved them correctly (there needs evil merges applied
>> to two files when merging this topic), and hopefully can push out
>> the result by the end of the day.
>> 
>> Thanks.
>
> If it ends up being too much of a headache for you to deal with, let me
> know and I can rebase on top of those series.  That way you don't have to
> deal with the conflict resolutions.  Just let me know what you'd like me
> to do.

Sorry, I forgot to push the result out, even though I double checked the conflict resolution I did last night. Now it is in the public repository. I have one squash queued at the right place to update SHA1s to OIDs in the comment Brian pointed out.

If you ever need to rebase this on top of future 'master' that already has js/blame-lib topic, fetching from me and checking the evil merge I did may turn out to be helpful:

 $ git fetch git://github.com/gitster/git refs/merge-fix/bw/object-id
 $ git show FETCH_HEAD

but I can take patches based on the same old 'master'; as long as the evil merge above is correct, that would probably be preferrable, as it makes it easier to compare the two iterations of your series.

Repeating some backstory of "merge-fix" might be beneficial, if a reader is interested. Otherwise the remainder of this message can safely be skipped.

After a topic (i.e. js/blame-lib) moves a lot of code around (i.e. a bulk of what used to be in builtin/blame.c is now in blame.c and some in diff.c), merging a topic that touches places in the code that was moved in-place (i.e. bw/object-id, which updates the code in builtin/blame.c) will leave a conflict that looks like:

    <<<<<<< HEAD
    ... very little that is left after moving
    ... bunch of code out of this file
    ||||||| common
    ... a lot of
    ... stuff before
    ... your change from SHA1 to OID
    ... is here
    =======
    ... a lot of
    ... stuff after
    ... your change from SHA1 to OID
    ... is here
    >>>>>>> theirs

As far as builtin/blame.c is concerned, the resolution for this set of conflicts is just to take the HEAD version, ignoring all of your SHA1-to-OID changes. Once it is resolved, "rerere" can help us remember this resolution to builtin/blame.c

But the ignored changes need to go somewhere else.

What the user who is doing a merge does at this point is to compare what is between ||||||| and ======= (i.e. common ancestor's version) with what is between ======= and >>>>>>> (i.e. their version) to figure out what the branch being merged did. And the user needs to know where the common code went in the version in HEAD.

 $ git log [--no-merges] -p MERGE_HEAD.. -- builtin/blame.c

is helpful to locate the commit that lost the common lines from the file. And "git show" on it will tell us that they mostly went to blame.c while some migrating to diff.c; we found out what you did by comparing "common" and "theirs" in the previous step and we apply these changes to these "new" places.

And that is the diff you see in refs/merge-fix/bw/object-id. The script I use to re-build 'pu' every day (probably I use it three times a day on average) knows about that ref. The script starts from the tip of 'master', and for each topic, (1) run "git merge" into HEAD, (2) take resolution recorded by "rerere" and (3) if merge/fix/$topic exists, cherry-pick it on top to squash into the merge made in (2).

Once I have taught my rerere database and refs/merge-fix/ about this merge, it is not too big a deal to redo the merge to adjust to an updated 'master' or a new interation of your series because of the above mechanism. And that is why I say it is OK for an updated series to be based on the same old 'master'.

Thanks.