1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-13 20:53:02 +01:00
Commit graph

3 commits

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>
2012-01-03 16:13:14 -08:00
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>
2011-11-04 21:40:25 -07:00
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>
2007-03-05 00:27:37 -08:00