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

[Brandon Williams <bmwill@google.com>]

On 06/03, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> 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.
> 

What you have at 'bw/object-id' matches the changes I made locally
(changing SHA1 to OID) and looks good to me!

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

Sounds like basing it on the original 'master' would work easiest for
you, so I'll continue to do that :)

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

-- 
Brandon Williams