Using a development branch on the public repo sounds alright to me. I started my repo before I had the commit bit on the public repo, which is what got me started historically. I didn't change my workflow just because I've been too lazy to learn how to do it so far.
If someone will point me to a document that explains how to properly use branched development with git, I will gladly do it (as it seems to be the consensus that we should be using branches in the main public repo). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is joy in work. There is no happiness except in the realization that we have accomplished something. — Henry Ford 2010/1/28 Robert Goldman <[email protected]>: > 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 <[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. >> >> 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
