Roman Neuhauser <rn+git@xxxxxxxxxx> writes: >> But we'd end up treating them the same. And something like >> remote.originName would help that. Otherwise, we'd end up sending >> this message: >> >> Even if we give "--bare --origin yourfavouritename" to you now, >> unlike how 'origin' is treated in the default case, in the >> resulting repository, 'yourfavouritename' is not special at all. > > Isn't that the case in non-bare repositories as well? You have branches that are checked out. The first branch that you'd presumably be using as the primary (traditionally called 'master') knows that the nickname used to call the remote it integrates with as the value of branch.master.remote In a bare repository, there is no such clue. > Can't they just continue doing what they've been doing so far, > that is leave it at "origin"? I'm not sure this would be my concern > as a user of this feature. That answer can be thrown back at you. You can leave it at "origin" when using "--bare" ;-). The posted patch is a good first step to allow both options to be used at the same time. Without the first step, these two options cannot coexist. But I am also saying that the first step alone is an inadequate solution that goes only halfway. If you can get yourfavouritename, while others cannot use their favourite names, that is not a satisfying solution.
