mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Cosmin Polifronie <>
To: Bryan Turner <>
Cc: Git Users <>
Subject: Re: Running 'git worktree add' in 'pre-commit' hook
Date: Wed, 15 May 2019 15:38:44 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello Bryan,

My project contains a Gradle build that is dependent on a
configuration found in a file called build.gradle. What I need to do
is run Gradle with a proper build.gradle file, meaning: if a new
build.gradle is staged, I will use that for my Gradle build, if not I
will use the latest approved commit's one (as in a commit that has
already passed the pre-commit check). The problem is that build.gradle
can be modified and not be staged, and Gradle cannot know that, it
will use whatever is available on disk. I want to avoid that.

This is why I needed a copy of my current repo with the file versions
already approved (already staged at a previous date). This is why I am
using 'git worktree add'.

Now, I have found another solution using stashes, and those might
work, but I am still curious about this situation.

On Wed, May 15, 2019 at 3:46 AM Bryan Turner <> wrote:
> On Tue, May 14, 2019 at 7:53 AM Cosmin Polifronie <> wrote:
> >
> > Hello! I am trying to run 'git worktree add <path> HEAD' in the
> > 'pre-commit' hook, more specifically in a Python script that is being
> > called from the hook. When doing so, I am greeted with the following
> > error:
> >
> > On Windows 10:
> > Preparing worktree (detached HEAD cbfef18)
> > fatal: Unable to create 'C:/Users/meh/Desktop/abc/.git/index.lock': No
> > such file or directory
> >
> > On Arch Linux:
> > Preparing worktree (detached HEAD cbfef18)
> > fatal: Unable to create '/home/cosmin/Downloads/abc/.git/index.lock':
> > Not a directory
> >
> > Is it forbidden to call this command from a hook? If yes, what kind of
> > alternatives do I have? I need to make a copy of the repo in its HEAD
> > state, process it and then decide if I will pass the current commit or
> > not.
> I can't speak to whether `git worktree add` should succeed or fail
> inside a `pre-commit` hook, but...
> Why do you need a new work tree, versus whatever working copy you're
> running `git commit` in? Is there a reason whatever validation needs
> to be done can't be done in the existing working copy? `HEAD` is the
> _previous, existing commit_, not the new, currently-being-created
> commit, so your validation in the new work tree, if you actually
> managed to create one, would be applied to the _latest existing
> commit_, not the new changes you're trying to commit. Even trying to
> copy the changes over wouldn't necessarily result in the same state,
> because there may be unstaged changes.
> What type of validation are you trying to do? I think the failure
> you're running into is an alarm bell indicating what you're trying to
> do may not make sense. However, without any insight into what "process
> it and then decide if I will pass the current commit or not" actually
> looks like, it's hard to offer you much help.
> Bryan
> >
> > Thanks! :)

  reply	other threads:[~2019-05-15 12:38 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 [this message]
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
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 \
    --in-reply-to='' \ \ \ \

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