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@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
