Re: want <reason> option to git-rebase

From

IJIan Jackson <ijackson@chiark.greenend.org.uk>

Date

Jun 19, 2018, 10:19 UTC

Message-ID

<23336.55459.558413.723251@chiark.greenend.org.uk>

In-Reply-To

<20180619010655.GA173168@aiede.svl.corp.google.com>

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.

Ian.

-- 
Ian Jackson <ijackson@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.