Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > In a successful run with older git I get a reflog like this:
> >
> > 4833d74 HEAD@{0}: rebase finished: returning to
> > refs/heads/with-preexisting
> > 4833d74 HEAD@{1}: debrebase new-upstream 2.1-1: rebase: Add another new
> > upstream file
> > cabd5ec HEAD@{2}: debrebase new-upstream 2.1-1: rebase: Edit the .c file
> > 0b362ce HEAD@{3}: debrebase new-upstream 2.1-1: rebase: Add a new
> > upstream file
> > 29653e5 HEAD@{4}: debrebase new-upstream 2.1-1: rebase: checkout
> > 29653e5a17bee4ac23a68bba3e12bc1f52858ac3
> > 85e0c46 HEAD@{5}: debrebase: launder for new upstream
...
> > This breaks the test because my test suite is checking that I set
> > GIT_REFLOG_ACTION appropriately.
> >
> > If you want I can provide a minimal test case but this should suffice
> > to see the bug I hope...
>
> This should be plenty for me to get going. Thank you!
Happy hunting.
While you're looking at this, I observe that the fact that the `rebase
finished' message also does not honour GIT_REFLOG_ACTION appears to be
a pre-existing bug.
(In general one often can't rely on GIT_REFLOG_ACTION still being set
because the rebase might have been interrupted and restarted, which I
think is why my test case looks for it in the initial `checkout'
message.)
Regards,
Ian.
--
Ian Jackson <[email protected]> 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.
