summaryrefslogtreecommitdiff
path: root/t/t5515/fetch.br-config-glob-octopus_config-glob
Commit message (Collapse)AuthorAgeFilesLines
* write first for-merge ref to FETCH_HEAD firstjh/fetch-head-updateJoey Hess2012-01-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* fetch: do not store peeled tag object names in FETCH_HEADLinus Torvalds2011-11-041-3/+3
| | | | | | | | | | | | 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>
* Make fetch a builtinDaniel Barkalow2007-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | Thanks to Johannes Schindelin for review and fixes, and Julian Phillips for the original C translation. This changes a few small bits of behavior: branch.<name>.merge is parsed as if it were the lhs of a fetch refspec, and does not have to exactly match the actual lhs of a refspec, so long as it is a valid abbreviation for the same ref. branch.<name>.merge is no longer ignored if the remote is configured with a branches/* file. Neither behavior is useful, because there can only be one ref that gets fetched, but this is more consistant. Also, fetch prints different information to standard out. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetchSanti Béjar2007-03-051-0/+11
Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>