Brandon Williams <bmwill@xxxxxxxxxx> writes:
> 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.