list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Junio C Hamano <>
Cc: Phillip Wood <>,
	Johannes Schindelin <>,
	Elijah Newren via GitGitGadget <>,
	Git Mailing List <>,
	Philip Oakley <>
Subject: Re: unifying sequencer's options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages
Date: Fri, 2 Apr 2021 15:18:09 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqa6qg4d0i.fsf@gitster.g>

On Fri, Apr 2, 2021 at 2:01 PM Junio C Hamano <> wrote:
> Phillip Wood <> writes:
> > I think we would save a lot by only syncing the state to disk when we
> > stop or run an exec command (the state needs to be synced so exec
> > commands can alter the todo list). In those cases we need to write the
> > index and possibly run an external process so writing a couple of
> > files is probably insignificant.
> The optimization opportunity of this may be a lot smaller than you
> would think---you must cater to not just exec but hook scripts that
> are run while a new commit is made, which means every step you'd
> need to write anyway.

From Documentation/git-rebase.txt, right after discussing how the
backends disagree on which hooks are called and how they are called:

...In each case, the calling of these hooks was by accident of
implementation rather than by design (both backends were originally
implemented as shell scripts and happened to invoke other commands
like 'git checkout' or 'git commit' that would call the hooks).  Both
backends should have the same behavior, though it is not entirely
clear which, if any, is correct.  We will likely make rebase stop
calling either of these hooks in the future.

Even if others now disagree with the above, I know I can get a huge
speedup by changing sequencer to stop per-commit wasteful work (stop
forking processes like "git commit", don't write control structures if
the rebase hasn't ended or hit a conflict, don't update the working
copy or index or reflog).  It's enough of a speedup that if backward
compatibility won't allow such a method to be used by default, I'd
still make yet another backend that could be optionally used.  And I'd
have the default rebase and cherry-pick start printing annoying
deprecation notices so that users become aware of a faster option.
Should I go that route?  t/helpers/test-fast-rebase.c already has a
good start...

> > Where I think we can usefully consolidate is the one-line files which
> > store the options rather than state - these are read an written much
> > less frequently so I don't think they have much of a performance hit
> > but it would be much nicer to just serialize the options to a single
> > file.
> Would that break external scripts, hooks, etc.?  I am not sure if we
> even have any rough consensus for allowing other people to peek into
> the .git/rebase-*/ directories, but I am inclined to say that it
> sounds more like a solution looking for a problem than a good idea
> to solve some concrete problem.

To be honest, my bigger complaint with the non-unified backend config
is how far it bled into the code and how difficult it is to determine
how things are controlled and which sections of code are relevant for
which types of operations.  And how much of a pain I'm worried it'd
make the "allow rebasing and cherry-picking in a bare repository (or
for an unchecked-out branch)" functionality.  Perhaps the code can be
cleaned up without changing these on-disk structures, in which case my
concern for this point would lessen.

  reply	other threads:[~2021-04-02 22:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  7:16 [PATCH] " Elijah Newren via GitGitGadget
2021-03-26 12:27 ` Philip Oakley
2021-03-26 15:12   ` Elijah Newren
2021-03-28  1:30     ` Junio C Hamano
2021-03-29  9:23 ` Phillip Wood
2021-03-29 20:52   ` Junio C Hamano
2021-03-29 21:25   ` Elijah Newren
2021-03-30  2:09 ` [PATCH v2] " Elijah Newren via GitGitGadget
2021-03-30 10:13   ` Johannes Schindelin
2021-03-30 18:47     ` Junio C Hamano
2021-03-30 20:16       ` Elijah Newren
2021-03-31 17:36         ` Ævar Arnfjörð Bjarmason
2021-03-31 17:52           ` Elijah Newren
2021-03-31 18:01         ` Junio C Hamano
2021-04-01 16:31           ` Elijah Newren
2021-03-30 19:37     ` Elijah Newren
2021-03-31 13:48       ` unifying sequencer's options persisting, was " Johannes Schindelin
2021-04-02 11:28         ` Phillip Wood
2021-04-02 13:10           ` Phillip Wood
2021-04-02 21:01           ` Junio C Hamano
2021-04-02 22:18             ` Elijah Newren [this message]
2021-04-02 22:27               ` Junio C Hamano
2021-04-08  2:40                 ` Johannes Schindelin
2021-04-08 17:45                   ` Junio C Hamano
2021-04-08 19:58                   ` Christian Couder
2021-04-09 13:53                     ` Johannes Schindelin
2021-03-31  6:52   ` [PATCH v3] " Elijah Newren via GitGitGadget
2021-03-31 14:38     ` Johannes Schindelin
2021-04-02 11:40 unifying sequencer's options persisting, was Re: [PATCH v2] " Gabriel Young

Reply instructions:

You may reply publicly 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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: unifying sequencer'\''s options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages' \

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

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

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