On Monday 11 December 2006 14:33, Johannes Schindelin wrote: > On Mon, 11 Dec 2006, Josef Weidendorfer wrote: > > > On Monday 11 December 2006 11:39, Andreas Ericsson wrote: > > > > Import/export scripts literally require wrapping every single GIT > > > > command with a script that changes directory a few times, reads from a > > > > different checked-out tree, and permutes some extended-attribute data > > > > slightly before storing it in the underlying GIT tree. Even without > > > > adding any new functionality whatsoever that doubles the amount of code > > > > just for finding your repository and checking command-line arguments, > > > > and that's a crazy trade-off to make in any situation. > > > > > > > > > > GIT_DIR=/some/where/else/.git git log -p > > > > Doing this everytime you want to run a git command *is* a lot of time > > wasted for typing. > > > > The .gitlink proposal would come in handy here: you have a simple > > file instead of .git/, which links to the real repository. > > I beg your pardon; I'm just joining in. Why is a symbolic link for .git > inacceptable? You are totally right. The .gitlink thing is tailored to allow submodule support later. It includes some smart searching for the git repository to allow moving the checkout in some limits without breaking the link to the repository. Aside from this, the proposal is more flexible in that you can specify not only GIT_DIR (or the GIT_DIR_HINT to trigger smart search), but also GIT_INDEX_FILE and GIT_HEAD_FILE, which allows different checkouts (with different index state and HEAD) for the same repo easily. Which is not needed in this case. So, sorry for the noise ;-) Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html