mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Junio C Hamano <>
Cc: Tom Rutherford <>,
	Git Mailing List <>
Subject: Re: post-checkout hook aborts rebase
Date: Thu, 27 Aug 2020 10:47:08 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Aug 27, 2020 at 10:28 AM Junio C Hamano <> wrote:
> Elijah Newren <> writes:
> > On Wed, Aug 26, 2020 at 5:24 PM Junio C Hamano <> wrote:
> >>
> >> Junio C Hamano <> writes:
> >>
> >> > ...  If "git rebase" or whatever
> >> > command wanted to place files and the index into some state by using
> >> > "git checkout" command, and if the post-checkout hook mucked with
> >> > the state in such a way that contradicts with what the "git rebase"
> >> > command wanted them to be in, it is not surprising the hook's behavior
> >> > broke "git rebase"'s operation.
> >>
> >> Having said all that, I actually think that "rebase" shouldn't be
> >> invoking "git checkout" (and its equivalent) internally when
> >> switching to a specific version, in such a way that it would trigger
> >> any end-user specified hooks and allow them to muck with the working
> >> tree and the index state.
> >>
> >> I haven't checked the actual implementation of "git rebase" for
> >> quite some time to be sure, but we have lower-level plumbing
> >> commands that are not affected by the end-user hooks for exactly
> >> that kind of "build higher-level commands by synthesis of
> >> lower-level machinery", and it is very possible that what we are
> >> looking at is actually a bug that needs to be fixed.  I dunno.
> >>
> >> Thanks.
> >
> > Yes, and I think we should also make rebase stop invoking "git commit" too.
> Note that I didn't say we should make it stop invoking "git
> checkout".

Understood that you didn't say that, but I am of the opinion that we
should do that.

Invoking "git checkout" and "git commit" were convenient
implementation details when rebase was written as a script.  When it
was rewritten in C, forking out to these processes made for an easy
conversion path (even if slightly ugly).  But forking other processes
is costly, it has given us multiple reports of unwanted side-effects
from hooks[1], it makes the code more difficult to debug in a
debugger, etc.  I think these are all problems we could avoid by no
longer calling these external commands.

> We could invent a mechanism that disables all the hook invocations
> and other customizations [*1*] (done e.g. via the configuration
> variables) for internal use of the Porcelain commands, and use it
> when "rebase" invokes Porcelains like "checkout", "commit" as its
> implementation detail, for example (some "invocations" I think
> bypass the run_command() inteface and instead done by directly
> calling the implementation detail of "checkout" and "commit", but
> the principles are the same).
> [Footnote]
> *1* of course, it becomes a balancing act to decide what kind of
>     customizations are OK to honor under such a mode.

That'd be one way to solve it, but it feels like it'd push maintenance
burden onto future folks that people touching the commit and checkout
builtins have to be aware of what other commands are using them under
the covers and tweak them appropriately.  I'd rather checkout and
commit just shared the relevant bits of important code with sequencer,
and then if people want to add configuration bits (be that hooks or
config settings or whatever), then it only gets added to the commands
that people explicitly add them to, rather than them getting added to
rebase via accident.

      reply	other threads:[~2020-08-27 17:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26 23:10 post-checkout hook aborts rebase Tom Rutherford
2020-08-27  0:13 ` Junio C Hamano
2020-08-27  0:22   ` Junio C Hamano
2020-08-27  0:44     ` Tom Rutherford
2020-08-27  5:44       ` Chris Torek
2020-08-27 15:51         ` Junio C Hamano
2020-08-27 19:04           ` Chris Torek
2020-08-27 20:11             ` Elijah Newren
2020-08-27 20:32               ` Chris Torek
2020-09-09  9:43       ` Phillip Wood
2020-09-09 16:07         ` Tom Rutherford
2020-09-11 20:25         ` Philippe Blain
2020-09-12  0:51           ` Junio C Hamano
2020-08-27 16:27     ` Elijah Newren
2020-08-27 17:27       ` Junio C Hamano
2020-08-27 17:47         ` Elijah Newren [this message]

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).