On Wed Sep 11, 2024 at 00:29, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Bence Ferdinandy <bence@xxxxxxxxxxxxxx> writes: > > > What is missing for sure is: > > - documentation > > - tests (if needed) > > What change does not need tests? Fair enough, for the next iteration I'll look into tests as well! > > > - settings > > > > For settings, my idea would be a fetch/remote.set_head that could take three values: > > * never > > * missing: run it only if the ref is missing, this setting would basically > > allow replicating the result of a clone > > * always (with the other patch, this would still be a no-op if it didn't change) > > > > This would probably also require a --no-set-head flag, to disable an > > always/missing setting. A --missing-set-head or something of the like also may > > or may not make sense. Alternatively, only two behaviours might be enough > > (missing and always) since clone already sort of does this. > > If we were to assume "always" is needed, then the tristate like the > above may be a reasonable way to go. > > But as I outlined in my response to [1/2], I suspect that an > approach without configuration or command line option would give the > users the most smooth experience. They are used to seeing "clone" > to give them a remote tracking HEAD and nobody complained that we > lack the option to "clone" to prevent that. If "fetch" notices we > do not have remote tracking HEAD for a remote [*] and stores what it > observed at their HEAD in remote tracking HEAD, that should not > bother anybody. No matter what mechanism gave you the initial > remote tracking HEAD, if you want to update it to something else, we > already have the "remote set-head" command. So I guess we did conclude that no settings are actually needed. > > > [Footnote] > > * One thing we MUST be careful about is that some remotes may not > have ANY remote tracking branches (i.e. you only want to use the > remote mechanism to give you a shorthand for URL, but you do not > have fetch refspec at all). Even if refs/remotes/$repo/HEAD is > missing for such a remote, we should *not* attempt to create it, > as we are not populating refs/remotes/$repo/master and friends at > all in such a case. You mean that somebody does git init && git remote add origin $remote, but never does calls fetch? Currently remote set-head -a origin will fail with error: Not a valid ref: refs/remotes/origin/master Although if everything is done _after_ a fetch, unless I misunderstood, we shouldn't be able to be in this situation at all. Best, Bence
