Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> On the client side, Git will always send the "unborn" argument if it is >> supported by the server. During "git clone", if cloning an empty >> repository, Git will use the new information to determine the local >> branch to create. In all other cases, Git will ignore it. > > I'm not a fan of this change not because of the whole s/master/whatever/ > discussion, but because of the magic it adds for seemingly little gain & > without any documentation. > > So if I have init.defaultBranch explicitly set that'll be ignored on > "clone", but on "init/git remote add/fetch" it won't? That description is backwards. To help interoperate with the repository you cloned from better, we made it easy to use whatever your 'origin' uses. "git clone" does so by (1) in the original implementation, by inferring where HEAD points at over there by comparing the objects reported for HEAD and tips of branches (2) later, by adding symref capability to the protocl so that the sending repository can tell exactly which branch its HEAD points at. What was lacking was that symref capability is not sent if there is nothing in the repository. And I think this is an attempt to bring that "cloning nothing" case in line with a clone of a repository with contents. > Shouldn't this at the very least be a > init.defaultBranchFromRemote=<bool> which if set overrides > init.defaultBranch? We could turn that to "true" by default and get the > same behavior as you have here, but with less inexplicable magic for the > user, no? I view the change in the patch being discussed a bugfix (clone ought to follow whatever the other side uses by default, unless you say -b, and the case when cloning an empty repository was buggy). I am OK if we wanted to consider a _new_ feature to always use the name you want locally (i.e. as if you added "-b $(git config init.defaultBranch)" on your "git clone" command line), but that is a new feature that needs to be discussed in a separate topic. > Another reason I'm not a fan of it is because it's another piece of > magic "clone" does that you can't emulate in "init/fetch". That ship has sailed longlonglong time ago when dfeff66e (revamp git-clone., 2006-03-20) started pointing our HEAD to match theirs. > But shouldn't there at least be a corresponding "fetch" option? On init > we'll create head, but "git fetch --clobber-my-idea-of-HEAD-with-remote > ..."? It may be nice to have a corresponding one, but again, that is a separate topic on a new feature, and not relevant in the context of this fix. > Maybe not for reasons I haven't thought of, but I'd at least be much > happier with an updated commit message justifying another special-case > in clone that you can't do with "init/fetch". This is *not* another special-case, but is 14-year old outstanding one, so I do not think there specifically needs such justification. The log message DOES need to be clarified. Your mistaking that this is a new feature and not a bugfix may be a good indication that the proposed log message is not doing its job. > And on the "litte gain" side of things: I very much suspect that the > only users who'll ever use this will be some big hosting providers (but > maybe not, the commit doesn't suggest a use-case). Explorers who learn this new GitHub or GitLab thingy, create an empty repository there and then clone it to their local disk, just to dip their toes in the water, would most benefit. Those of us who are working on an already existing and populated projects won't be helped or bothered. We do sometimes create our own repositories and publish to hosting sites, and I expect that many experienced Git users follow the "local first and the push", and they won't be helped or bothered. But I expect some do "create a void at the hosting site and clone to get a local playpen" for their real projects. They would be helped, and because Git userbase is populous enough that their number in absolute terms would not be insignificant, even if they weren't in percentage terms.
