git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Christian Couder <christian.couder@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Elijah Newren" <newren@gmail.com>,
	"Phillip Wood" <phillip.wood123@gmail.com>,
	"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Philip Oakley" <philipoakley@iee.email>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: unifying sequencer's options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages
Date: Fri, 9 Apr 2021 15:53:23 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2104091548500.54@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <CAP8UFD1WsjB_shHnRUcH3rnQjwh0yodrETq6zh39vnZnHQpVyw@mail.gmail.com>

Hi Christian,

On Thu, 8 Apr 2021, Christian Couder wrote:

> On Thu, Apr 8, 2021 at 2:22 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Fri, 2 Apr 2021, Junio C Hamano wrote:
> >
> > > Elijah Newren <newren@gmail.com> writes:
> > >
> > > > 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 would be interesting to know which of these updates (working copy,
> index or reflog) is the most costly. Of course the best would be to
> compare the costs when updates are done at each step vs only at the
> end.

I would bet that the worktree updates are the most costly thing.

Note: there is also the step where new objects are written to the object
database, but that is a step that we can _not_ skip.

> If the split index could also become the default one day, I guess we
> could be doing pretty well even when some hooks are installed.

Hmm. My opinion about the split index does not match yours.

I'd much rather see us tackle the challenge of allowing truly incremental
index updates. That "split index" feature feels like a bandaid that tries
to do sort of an incremental update, and fails at it because it is not
truly incremental. Granted, that would look much more like a real database
and is much, much harder than what the split index code does (think
e.g. locking).

Ciao,
Dscho

  reply	other threads:[~2021-04-09 13:53 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
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 [this message]
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:
  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=nycvar.QRO.7.76.6.2104091548500.54@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=philipoakley@iee.email \
    --cc=phillip.wood123@gmail.com \
    --subject='Re: unifying sequencer'\''s options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages' \
    /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

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