Re: Generating a todo file for non-interactive rebasing

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Drew

On 16/04/2019 16:37, Drew DeVault wrote:
> Hiya!
> 
> Whenever I do a particularly long rebase on a branch, sorting out
> conflicts from upstream, I find that it's often useful to have the
> additional context that you get during an interactive rebase, such as
> recent commands run, commands planned to run, and so on, to get a better
> idea of where I'm at during the rebase. These show when you run `git
> status` during an interactive rebase.
> 
> However, the code that generates this report relies on a todo list being
> generated in the rebase state directory. A todo list which consists only
> of "pick" commands is functionally equivalent to a non-interactive
> rebase, the only difference being that the editor isn't shown to the
> user.
> 
> Is there any reason not to refactor the rebase command to always
> generate a todo list? This would simplify the internals and provide more
> context to the user during hairy rebases. It might also be useful to run
> --edit-todo if you realize your rebase strategy needs to change partway
> through a rebase which was initially non-interactive.

Things are moving in that direction. Currently --merge, --keep-empty, 
--recreate-merges and --exec will result in a todo list being used 
regardless of --interactive. There was some discussion a couple of 
months ago about making --merge the default if there were no am specific 
options given but I've not noticed a patch for that yet. There is also a 
GSoC project that will implement some of the am specific options for the 
interactive backend with the long term aim of removing the am based backend.

Best Wishes

Phillip
> 
> Note: I'm a non-subscriber, please Cc me on replies.
>