Thomas Rast wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Thomas Rast Cc'ed as he has been the primary force behind this line > > of "notes" usability. > > Thanks for pointing this out to me. > > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > >> Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> > >> --- > >> builtin/revert.c | 2 + > >> sequencer.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- > >> sequencer.h | 2 + > >> t/t3500-cherry.sh | 32 +++++++++++++ > >> 4 files changed, 169 insertions(+), 3 deletions(-) > > > > "git cherry-pick" should help maintaining notes just like amend and > > rebase, but how should this interact with notes.rewrite.<command>, > > where the command is capable of doing this without an explicit > > option once you tell which notes need to be maintained? > > Since we already have the notes.rewrite.<command> convention, it would > seem the obvious choice to line it up with the others. The main > bikeshedding opportunity is whether this should be an exception and > default to false (all other commands default it to true). > > Also: how does this interact with notes.rewriteRef and the corresponding > env vars? Why? > > How does it interact with 'cherry-pick -n' if this is done in sequence, > effectively squashing several commits (this use-case is actually > suggested by the manpage), if multiple source commits had notes? Should > it respect notes.rewriteMode (and by default concatenate)? (I don't > know if the sequencer state is expressive enough already to carry this > in a meaningful way across cherry-pick commands.) Feel free to implement that. I'm just interested in 'git cherry-pick' being usable for 'git rebase' purposes. -- Felipe Contreras -- 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