Re: [RFC] introduce GIT_WORK_DIR environment variable

Linus Torvalds [off-list ref] writes:

So let's say that you have a git repository for tracking all that. The 
"working tree" for that git repository would be your home directory.

Now, imagine that you *also* want to track something else in git, that you 
*also* have in your home directory. Say your ".bashrc" files etc. They 
have nothing to do with your music tracking setup, so you don't want to 
track it in the same git repository, and you want to have a totally 
different .git/index file for those. But again, the *working*tree* is 
actually your home directory.

That is a good example usage schenario; we would need to think
about what to do with .gitignore (and .gitattributes if we will
have that in-tree), though.

On Sun, 11 Mar 2007, Junio C Hamano wrote:

That is a good example usage schenario; we would need to think
about what to do with .gitignore (and .gitattributes if we will
have that in-tree), though.

Good point. That's a real problem.

I guess you could say that for this kind of usage scenario you only want 
to use the per-repository .git/ignore file, or maybe have some way of 
specifying the name of the .gitignore file per repository.

Hmm. I'm not sure it was a great idea. I still like the concept, but 
you're right, it's not without its problems.

		Linus

On 3/11/07, Junio C Hamano [off-list ref] wrote:

Linus Torvalds [off-list ref] writes:

quoted

So let's say that you have a git repository for tracking all that. The
"working tree" for that git repository would be your home directory.

Now, imagine that you *also* want to track something else in git, that you
*also* have in your home directory. Say your ".bashrc" files etc. They
have nothing to do with your music tracking setup, so you don't want to
track it in the same git repository, and you want to have a totally
different .git/index file for those. But again, the *working*tree* is
actually your home directory.

That is a good example usage schenario; we would need to think
about what to do with .gitignore (and .gitattributes if we will
have that in-tree), though.

Modulo problems like above, isn't this just a solid solution to the
modules problem?   (not only directory-level modules, but intertwined
(in the sense of repositories) files within a directory).

And wouldn't the cheap hack just to be to have a pecking order for
determining attributes?  (i.e. a master file with metadata which is
owned by the working directory, not the repository, to decide which
repository to look at for which files).

Ouch, but Junio's right, it's still painful, ugly and problematic.

best,
-tony

blindglobe@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

On Sunday 2007, March 11, Junio C Hamano wrote:

That is a good example usage schenario; we would need to think
about what to do with .gitignore (and .gitattributes if we will
have that in-tree), though.

While it's not solveable yet; if git gets gitattributes support, then 
it's easy.  As long as there is a way of specifying attributes in the 
config (which I'm sure there will be), in the music repository you 
would have (syntax being made up on the spot)

[attribute "gitattributesfile"]
  path = .gitattribute-music
[attribute "gitignorefile"]
  path = .gitignore-music

Then in the config repository:

[attribute "gitattributesfile"]
  path = .gitattribute-config
[attribute "gitignorefile"]
  path = .gitignore-config



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com