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