On 3/11/07, Junio C Hamano <junkio@xxxxxxx> wrote:
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
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@xxxxxxxxx Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). - 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