Re: [RFC PATCH v2 0/2] set remote/HEAD with fetch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux