Re: git switch has fatal dependency on default fetch config

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

 



On Tue, Dec 05, 2023 at 07:41:28PM -0800, Jeremiah Steele (Jerry) wrote:

> Changing the default fetch refspec for a remote breaks git switch:
> 
> % git branch -r
>   origin/HEAD -> origin/master
>   origin/feature
>   origin/master
> % git remote set-branches origin master
> % git switch -c feature --track origin/feature
> fatal: cannot set up tracking information; starting point 'origin/feature' is not a branch
> % git remote set-branches --add origin feature
> % git switch -c feature --track origin/feature
> branch 'feature' set up to track 'origin/feature'.
> Switched to a new branch 'feature'
> 
> It seems like I should be able to fetch a remote branch and track it
> without having to monkey around with my default fetch config. Is there
> a reason git switch has a hard dependency on the default remote fetch
> refspec configuration?

I think it's required by the form of the tracking config, which is
defined by a named remote and a remote branch, like:

  [branch "foo"]
  remote = origin
  merge = refs/heads/foo

You explicitly asked to track "origin/feature", which means that Git has
to be able to turn that into config as above. It can handle two cases:

  1. It's a local branch in refs/heads/, in which case the remote is "."
     and the "merge" field is the name of the branch.

  2. It's a ref that can be found by reversing a fetch refspec. With the
     default remote.origin.fetch refspec of refs/heads/*:refs/remotes/origin/*,
     we know that "refs/remotes/origin/feature" comes from "refs/heads/feature"
     on the "origin" remote.

     But since you used "remote set-branches" to limit that refspec, we
     can't do that same reversal. And "origin/feature", while we do
     still have it as a ref, does not correspond to any remote ref we'd
     fetch. So we don't know how to set up the tracking config.

The notion of "tracking" really came about as defining what "git pull"
does. And without a remote that fetches, "git pull" does not really make
much sense.

I'd guess that you are more interested in being able to just use
@{upstream}, especially as the default for things like rebase, etc. And
that could work without being able to actually fetch the ref. But those
two things are intertwined in Git. You obviously can still base a branch
off of "origin/feature", but you'll have to specify it manually when
doing rebase, etc.

-Peff




[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