git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Generating a todo file for non-interactive rebasing
@ 2019-04-16 15:37 Drew DeVault
  2019-04-17 14:59 ` Phillip Wood
  2019-04-17 16:11 ` Johannes Schindelin
  0 siblings, 2 replies; 4+ messages in thread
From: Drew DeVault @ 2019-04-16 15:37 UTC (permalink / raw)
  To: git

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.

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

-- 
Drew DeVault

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Generating a todo file for non-interactive rebasing
  2019-04-16 15:37 Generating a todo file for non-interactive rebasing Drew DeVault
@ 2019-04-17 14:59 ` Phillip Wood
  2019-04-17 16:11 ` Johannes Schindelin
  1 sibling, 0 replies; 4+ messages in thread
From: Phillip Wood @ 2019-04-17 14:59 UTC (permalink / raw)
  To: Drew DeVault, git

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.
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Generating a todo file for non-interactive rebasing
  2019-04-16 15:37 Generating a todo file for non-interactive rebasing Drew DeVault
  2019-04-17 14:59 ` Phillip Wood
@ 2019-04-17 16:11 ` Johannes Schindelin
  2019-04-17 17:11   ` Drew DeVault
  1 sibling, 1 reply; 4+ messages in thread
From: Johannes Schindelin @ 2019-04-17 16:11 UTC (permalink / raw)
  To: Drew DeVault; +Cc: git

Hi Drew,

On Tue, 16 Apr 2019, Drew DeVault wrote:

> 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.

The default mode of the rebase command is actually not based on picks, but
internally generates mails, puts them into an mbox, and then pretends to
apply those patches from a mailing list.

That mode is obviously very different from the interactive rebase, so
there is not quite the simplification in store that you hoped for.

However, we recently changed the way the --merge backend works, and it is
now indeed backed by the same machinery as the interactive rebase.
Meaning: if you call `git rebase -m <options>...`, you have what you
wished for. This change is part of v2.21.0.

To my surprise, Elijah Newren (who authored that change) then demonstrated
that in most cases, the `--merge` backend is actually *faster* than the
default (`--am`) backend. There were patches floating around to make it
the default rebase backend for that reason, but those patches were not
picked up yet.

Short version: if you add `--merge` or `-m` to your `git rebase`
invocations, you already get what you want.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Generating a todo file for non-interactive rebasing
  2019-04-17 16:11 ` Johannes Schindelin
@ 2019-04-17 17:11   ` Drew DeVault
  0 siblings, 0 replies; 4+ messages in thread
From: Drew DeVault @ 2019-04-17 17:11 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Thanks for clarifying this, folks.

On 2019-04-17  6:11 PM, Johannes Schindelin wrote:
> To my surprise, Elijah Newren (who authored that change) then demonstrated
> that in most cases, the `--merge` backend is actually *faster* than the
> default (`--am`) backend. There were patches floating around to make it
> the default rebase backend for that reason, but those patches were not
> picked up yet.

Would be cool to see these picked up.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-04-17 17:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-16 15:37 Generating a todo file for non-interactive rebasing Drew DeVault
2019-04-17 14:59 ` Phillip Wood
2019-04-17 16:11 ` Johannes Schindelin
2019-04-17 17:11   ` Drew DeVault

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).