git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: 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>
Subject: Re: unifying sequencer's options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages
Date: Thu, 08 Apr 2021 10:45:09 -0700	[thread overview]
Message-ID: <xmqqzgy8u0uy.fsf@gitster.g> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2104080438080.54@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Thu, 8 Apr 2021 04:40:46 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > ...  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.
>>
>> A faster and less powerful interface is good; I doubt deprecation
>> would work well. If a workflow depends on things like post-commit
>> hook, the affected users deserve some way to migrate to --exec or
>> whatever method to compensate the loss of functionality.
>
> I could imagine that there is opportunity to "persist on disk only when
> needed". For example, if no `pre-commit` hook is installed that needs to
> be run, there is no need to update the worktree nor HEAD until the rebase
> is done.
>
> And this type of `only write to disk when needed` functionality could
> probably be abstracted away so much as to make the rest of the code
> look elegant again.

Yes, we are on the same page.  What Elijah proposed as "another
backend" would unfortunately be different, and needs to be adjusted
with such an "only when needed" tweak.  The check hopefully needs to
be done only once (e.g. do we have this hook enabled?  do we have
that hook enabled? do we have a commit with this trait in the range
being worked on? etc. etc.) upfront and for certain workflows may
not require any persistence.

And until that happens, "annoying deprecation notices" will never be
a viable step to take.

  reply	other threads:[~2021-04-08 17:45 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 [this message]
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:
  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=xmqqzgy8u0uy.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.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).