Re: "GIT_INDEX_FILE" environment variable

From: Junio C Hamano <junkio@cox.net>
Date: 2005-04-23 06:20:29
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> ... The fact is, you can do _exactly_ what you are talking
LT> about by just wrapping the calls in

LT> 	( cd $WORKING_DIR && git-cmd )

LT> which simply doesn't have any downsides that I can see.

Almost, with a counter-example.  Please try this yourself:

  $ cd mozilla-sha1
  $ echo '/* garbage */' >>sha1.c
  $ sh -c 'cd .. && show-diff "$0" "$@"' sha1.c
  $ cd .. && show-diff mozilla-sha1/sha1.c

Some commands that take working tree relative paths do strange
things without the path munging I discussed in the original
message ("$R- prefixing") if you chdir to the $WORKING_DIR.  The
jit-update-cache wrapper I sent in the previous message is an
example of how Cogito layer can work it around.  It does not
break my "yuck" meter but I think it probably makes most people
barf ;-).  I was trying to make this path munging part easier
for the upper layer by making the core aware of WORKING_DIR.

Here is an updated set of commands that needs such path munging:

  check-files paths...
  show-diff [-R] [-q] [-s] [-z] [paths...]
  update-cache [--add] [--remove] [--refresh]
      [--cacheinfo mode blob-id] paths...
  checkout-cache [-f] [-a] paths...

That said, I do not think the above set is too many to warrant a
core surgery (I am agreeing with your conclusion here).  Unless
we also normalize path to support something like:

  $ cd mozilla-sha1
  $ echo '/* garbage */' >>cache.h
  $ sh -c 'cd .. && show-diff "$0" "$@"' ../cache.h

in the core, that is.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Sat Apr 23 06:21:01 2005

This archive was generated by hypermail 2.1.8 : 2005-04-23 06:21:02 EST