From: Johan Herland <johan@herland.net>
Date: Wed, 17 Dec 2008 09:15:45 GMT
Subject: Re: rebasing commits that have notes, was Re: Git Notes idea.
Message-ID: <200812171015.45303.johan@herland.net>
In-Reply-To: <alpine.DEB.1.00.0812170110160.14632@racer>

On Wednesday 17 December 2008, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Dec 2008, Jeff King wrote:
> >   Some discussion of the interaction of notes and rebase:
> >   http://thread.gmane.org/gmane.comp.version-control.git/100533
>
> Oh, I misinterpreted that label... of course you can track rebases in
> notes, but some issue that we did not look into yet (I think) is the
> issue that you can cherry-pick and rebase commits and lose notes in the
> process.
>
> It seems that the notes idea is not that unintrusive as I thought...

So we have two issues here:

1. Using notes to annotate the rebase/cherry-pick action itself.

2. Preserving (or at least giving the user the option of preserving) notes 
across a rebase/cherry-pick.


I think issue #1 has already been discussed, and is largely resolved: People 
can do this if they want to; it probably only makes sense when 
rebasing/cherry-picking public branches; etc... AFAICS there are no 
remaining problems here that needs an intrusive solution (see below for one 
such unintrusive alternative).

Issue #2, however, is a little more involved. We can discuss the merits of 
wanting to preserve notes across a rebase/cherry-pick itself; e.g. when it 
makes sense to preserve notes, and when it doesn't make sense, but I think 
this is orthogonal to the issue of HOW to preserve them, so instead of 
focusing on WHY, I'll focus on HOW:

If notes are named according to the "refs/notes:<first byte in hex>/<rest of 
bytes>/<referenced object SHA-1>" scheme (and AFAICS this is still being 
discussed, so it's indeed a big IF), then rebase/cherry-pick of the 
referenced object simply translates to a rename/copy of the corresponding 
note (this is of course assuming that the note itself does not contain the 
SHA-1 of the referenced object). This could probably be solved fairly 
unintrusively in the current code, but there are (as always) complications:

- The user may want to amend the note after the rebase/cherry-pick (just as 
(s)he may want to amend the commit message).

- In some cases it may even make sense to fold (parts of) the note _into_ 
the commit message.

- probably more reasons...

So what about the following proposal: Add hooks that are invoked by 
rebase/cherry-pick with the <from-SHA1> and <to-SHA1> as arguments. A 
typical hook script can then use this information to look up notes 
referencing <from-SHA1> and update these to reference <to-SHA1> instead, 
and in the process, prompt the user to do whatever changes (s)he wants to. 
The hook scripts can do other things as well, e.g. implementing issue #1 
above (adding notes for annotating the rebase/cherry-pick itself.)


Have fun! :)

...Johan


PS: What's the current status on git-sequencer? It's probably the best place 
to invoke these hooks.

-- 
Johan Herland, <johan@herland.net>
www.herland.net