[asdf-devel] Question about git

[Robert Goldman]

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