Jonathan Nieder writes ("Re: want <reason> option to git-rebase"):
> Ian Jackson wrote[1]:
> > git-rebase leaves entries like this in the reflog:
> >
> > c15f4d5391 HEAD@{33}: rebase: checkout
> > c15f4d5391ff07a718431aca68a73e672fe8870e
...
> GIT_REFLOG_ACTION
> When a ref is updated, reflog entries are created to keep
> track of the reason why the ref was updated (which is
> typically the name of the high-level command that updated the
> ref), in addition to the old and new values of the ref. A
> scripted Porcelain command can use set_reflog_action helper
> function in git-sh-setup to set its name to this variable when
> it is invoked as the top level command by the end user, to be
> recorded in the body of the reflog.
>
> "git rebase" sets this itself, so it doesn't solve your problem.
Hrm.
> Can you say more about what your tool does? I'm wondering if it would
> make sense for it to use lower-level commands where GIT_REFLOG_ACTION
> applies, instead of the more user-facing git rebase.
Sure.
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git-manpage/dgit.git/git-debrebase.1
See the description of git-rebase new-upstream. It does a lot of
complicated work, synthesising a new pair of commits using plumbing
etc., and then does
git rebase --onto <thing it made> <user's previous base>
If the user says git rebase --abort, everything should be undone.
Another alternative solution would be to be able to make git reflog
entries without actually updating any ref.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
