Re: [PATCH] sequencer: honor GIT_REFLOG_ACTION

> > As a heads up, though, my personal plans for rebase (subject to buy-in
> > from other stakeholders) is to make it do a lot more in-memory work.
> > In particular, this means for common cases there will be no subprocess
> > invocations, no writing of any state unless/until you hit a conflict,
> > no updating of any files in the working tree until all commits have
> > been created (or a conflict is hit),
>
> I'm with you up to here - it sounds fantastic
>
> > and no updating of the branch
> > until after all the commits have been created.
>
> We only update the branch reflog at the end of the rebase now.
>
> > Thus, for the common
> > cases with no conflicts, there would only be 1 entry in the reflog of
> > HEAD the entire operation, rather than approximately 1 per commit.
>
> This I'm not so sure about. In the past where I've messed up a rebase
> and not noticed until after a subsequent rebase it has been really
> useful to be able to go through HEAD's reflog and find out where exactly
> I messed up by looking at the sequence of picks for the first rebase.
> Specifically it shows which commits where squashed together which you
> cannot get by running git log on the result of the rebase.