On 2010/01/27, at 22:47 , Robert Goldman wrote:
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.
You can think of a repository as a sequence of patches.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.