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

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

On Sun, 3 Feb 2008, Mark Levedahl wrote:

quoted

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.

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