[asdf-devel] Question about git

[Pascal J. Bourguignon]

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.

-- 
__Pascal Bourguignon__
http://www.informatimago.com