Junio C Hamano wrote:
"Mark Levedahl" <mlevedahl@xxxxxxxxx> writes:
Thanks.
I have to admit that I happen to agree with Dscho. I do not see
this helping to solve communication issues very much.
Junio,
My use really is a different use-case than is typical. Origin is a great
concept for the common case of projects with a single upstream
repository. Except for cloning, you don't have to know or care the name
of the upstream as you move from project to project, it is just always
"origin" and you use the same remote nickname in each.
This breaks down in a project like mine where there are multiple servers
and the differences are important. Content and usage vary server to
server, not just connectivity. At this point, hiding the server names is
counterproductive. Basically, use of origin is data hiding, and data
hiding is not good when you actually need the data.
Across the git project, I believe everyone basically understands origin
as git.kernel.org/..., and origin is not ambiguous. There is just one
server. For my project, there are multiple servers and a number of us
pull from and push to multiple servers with no intent that any one
server has everything (This multiplicity is necessary for several
reasons, and we have various guards in place restrict the content of
different servers). Thus, there really is no usefully defined *origin*.
There just isn't. This is where the disagreements lie.
The argument against my approach of explicitly naming the server rests
upon the premise that hiding a half-dozen servers, all different and
with those differences being important, under the single universal name
"origin", makes things easier. It doesn't when different servers are
different. Yes, it is possible to figure out what "origin" means at a
given client, and thus understand how to address a given server from
that client. That is the essence of the problem. It is clear to address
server1 as "server1", and server3 as "server3." It is not helpful to
sometimes refer to server1 as origin, sometimes as server3, and thus
need to know the definition of origin to know how to name the server.
For the "normal" git use-case the specific definition of origin is
unimportant when you use it and so provides a useful abstraction. That I
must know what origin means in order to know what to do indicates the
abstraction is counter-productive.
Until we started using sub-modules, we used git clone --origin
<nickname> and per our standard usage never even had "origin" defined.
We just agreed on a common set of nicknames for our servers and used
those. Not everyone had all the remotes defined, but nickname "foo"
meant the same thing everywhere it was defined. That worked very well
for us.
So, all I am doing here is trying to extend a basic multi-server
capability git already has for a monolithic project into projects using
sub-modules. This will let us resume working the way we did before and
stop overloading a single nickname (origin) with multiple meanings.
Mark
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
