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

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