From: Robert Goldman rpgoldman@sift.info
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman rpgoldman@sift.info
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
Also, my suggestion was about economic sense: if you have a moving devel branch, which is likely to go upstream, it makes sense to begin making changes off that, rather than off something in the past -- you basically get merging for free.
This doesn't have anything to do with one vs. two repositories -- rather, this is pertinent to any situation with two branches -- 'release' and 'devel'.
regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org