Why can't Git resolve remote branches when --single-branch is used?Check whether a branch will be fetched and allowed to be checked-outHow to clone all remote branches in Git?How to resolve merge conflicts in GitMake an existing Git branch track a remote branch?Delete commits from a branch in GitHow do you create a remote Git branch?Move the most recent commit(s) to a new branch with GitHow do I check out a remote Git branch?How do I delete a Git branch locally and remotely?How do I push a new local branch to a remote Git repository and track it too?How do I rename a local Git branch?
Is a request to book a business flight ticket for a graduate student an unreasonable one?
Should disabled buttons give feedback when clicked?
Indesign - how to change the style of the page numbers?
Salt, pepper, herbs and spices
Would dual wielding daggers be a viable choice for a covert bodyguard?
This one's for Matthew:
Received a dinner invitation through my employer's email, is it ok to attend?
Why isn't pressure filtration popular compared to vacuum filtration?
Managing and organizing the massively increased number of classes after switching to SOLID?
Single word for "refusing to move to next activity unless present one is completed."
OR-backed serious games
Is "I do not want you to go nowhere" a case of "DOUBLE-NEGATIVES" as claimed by Grammarly?
What happens to unproductive professors?
How can I fix the dull colors I am getting in Ubuntu 19.04 Terminal?
What is the measurable difference between dry basil and fresh?
How can I effectively communicate to recruiters that a phone call is not possible?
Why do we need common sense in AI?
What specific instant in time in the MCU has been depicted the most times?
Why did Harry Potter get a bedroom?
Why are they 'nude photos'?
Extracting points from 3D plot that lie along an arbitrarily oriented line
What is this little owl-like bird?
How do you move up one folder in Finder?
Why is the ladder of the LM always in the dark side of the LM?
Why can't Git resolve remote branches when --single-branch is used?
Check whether a branch will be fetched and allowed to be checked-outHow to clone all remote branches in Git?How to resolve merge conflicts in GitMake an existing Git branch track a remote branch?Delete commits from a branch in GitHow do you create a remote Git branch?Move the most recent commit(s) to a new branch with GitHow do I check out a remote Git branch?How do I delete a Git branch locally and remotely?How do I push a new local branch to a remote Git repository and track it too?How do I rename a local Git branch?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
So, we frequently optimize clones by effectively cloning with --single-branch. However, we are then unable to get additional branches later. What is the difference, plumbing-wise, between a git clone with and without --single-branch? How can we fetch down additional branches later?
A standard clone:
$ git clone -b branch-name https://repo.url standard
$ cd standard
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
A single-branch clone:
$ git clone -b branch-name --single-branch https://repo.url singlebranch
$ cd singlebranch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
UPDATE
Per the answer from @AndrewMarshall, below, you need to update the default fetch refspec in the config. Even though you can hack your way around the fetch to pull down the right commits, your attempted checkout will absolutely deny knowing anything about that branch if you don't fix your config first:
$ git fetch origin +refs/heads/remote-branch:refs/remotes/origin/remote-branch
From https://gerrit.magicleap.com/a/platform/mlmanifest
* [new branch] remote-branch -> origin/remote-branch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
$ git remote set-branches origin --add remote-branch
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
Notice we fetch it, then reconfigure, then checkout. The fetch can happen in any order (though you have to pass parameters if not in the config) but the checkout is gated by the config.
git
add a comment |
So, we frequently optimize clones by effectively cloning with --single-branch. However, we are then unable to get additional branches later. What is the difference, plumbing-wise, between a git clone with and without --single-branch? How can we fetch down additional branches later?
A standard clone:
$ git clone -b branch-name https://repo.url standard
$ cd standard
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
A single-branch clone:
$ git clone -b branch-name --single-branch https://repo.url singlebranch
$ cd singlebranch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
UPDATE
Per the answer from @AndrewMarshall, below, you need to update the default fetch refspec in the config. Even though you can hack your way around the fetch to pull down the right commits, your attempted checkout will absolutely deny knowing anything about that branch if you don't fix your config first:
$ git fetch origin +refs/heads/remote-branch:refs/remotes/origin/remote-branch
From https://gerrit.magicleap.com/a/platform/mlmanifest
* [new branch] remote-branch -> origin/remote-branch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
$ git remote set-branches origin --add remote-branch
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
Notice we fetch it, then reconfigure, then checkout. The fetch can happen in any order (though you have to pass parameters if not in the config) but the checkout is gated by the config.
git
I recommend avoiding--single-branch
in general (also avoid--shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.
– torek
Mar 26 at 5:38
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparingmaster
to some development branch, stop working. Using--depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!
– torek
Mar 27 at 7:02
add a comment |
So, we frequently optimize clones by effectively cloning with --single-branch. However, we are then unable to get additional branches later. What is the difference, plumbing-wise, between a git clone with and without --single-branch? How can we fetch down additional branches later?
A standard clone:
$ git clone -b branch-name https://repo.url standard
$ cd standard
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
A single-branch clone:
$ git clone -b branch-name --single-branch https://repo.url singlebranch
$ cd singlebranch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
UPDATE
Per the answer from @AndrewMarshall, below, you need to update the default fetch refspec in the config. Even though you can hack your way around the fetch to pull down the right commits, your attempted checkout will absolutely deny knowing anything about that branch if you don't fix your config first:
$ git fetch origin +refs/heads/remote-branch:refs/remotes/origin/remote-branch
From https://gerrit.magicleap.com/a/platform/mlmanifest
* [new branch] remote-branch -> origin/remote-branch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
$ git remote set-branches origin --add remote-branch
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
Notice we fetch it, then reconfigure, then checkout. The fetch can happen in any order (though you have to pass parameters if not in the config) but the checkout is gated by the config.
git
So, we frequently optimize clones by effectively cloning with --single-branch. However, we are then unable to get additional branches later. What is the difference, plumbing-wise, between a git clone with and without --single-branch? How can we fetch down additional branches later?
A standard clone:
$ git clone -b branch-name https://repo.url standard
$ cd standard
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
A single-branch clone:
$ git clone -b branch-name --single-branch https://repo.url singlebranch
$ cd singlebranch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
UPDATE
Per the answer from @AndrewMarshall, below, you need to update the default fetch refspec in the config. Even though you can hack your way around the fetch to pull down the right commits, your attempted checkout will absolutely deny knowing anything about that branch if you don't fix your config first:
$ git fetch origin +refs/heads/remote-branch:refs/remotes/origin/remote-branch
From https://gerrit.magicleap.com/a/platform/mlmanifest
* [new branch] remote-branch -> origin/remote-branch
$ git checkout remote-branch
error: pathspec 'remote-branch' did not match any file(s) known to git
$ git remote set-branches origin --add remote-branch
$ git checkout remote-branch
Branch 'remote-branch' set up to track remote branch 'remote-branch' from 'origin'.
Switched to a new branch 'remote-branch'
Notice we fetch it, then reconfigure, then checkout. The fetch can happen in any order (though you have to pass parameters if not in the config) but the checkout is gated by the config.
git
git
edited Mar 26 at 2:46
Dustin Oprea
asked Mar 26 at 1:47
Dustin OpreaDustin Oprea
5,1755 gold badges46 silver badges75 bronze badges
5,1755 gold badges46 silver badges75 bronze badges
I recommend avoiding--single-branch
in general (also avoid--shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.
– torek
Mar 26 at 5:38
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparingmaster
to some development branch, stop working. Using--depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!
– torek
Mar 27 at 7:02
add a comment |
I recommend avoiding--single-branch
in general (also avoid--shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.
– torek
Mar 26 at 5:38
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparingmaster
to some development branch, stop working. Using--depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!
– torek
Mar 27 at 7:02
I recommend avoiding
--single-branch
in general (also avoid --shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.– torek
Mar 26 at 5:38
I recommend avoiding
--single-branch
in general (also avoid --shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.– torek
Mar 26 at 5:38
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparing
master
to some development branch, stop working. Using --depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!– torek
Mar 27 at 7:02
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparing
master
to some development branch, stop working. Using --depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!– torek
Mar 27 at 7:02
add a comment |
1 Answer
1
active
oldest
votes
--single-branch
works by setting the remote’s fetch
property to only be the single branch name, instead of a glob:
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
So let’s add an entry with git remote set-branches
:
$ git remote set-branches origin --add other-branch
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
+refs/heads/other-branch:refs/remotes/origin/other-branch
$ git fetch
From origin
* [new branch] other-branch -> origin/other-branch
$ git checkout other-branch
Branch 'other-branch' set up to track remote branch 'other-branch' from 'origin'.
Switched to a new branch 'other-branch'
Or, alternatively, make it a glob so all branches may be fetched (the default, non-single-branch behavior):
git remote set-branches origin '*'
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g.git fetch other-branch
),git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).
– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.git checkout other-branch origin/other-branch
), rather than lettinggit-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).
– Andrew Marshall
Mar 26 at 2:51
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55348731%2fwhy-cant-git-resolve-remote-branches-when-single-branch-is-used%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
--single-branch
works by setting the remote’s fetch
property to only be the single branch name, instead of a glob:
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
So let’s add an entry with git remote set-branches
:
$ git remote set-branches origin --add other-branch
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
+refs/heads/other-branch:refs/remotes/origin/other-branch
$ git fetch
From origin
* [new branch] other-branch -> origin/other-branch
$ git checkout other-branch
Branch 'other-branch' set up to track remote branch 'other-branch' from 'origin'.
Switched to a new branch 'other-branch'
Or, alternatively, make it a glob so all branches may be fetched (the default, non-single-branch behavior):
git remote set-branches origin '*'
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g.git fetch other-branch
),git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).
– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.git checkout other-branch origin/other-branch
), rather than lettinggit-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).
– Andrew Marshall
Mar 26 at 2:51
|
show 1 more comment
--single-branch
works by setting the remote’s fetch
property to only be the single branch name, instead of a glob:
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
So let’s add an entry with git remote set-branches
:
$ git remote set-branches origin --add other-branch
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
+refs/heads/other-branch:refs/remotes/origin/other-branch
$ git fetch
From origin
* [new branch] other-branch -> origin/other-branch
$ git checkout other-branch
Branch 'other-branch' set up to track remote branch 'other-branch' from 'origin'.
Switched to a new branch 'other-branch'
Or, alternatively, make it a glob so all branches may be fetched (the default, non-single-branch behavior):
git remote set-branches origin '*'
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g.git fetch other-branch
),git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).
– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.git checkout other-branch origin/other-branch
), rather than lettinggit-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).
– Andrew Marshall
Mar 26 at 2:51
|
show 1 more comment
--single-branch
works by setting the remote’s fetch
property to only be the single branch name, instead of a glob:
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
So let’s add an entry with git remote set-branches
:
$ git remote set-branches origin --add other-branch
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
+refs/heads/other-branch:refs/remotes/origin/other-branch
$ git fetch
From origin
* [new branch] other-branch -> origin/other-branch
$ git checkout other-branch
Branch 'other-branch' set up to track remote branch 'other-branch' from 'origin'.
Switched to a new branch 'other-branch'
Or, alternatively, make it a glob so all branches may be fetched (the default, non-single-branch behavior):
git remote set-branches origin '*'
--single-branch
works by setting the remote’s fetch
property to only be the single branch name, instead of a glob:
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
So let’s add an entry with git remote set-branches
:
$ git remote set-branches origin --add other-branch
$ git config --get-all remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master
+refs/heads/other-branch:refs/remotes/origin/other-branch
$ git fetch
From origin
* [new branch] other-branch -> origin/other-branch
$ git checkout other-branch
Branch 'other-branch' set up to track remote branch 'other-branch' from 'origin'.
Switched to a new branch 'other-branch'
Or, alternatively, make it a glob so all branches may be fetched (the default, non-single-branch behavior):
git remote set-branches origin '*'
answered Mar 26 at 2:12
Andrew MarshallAndrew Marshall
81.7k17 gold badges189 silver badges197 bronze badges
81.7k17 gold badges189 silver badges197 bronze badges
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g.git fetch other-branch
),git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).
– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.git checkout other-branch origin/other-branch
), rather than lettinggit-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).
– Andrew Marshall
Mar 26 at 2:51
|
show 1 more comment
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g.git fetch other-branch
),git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).
– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.git checkout other-branch origin/other-branch
), rather than lettinggit-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).
– Andrew Marshall
Mar 26 at 2:51
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
If I could give you a thousand points for such a prompt, concise answer, I would.
– Dustin Oprea
Mar 26 at 2:14
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
You're right. Didn't think about that. So, is the refspec provided to git-fetch just a filter on what we're already auditing for that remote?
– Dustin Oprea
Mar 26 at 2:17
It seems two-fold:
git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g. git fetch other-branch
), git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).– Andrew Marshall
Mar 26 at 2:22
It seems two-fold:
git-fetch
uses the configured refspecs by default when asking the remote, and, when a refspec is given explicitly (e.g. git fetch other-branch
), git-fetch
will only create/update a local ref to match the remote if it’s configured (as otherwise it doesn’t know what local ref to create/update).– Andrew Marshall
Mar 26 at 2:22
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
Actually, it looks like the checkout is also constrained by it. You can pass the value you suggested directly, and fetch brings it down. However, checkout will still staunchly refuse to cooperate. See the example in my addendum above.
– Dustin Oprea
Mar 26 at 2:39
It would probably work if you gave the ref itself (e.g.
git checkout other-branch origin/other-branch
), rather than letting git-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).– Andrew Marshall
Mar 26 at 2:51
It would probably work if you gave the ref itself (e.g.
git checkout other-branch origin/other-branch
), rather than letting git-checkout
try and figure it out for itself (in which case it will use the fetch config (docs)).– Andrew Marshall
Mar 26 at 2:51
|
show 1 more comment
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55348731%2fwhy-cant-git-resolve-remote-branches-when-single-branch-is-used%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I recommend avoiding
--single-branch
in general (also avoid--shallow
in general). It's OK for very specific cases, but if you actually plan to use the repository, just go ahead and make a full clone. It's painful once, at the start, if the repository is big; after that, subsequent fetches are generally pretty light weight.– torek
Mar 26 at 5:38
That makes sense for developer systems but less sense for ephemeral build workspaces.
– Dustin Oprea
Mar 27 at 6:52
Yes—although it turns out that when Jenkins, for instance, makes shallow clones (which are also single-branch clones), some sensible ideas, such as comparing
master
to some development branch, stop working. Using--depth=50
makes for even more mysterious failures: almost all builds work, but then some don't, and it takes a long time to realize that it is long commit chains that are breaking!– torek
Mar 27 at 7:02