On Thu, Aug 4, 2016 at 2:31 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Chris, > > On Wed, 3 Aug 2016, Chris Packham wrote: > >> This is similar to the existing "reword" command in that it can be used >> to update the commit message the difference is that the editor presented >> to the user for the commit. It provides a useful shorthand for "exec git >> commit --amend --no-edit -s" <snip> > Having said that, this patch clashes seriously with my current effort to > move a lot of the interactive rebase from shell into plain C. It is > actually ready, but getting this into the code base is really slow-going, > unfortunately. > > Now, after looking at your patch it looks to me as if this would be easily > ported, so there is not a big deal here. Yeah sorry. I knew there was something in flight but ended up doing a quick hack on top of master. > However, I could imagine that we actually want this to be more extensible. > After all, all you are doing is to introduce a new rebase -i command that > does nothing else than shelling out to a command. Why not introduce a much > more flexible feature, where you add something like "rebase -i aliases"? > > Maybe something like this: > > [rebase "command"] > sign = git commit --amend -s --no-post-rewrite --no-edit -S I did briefly consider that. I ended up taking the shortcut because I had a patch series I needed to sign. Elsewhere in this thread the idea of pick -S or reword -S was raised. I'd actually prefer that because there seems little between 'git config rebase.command.sign blah' and 'exec ~/sign.sh' > I have not completely thought this through, but maybe this direction would > make the interactive rebase even more powerful? The uses I can think of are adding sign-off and running "make check". For me rebase -i doesn't need to be much more powerful than that. -- 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