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