Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: [RFC] introduce GIT_WORK_DIR environment variable

From: A.J. Rossini <hidden>
Date: 2016-06-15 22:42:59

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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help