mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Duy Nguyen <>
Cc: Cosmin Polifronie <>,
	Git Mailing List <>
Subject: Re: Running 'git worktree add' in 'pre-commit' hook
Date: Thu, 16 May 2019 18:17:02 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 16, 2019 at 06:25:24PM +0700, Duy Nguyen wrote:

> > Is it forbidden to call this command from a hook?
> pre-commit hook sets GIT_INDEX_FILE to this "index.lock" so you have
> the latest index content (which is not the same as from
> $GIT_DIR/index). This variable will interfere with any commands that
> work on a different worktree.
> So you probably can still make it work by backing up $GIT_INDEX_FILE
> (in case you need it), then unset it before you use "git worktree" (or
> cd to it if you keep a permanent separate worktree for pre-commit
> activities). To make sure you don't have similar problems, you
> probably should do "env | grep GIT" from the hook and see if any other
> variables are set.

If you're entering another repo from a hook, you're supposed to use:

  unset $(git rev-parse --local-env-vars)

I wondered if we'd need another similar mechanism for entering the
worktree of another repo, that would maybe clear fewer variables. But I
think it's actually the same: we really want to clear everything and let
our "cd" pick up the new repository path.

The case of actually _adding_ a new work tree (before we enter it) is
weirder, though. We definitely want to stay in the same repository, and
clearing all of that would not make sense. I do wonder if worktree-add
should be handling GIT_INDEX_FILE (ignoring it when we want to be
dealing with the index of the new worktree we added, and handling any
relative fixups if we chdir inside the worktree code).


  parent reply	other threads:[~2019-05-16 22:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 14:52 Running 'git worktree add' in 'pre-commit' hook Cosmin Polifronie
2019-05-15  0:46 ` Bryan Turner
2019-05-15 12:38   ` Cosmin Polifronie
2019-05-16 11:25 ` Duy Nguyen
2019-05-16 11:33   ` Eric Sunshine
2019-05-16 11:39     ` Eric Sunshine
2019-05-16 11:44       ` Duy Nguyen
2019-05-16 12:05         ` Eric Sunshine
2019-05-16 11:41     ` Duy Nguyen
2019-05-16 12:14       ` Eric Sunshine
2019-05-16 12:28         ` Duy Nguyen
2019-05-16 11:59   ` Eric Sunshine
2019-05-16 22:17   ` Jeff King [this message]
2019-05-16 23:16     ` Eric Sunshine
2019-05-17  0:19       ` Jeff King
2019-05-17  1:02         ` Eric Sunshine
2019-05-17  1:19           ` Jeff King

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