Re: [PATCH v2] clone: Allow combining --bare and --origin
- From
- Roman Neuhauser <rn+git@sigpipe.cz>
- Date
- Aug 6, 2021, 20:23 UTC
- Message-ID
- <YQ2aXpfzyOOUFhQk@isis.sigpipe.cz>
- In-Reply-To
- <xmqqbl6dqgvc.fsf@gitster.g>
Hello,
i'm "the user" in this story. Muchas gracias to osse for turning my bickering into a patch.
A little background. I use --origin a lot (or git remmote rename afterwards), because origin carries no information about the remote repository, and I could have cloned any of those. The URL I used in `git clone` has little to do with which remotes I'll want to pull from and which I'll want to push to. "origin" is suspicious and I'm used to giving my remotes names that mean something to me.
My need for git clone --bare --origin surfaced when I was writing a tool for versioning dotfiles (don't we all have one). It has to be able to work with pre-existing files in the home dir:
$ git dirs clone $url x # git-dir is $PWD/.git-dirs/repo.d/x # work-tree is $PWD
I used git clone --bare / git config core.bare false / git config core.worktree ... and hit the error message when I tried to add support for --origin.
# gitster@pobox.com / 2021-08-04 10:06:31 -0700:
> In other words, if there were two remotes in the configuration file, > you cannot tell which one was given to --origin when you made the > repository with "git clone".
I'm not sure why this matters (not saying it doesn't).
Show 7 quoted lines
> 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? BTW I don't like special cases but realize that the "origin" ship has sailed long ago.
> Some people may want to treat yourfavouritename is not special at > all, while some people may want to treat yourfavouritename truly as > a replacement for 'origin' that is the default. The message we > would be sending is that we'd ignore the latter folks.
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.
-- roman