On 2008.01.11 11:39:48 -0500, Mark Levedahl wrote: > On Jan 11, 2008 10:03 AM, Johannes Schindelin > > > 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 - 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
