Bence Ferdinandy <bence@xxxxxxxxxxxxxx> writes: > What is missing for sure is: > - documentation > - tests (if needed) What change does not need tests? > - 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. [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.
