Re: Running 'git worktree add' in 'pre-commit' hook

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 16, 2019 at 7:25 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> 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.

I think that this is not quite accurate. The problem isn't that
git-commit is pointing GIT_INDEX_FILE at a temporary index; that works
fine. The problem is when it is using the normal .git/index file, in
which case the value it assigns to GIT_INDEX_FILE is relative.

For instance, with pre-commit hook:

    #!/bin/sh
    echo "GIT_INDEX_FILE=$GIT_INDEX_FILE"
    git worktree add --detach other

"git-worktree add" with a normal git-commit breaks due to the relative
location specified by GIT_INDEX_FILE:

    $ git add file
    $ git commit -m foo
    GIT_INDEX_FILE=.git/index
    Preparing worktree (detached HEAD 0857fef)
    fatal: Unable to create '/.../other/.git/index.lock': Not a directory
    $

whereas, the "git commit <file>" form succeeds just fine because it
assigns an absolute path for the temporary index:

    $ git commit -m foo file
    GIT_INDEX_FILE=/.../.git/next-index-23675.lock
    Preparing worktree (detached HEAD 0857fef)
    HEAD is now at 0857fef first
    [master 2fa5413] foo
    $



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux