On 1/28/10 Jan 28 -6:53 AM, Pascal J. Bourguignon wrote:
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.
Currently, since ASDF lives pretty much in a single .lisp file, the merge task may be daunting.
Suggestion: let's develop a proposed work method for people who want to develop for ASDF. It seems like this proposed work method should specify at least:
1. What repository do you pull from?
2. How do you provide fixes? Are you expected to provide your own public git repository (I would /not/ favor this alternative --- raises the bar too high) or are you supposed to use git-format-patch/git-email?
3. If we are to prepare patches, we should provide a recipe for preparing them (i.e., do /these/ git commands, including how to bring your repo into harmony with the designated public repo).
4. Should the public repository be modified to have a stable and a development branch? I sorta prefer the idea that we should have a stable and development branch on the main repo and prepare patches against the development branch, rather than having to synchronize myself with both the public repo and Fare's.
4.a. Note that I am not wedded to the public repo --- if we were to move to synchronizing against Fare's that would be fine with me. But I think there are two reasons to prefer moving Fare's development branch to the public repo, instead of syncing with Fare's: (1) stability --- ASDF development has been chaotic already and switching repositories seems like yet more confusion; (2) the public one permits access from multiple people in case of emergency as in, e.g., Fare gets abducted by aliens, or gets born again and will program only in Visual Basic.
5. We should provide an explanation of how to interact with both stable and development remotely.
Cheers, r