[asdf-devel] Question about git

[Faré]

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 <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