On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote: > From: Robert Goldman <[email protected]> >> On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote: >>> From: Robert Goldman <[email protected]> >>>> 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
