On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
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.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state.
This seems like a Babel of states for me to track. What's the standard practice here?
I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is.
thanks, r