Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I.e. this feature seems like a candidate to be exposed by something like > by a ls-remote flag if you'd like to do an init/config/fetch. AFAIK the > only way to do it is to mock a "clone" with GIT_TRACE_PACKET or get the > information out-of-bounds. Yes, I think the updated protocol should be able to help adding a new feature usable by script writers, and I agree that ls-remote may be the ideal home for such a feature. > To borrow from Felipe Contreras's reply in the side-thread "I expect the > branch name to be chosen by the person who created that repository". I expect a bit differently. My expectation is that "git clone" tries to help you inter-operate well with the project you clone. You may be creating your local repository by cloning theirs, but because I do not expect "who created" matters more than how well end-users' workflows would work in the resulting repository, I do not expect local init.defaultBranch should matter here. If the project you would eventually push back to designates one branch as its primary branch everybody is expected to work off of (which is what it means to point it with their HEAD), it is convenient if your local clone names your primary branch to match. The push.default settings like 'simple' and 'current' are designed to work well when your local branch namespace matches what they have. > I suppose this comes down to a mental model of what it means to have > "created a repository". When I click "create repo" on those popular > hosting sites (e.g. github & gitlab) and clone it I was expecting it to > just be a shorthand init + a URL in my config (and refspecs...). So, no, I do not think "who created a repository" has much to do with the objective of the patch in question. It's really "what's the upstream's view of the primary branch". > That's also what happens with this patch if you "git init --bare > /tmp/my.git", then edit the HEAD symref to point to "foobar" and clone > it with file:///, it'll be "master" in your clone (or whatever > init.defaultBranch is). Isn't that discrepancy a bug then? Yes, I view it as the same bug to be fixed; JTan's protocol update patch only deals with the transport based on the git protocol and does not (yet?) address the --local short-cut. In principle, it should be a lot easier than the protocol update. Any takers? > On both of those big hosting sites (didn't test others) whatever their > preferred default name is they'll go with your idea and update HEAD's > pointer on the first such push. So this notion that the default unborn > symref isn't transported & it's up to the client to set it on-push (or > manually afterwards) has been reinforced by in-the-wild use. I think it would be great if somebody comes up with a protocol update for that "other" direction to push into an unborn HEAD. I haven't thought things through, but you may be right to point out that the "clone learns and prepares local to match the other side" we are discussing may not be complete with such a corresponding fix in the opposite direction. Thanks.
