Re: rebasing commits that have notes, was Re: Git Notes idea.

From: Johan Herland <johan@herland.net>
Date: Dec 17, 2008, 09:15 UTC
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:

Show 12 quoted lines

> 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