Re: [PATCH v3] Give the hunk comment its own color

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2009, 09:00 UTC
Message-ID: <7vvdgstmic.fsf@alter.siamese.dyndns.org>
In-Reply-To: <fabb9a1e0911300009j1574c06cy500dde75fc68662f@mail.gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> writes:

Show 10 quoted lines

> On Mon, Nov 30, 2009 at 08:47, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I'll merge the updated (i.e. rewound and then rebuilt) tip
>> of the topic branch when the topic graduates to the master (hopefully
>> before 1.6.6-rc1), so we won't see the botched one in the end result.
>
> I'm curious how you do this. Do you keep a list of replacements, that
> is "when merging branch foo from next to master, instead merge bar",
> or is it something the original author should remind you of when it's
> time to merge to master?

If you run "git log --oneline --first-parent master..pu", you will notice that there is no "Merge ... into next" at all.

I maintain a private 'jch' branch that merges everything that has been merged so far to 'next' and the branch always builds on top of 'master' whenever 'pu' is pushed out. The tree object recorded by the tip of 'jch' is designed to always match that of 'next'. And 'pu' is built on top of 'jch', instead of 'next', these days.

The Reintegrate script fron 'todo' (recall that I have a checkout of the branch in "Meta/" directory) is used this way:

    ... update 'jch' by merging topics that had new commits
    $ git checkout jch && git merge xx/topic && ...
    ... update the list of topics
    $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh

    ... update 'master' with commits and merges
    $ git checkout master
    $ git am trivially-correct-patch.mbox
    $ git merge yy/topic

    ... update 'next'
    $ git checkout next
    $ git merge master
    ... will merge new topics and topics that had new commits
    $ sh /var/tmp/redo-jch.sh

    ... rebuild 'jch' on top of the updated master
    $ git checkout jch
    $ git reset --hard master
    $ sh /var/tmp/redo-jch.sh

    ... then this shouldn't produce any output
    $ git diff next

This time, what I did _after_ Bert noticed my typo was:

    $ git checkout bw/diff-color-hunk-header
    $ edit diff.c ;# fix my typo
    $ git commit --amend -a
    $ git diff HEAD@{1} >P.diff
    $ git checkout next
    $ git apply --index P.diff
    $ git commit -m 'typofix'

After this, while rebuilding 'jch' branch the next time, Reintegrate script will notice that the bw/diff-color-hunk-header topic has been rebased. I can simply edit that note out in the /var/tmp/redo-jch.sh script and rebuild 'jch' branch---the result will exactly match 'next'.

The end result is that the commit merged in 'next' is not the tip of bw/diff-color-hunk-header anymore, but merging the _current_ tip of that branch together with all the other topics on top of 'master' would produce the desired result without "oops---that was a stupid typo" fixups.