Re: Generating a todo file for non-interactive rebasing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux