Why "git fetch origin branch:branch" works only on a non-current branch?
The error message comes from builtin/fetch.c#check_not_current_branch()
.
That function goes all the way back to commit 8ee5d73, Oct. 2008, git 1.6.0.4
The comment is instructive:
Some confusing tutorials suggested that it would be a good idea to fetch into the current branch with something like this:
git fetch origin master:master
(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically is plain wrong when the current branch is "master
".
This should only be allowed when (an incorrect) "git pull origin master:master
" tries to work around by giving--update-head-ok
to underlying "git fetch
", and otherwise we should refuse it, but somewhere along the lines we lost that behavior.The check for the current branch is now only performed in non-bare repositories, which is an improvement from the original behaviour.
Considering that the function check_not_current_branch()
is called with:
if (!update_head_ok)
check_not_current_branch(ref_map);
That means a git fetch -u origin develop:develop
should work.
-u
--update-head-ok
By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check.
This is purely for the internal use forgit pull
to communicate withgit fetch
, and unless you are implementing your own Porcelain you are not supposed to use it.
Even though you are not supposed to use that option, it does answer your initial requirement, making “git fetch origin branch:branch
” work on a current branch.
Regarding the origin of this patch, follow the discussion there.
While it might make sense to store what you want to pull
That is the fetch
part: it stores the remote history from the updated origin/master
.
But that is especially broken when the current local branch is also master
.
As mentioned in this answer:
I think "
git fetch url side:master
" whenmaster
is the current branch and we have omitted--update-head-ok
is broken.
The test fails on currentmaster
.It would also fail to update the working directory and would leave the index as if you're removing everything.
See "git pull
with refspec" as an example.
torek shows an example where:
suppose that I run git fetch and it brings in two new commits that I will label
C
andD
.
C
's parent isA
, andD
's is the node just beforeB
:C / ...--o--o--A <-- master \ o--B <-- develop \ D
The output from this git fetch will list this as:
aaaaaaa..ccccccc master -> origin/master + bbbbbbb...ddddddd develop -> origin/develop (forced update)
That forced update might be what you want if your current branch is not develop
.
But if you are on develop
when you type git fetch origin develop:develop
, and if the fetch was allowed to update HEAD, ... then your current index would reflect D
, and no longer B
.
So a git diff
done in your working tree would show differences between your files and D
, not your previous HEAD B
.
That is bad, because your initial git checkout develop
created a working tree identical to B
HEAD files.
Even if your git status
was clean (no modification of any kind), if git fetch origin develop:develop
updated HEAD (forcing an update from B to D), git status
would now report differences where there were none before the fetch.
That is why, by default git fetch
refuses to update the head which corresponds to the current branch.
Note: a bug in Git 2.29 also triggers a similar error message.
When "git commit-graph
"(man) detects the same commit recorded more than once while it is merging the layers, it used to die.
The code now ignores all but one of them and continues, fixed in Git 2.30 (Q1 2021).
See commit 85102ac, commit 150f115 (09 Oct 2020) by Derrick Stolee (derrickstolee
).
(Merged by Junio C Hamano -- gitster
-- in commit 307a53d, 02 Nov 2020)
commit-graph
: ignore duplicates when merging layersReported-by: Thomas Braun
Helped-by: Taylor Blau
Co-authored-by: Jeff King
Signed-off-by: Derrick Stolee
Thomas reported that a "
git fetch
"(man) command was failing with an error saying "unexpected duplicate commit id".$ git fetch origin +refs/head/abcd:refs/remotes/origin/abcd fatal: unexpected duplicate commit id 31a13139875bc5f49ddcbd42b4b4d3dc18c16576
The root cause is that they had
fetch.writeCommitGraph
enabled which generatescommit-graph
chains, and this instance was merging two layers that both contained the same commit ID.The initial assumption is that Git would not write a commit ID into a
commit-graph
layer if it already exists in a lowercommit-graph
layer.
Somehow, this specific case did get into that situation, leading to this error.While unexpected, this isn't actually invalid (as long as the two layers agree on the metadata for the commit). When we parse a commit that does not have a
graph_pos
in thecommit_graph_data_slab,
we use binary search in thecommit-graph
layers to find the commit and setgraph_pos
.
That position is never used again in this case. However, when we parse a commit from thecommit-graph
file, we load its parents from thecommit-graph
and assigngraph_pos
at that point.
If those parents were already parsed from thecommit-graph
, then nothing needs to be done. Otherwise, thisgraph_pos
is a valid position in thecommit-graph
so we can parse the parents, when necessary.Thus, this
die()
is too aggressive. The easiest thing to do would be to ignore the duplicates.If we only ignore the duplicates, then we will produce a commit-graph that has identical commit IDs listed in adjacent positions. This excess data will never be removed from the
commit-graph
, which could cascade into significantly bloated file sizes.Thankfully, we can collapse the list to erase the duplicate commit pointers. This allows us to get the end result we want without extra memory costs and minimal CPU time.
The root cause is due to disabling
core.commitGraph
, which prevents parsing commits from the lower layers during a 'git commit-graph write --split
(man)' command.
Since we use the 'graph_pos
' value to determine whether a commit is in a lower layer, we never discover that those commits are already in thecommit-graph
chain and add them to the top layer. This layer is then merged down, creating duplicates.The test added in
t5324-split-commit-graph.sh
fails without this change. However, we still have not completely removed the need for this duplicate check. That will come in a follow-up change.
And:
commit-graph
: don't write commit-graph when disabledReported-by: Thomas Braun
Helped-by: Jeff King
Helped-by: Taylor Blau
Signed-off-by: Derrick Stolee
The
core.commitGraph
config setting can be set to 'false
' to prevent parsing commits from thecommit-graph
file(s). This causes an issue when trying to write with "--split
" which needs to distinguish between commits that are in the existingcommit-graph
layers and commits that are not.
The existing mechanism usesparse_commit()
and follows by checking if there is a 'graph_pos
' that shows the commit was parsed from thecommit-graph
file.When
core.commitGraph=false
, we do not parse the commits from thecommit-graph
and 'graph_pos
' indicates that no commits are in the existing file.
The--split
logic moves forward creating a new layer on top that holds all reachable commits, then possibly merges down into those layers, resulting in duplicate commits. The previous change makes that merging process more robust to such a situation in case it happens in the writtencommit-graph
data.The easy answer here is to avoid writing a
commit-graph
if reading the commit-graph is disabled. Since the resultingcommit-graph
will would not be read by subsequent Git processes. This is more natural than forcingcore.commitGraph
to betrue
for the 'write
' process.
git commit-graph
now includes in its man page:
Write a
commit-graph
file based on the commits found in packfiles. If the config optioncore.commitGraph
is disabled, then this command will output a warning, then return success without writing acommit-graph
file.