On 1/28/10 Jan 28 -11:48 AM, Faré wrote: > 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).
The source I've been using so far is http://progit.org/book/, the apress book /Pro Git/. Specifically, there's the distributed Git chapter: http://progit.org/book/ch5-0.html There isn't a workflow in there that seems to perfectly reflect what we've been doing with ASDF, but maybe we can find one that works. Here's a single-user policy for git branches: http://www.newartisans.com/2009/10/branch-policies-with-git.html I'm not dead sure how to turn that into a distributed use case; maybe someone has a better source for that. I need to go wrestle with figuring out how to manage multiple remotes in my git repo.... Best, r > > [ 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
