Re: [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules

From: Steffen Prohaska <prohaska@zib.de>
Date: Feb 4, 2008, 05:19 UTC
Message-ID: <A3A63507-41CA-4FE0-BE77-BF6987E87AD2@zib.de>
In-Reply-To: <alpine.LSU.1.00.0802032237320.7372@racer.site>

On Feb 3, 2008, at 11:43 PM, Johannes Schindelin wrote:

Show 18 quoted lines

> On Sun, 3 Feb 2008, Mark Levedahl wrote:
>
>> This patch series was inspired by several issues dealing with  
>> multiple
>> remotes and submodules. The tests added as the last patch demonstrate
>> the specific use pattern to be supported, and that does not work
>> currently.
>
> It seems that everytime you send a new patch series, it gets longer/ 
> more
> complicated/affects more and more of git.
>
> As far as I understood, your problem was _purely_ a submodule  
> issue.  I
> find it utterly unnerving that you keep trying to sneak in _anything_
> unrelated to submodules.
>
> Such as the origin issue.

As fas as I understood, Mark's usage of submodules might have revealed a deficiency in the current handling of origin.

Mark described a distributed workflow that actively uses more than a single server to store repositories and these different servers are not pure replicates of each other. As a consequence the name of the server has a meaning for the users and therefore the workflow makes this explicit by never using "origin" but instead use descriptive names for the remotes. He described situations when people want to speak about what they have in their repositories and want to describe where they pulled from. I can well imaging that the result of everyone saying "I pulled from origin" can cause great confusion if origin means different things; and therefore it is a reasonable choice to completely avoid origin.

Partly because of this explanation by Mark and the problems he described, I decided against using submodules, but instead merged all the submodules that I originally planned to keep separate into a single monolithic repository. I expect that a single repository works well because this is what the Linux kernel uses.

Show 13 quoted lines

> I am getting pretty angry that you keep trying to complicating  
> things in
> that area!  origin is origin is origin.  It is the default remote.   
> It is
> what you can change to fetch from somewhere else _by default_.  So I
> absolutely detest your changes in that regard, who help _noboy_ except
> people who like confusion.
>
> So just change remote.origin.url, but do not mess up our nice  
> source code.
>
> If your issue is with git-submodule, then fix _that_, and do not "fix"
> _anything_ else.

If I understood Mark correctly, this would not solve his problem because he wants to *avoid* origin; and his arguments make sense to me. Unfortunately I cannot contribute any real world experience, because I chose to abandoned the idea of using submodules.

However, this does not mean that I'll never use submodules. Actually I am pretty sure submodules could become very helpful end of March; and I should also support multiple servers at that time. So I would be happy if the use case described by Mark was well supported by git.

	Steffen