Re: Allowing override of the default "origin" nickname

On 2008.01.11 11:39:48 -0500, Mark Levedahl wrote:

On Jan 11, 2008 10:03 AM, Johannes Schindelin >

quoted

Okay, so with your change the user has to either remember or lookup which
is the default remote.  Without your change, the user has to either
remember or lookup where origin points to.

I still think your change does not help.

That's a theoretical argument: my *experience* with trying to make the
current workflow operate was sufficiently bad and troublesome that it
caused me to write code and fix it to enable the new workflow. Also,
absent submodules the new workflow is fully supported by
branch.<name>.remote: are you advocating the elimination of that
existing feature?

AFAICT your main point is that you can do:
git config --get remotes.default

and get an unique _symbolic_ name, right? So while you still need to
lookup the value of remotes.default, you get e.g. "myremote" instead of
"git://myremote/foo.git" which you get from "git remote show origin". At
least that's how I interpreted it. Your argumentation wasn't that clear
on what you actually want to achieve/improve and why just looking up
"origin" isn't enough, IMHO.

A different approach, which feels more in-line with the current state of
things, might be to allow remote aliases. "origin" would be an alias of
"myremote", and "git remote show origin" might say "origin is an alias
for myremote" followed by the details of "myremote". So that would give
you the same benefit, but "origin" would keep its meaning, and you would
not get different behaviour depending on some configuration setting (so
the poor folks on #git can just assume that "origin" is the default for
everyone).

Admittedly, I don't see any use-case for aliases except for that origin
thing, but maybe someone else does?

Björn