kernel/git - git - PowerEL Git System

29886 Commits

6 Branches

36 Tags

131 MiB

Tree: e62cd35a3e

Commit Graph

Author	SHA1	Message	Date
Joey Hess	96890f4c42	write first for-merge ref to FETCH_HEAD first The FETCH_HEAD refname is supposed to refer to the ref that was fetched and should be merged. However all fetched refs are written to .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply takes the first ref as the FETCH_HEAD, which is often the wrong one, when other branches were also fetched. The solution is to write the for-merge ref(s) to FETCH_HEAD first. Then, unless --append is used, the FETCH_HEAD refname behaves as intended. If the user uses --append, they presumably are doing so in order to preserve the old FETCH_HEAD. While we are at it, update an old example in the read-tree documentation that implied that each entry in FETCH_HEAD only has the object name, which is not true for quite a while. [jc: adjusted tests] Signed-off-by: Joey Hess <joey@kitenet.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Linus Torvalds	7a2b128d13	fetch: do not store peeled tag object names in FETCH_HEAD We do not want to record tags as parents of a merge when the user does "git pull $there tag v1.0" to merge tagged commit, but that is not a good enough excuse to peel the tag down to commit when storing in FETCH_HEAD. The caller of underlying "git fetch $there tag v1.0" may have other uses of information contained in v1.0 tag in mind. [jc: the test adjustment is to update for the new expectation] Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Santi Béjar	ac3ec0d555	t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

Author

SHA1

Message

Date

Joey Hess

96890f4c42

write first for-merge ref to FETCH_HEAD first

The FETCH_HEAD refname is supposed to refer to the ref that was fetched
and should be merged. However all fetched refs are written to
.git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply
takes the first ref as the FETCH_HEAD, which is often the wrong one,
when other branches were also fetched.

The solution is to write the for-merge ref(s) to FETCH_HEAD first.
Then, unless --append is used, the FETCH_HEAD refname behaves as intended.
If the user uses --append, they presumably are doing so in order to
preserve the old FETCH_HEAD.

While we are at it, update an old example in the read-tree documentation
that implied that each entry in FETCH_HEAD only has the object name, which
is not true for quite a while.

[jc: adjusted tests]

Signed-off-by: Joey Hess <joey@kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Linus Torvalds

7a2b128d13

fetch: do not store peeled tag object names in FETCH_HEAD

We do not want to record tags as parents of a merge when the user does
"git pull $there tag v1.0" to merge tagged commit, but that is not a good
enough excuse to peel the tag down to commit when storing in FETCH_HEAD.
The caller of underlying "git fetch $there tag v1.0" may have other uses
of information contained in v1.0 tag in mind.

[jc: the test adjustment is to update for the new expectation]

Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Santi Béjar

ac3ec0d555

t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch

Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

18 years ago

3 Commits (e62cd35a3e8f5baf42f5cd972ff3b9f9834269c7)