[asdf-devel] Question about git

[Robert Goldman]

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 <rpgoldman at sift.info>:
>> 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 at sift.info>
>>>>>> On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
>>>>>>> From: Robert Goldman <rpgoldman at 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