git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Drew DeVault <sir@cmpwn.com>, git@vger.kernel.org
Subject: Re: Generating a todo file for non-interactive rebasing
Date: Wed, 17 Apr 2019 15:59:12 +0100
Message-ID: <07e0259b-0d7a-b109-cd3c-ccfbf17ad573@gmail.com> (raw)
In-Reply-To: <20190416153709.GA19000@homura.localdomain>

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

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 15:37 Drew DeVault
2019-04-17 14:59 ` Phillip Wood [this message]
2019-04-17 16:11 ` Johannes Schindelin
2019-04-17 17:11   ` Drew DeVault

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07e0259b-0d7a-b109-cd3c-ccfbf17ad573@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sir@cmpwn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox