Dan Douglas posted on Thu, 24 May 2012 01:51:28 -0500 as excerpted: > I don't think doing a branch of the entire tree is a good idea (well > maybe...). I was thinking more along the lines of subtree merges into a > local overlay, or perhaps submodules. To do that currently (I think) > would require taking the rsync tree and putting that into a repo, and > trying to keep it synchronized. Plus in the process you lose all > correspondance with upstream commits so that logs and diffs become > meaningless.
The thing about git branches is that they cost almost nothing. If the whole main tree is a single git tree, and you already have that available, maintaining a branch consisting of what we now call an overlay is trivial, compared to simply maintaining the separate files, as is normally done now. In that regard, git is nothing like for instance svn, where branches come at a much higher cost, as does merging between them. (CVS... I don't actually know enough about to make an informed comparison. It'd be a real shame not to expose the read-only git tree to the users who want it. Git was /designed/ to be distributed in that manner. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
