for the benefit of future git travelers, here is a small correction to the
prior post.  the command i use is this:

git checkout-index --prefix="${stage_dir}/" --all

the trailing slash in the prefix is important.  without it, the script was
trying to checkout files like "$GIT_WORK_TREE/foo" to locations like
"/tmp/tmp.UDIlPsCQamfoo" instead of "/tmp/tmp.UDIlPsCQam/foo".  this is
because mktemp returns values like "/tmp/tmp.UDIlPsCQam" without a trailing

less importantly, the '--work-tree="$PWD"' is unnecessary because PWD is
the default for the working directory.

On Tue, Jan 5, 2016 at 12:15 PM ozzloy <> wrote:

> thanks for the tip about checkout-index!
> the idea to use git checkout-index works, but it took me a while to
> figure it out completely.  you're right, it ends up being much shorter
> and does a lot less stuff than the other method.  here's the
> checkout-index that worked for me:
> git --work-tree="$PWD" checkout-index --prefix="${stage_dir}" --all
> "why are you concerned with the state of the file representing
> the index"
> partially because i didn't know about checkout-index.  this is
> definitely helpful.  i've converted to using this for now.  however,
> even though this works, i'm still exploring the in-place method for 2
> reasons:
> 0. it seems like it would be much more efficient.  it only modifies
> files that have changed since the last commit, rather than making copies
> of all project files in a new directory.  so far, the
> checkout-index method works fast enough, but i've only used it on
> small projects.
> 1. it is unclear to me how difficult it is to get some of the projects
> i work on to build in arbitrary directories.  some of the projects i
> work on are built via eclipse and configuring eclipse to build in a new
> location of the files has been difficult.  probably i can find a way to
> convince eclipse to build in other places.  i'm not sure, so i'm
> exploring.  but even if i do get that to work, then i've only got it
> to work for eclipse and i'll have to look into the specifics of the next
> build environment, and the one after that, and so on.
> thanks for the suggestion!  it's working great!
> On Wed, Oct 28, 2015 at 10:30 AM Konstantin Khomoutov <
>> wrote:
>> On Tue, 27 Oct 2015 22:12:51 -0700 (PDT)
>> ozzloy <> wrote:
>> > i am writing a script to test exactly what's staged for the next
>> > commit. this should work even on root commit, and in orphan branches,
>> > so using stash by itself doesn't work because there's no HEAD for
>> > stash to stash on.
>> >
>> > my current solution in those situations is to:
>> > 0 commit the index
>> > 1 stash unstaged unignored files
>> > 2 run tests and save result
>> > 3 stash pop
>> > 4 delete HEAD
>> > 5 return the saved test result
>> >
>> > my concern is that step 0 might modify the index.
>> >
>> > if there's a better way to test the index, i'd be happy to hear it
>> I have one ide and one question.
>> The idea: use `git checkout-index` with a relocated work tree
>> (something like the result of running `mktemp -d /tmp/gitXXXXXX`)
>> and build there.  This will basically replace step 0 and remove
>> steps 1,3-5.  Basically, you'd do:
>>   DIR=`mktemp -d /tmp/gitXXXXXX`
>>   trap "rm -rf '$DIR'" TERM INT EXIT
>>   git --work-tree="$DIR" checkout-index --all
>>   make test -C "$DIR"
>> The question is: why are you concerned with the state of the file
>> representing the index at all?  As I've already hinted, the behaviour
>> of the index file during committing appears to be not documented which
>> means Git is free to actually update the index when it records a commit.
>> So what would maintaining the index's file mtime etc would buy you?

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to