summaryrefslogtreecommitdiff
path: root/t/t5515/fetch.br-branches-one-octopus_branches-one
AgeCommit message (Collapse)AuthorFilesLines
2020-11-02t5515: use `main` as the name of the main branch for testing (part 2)Libravatar Johannes Schindelin1-1/+1
We just started preparing t5515 for the upcoming change of the default branch name to `main`. This patch adjusts roughly half of the supporting material in `t/t5515/` (the patch adjusting all of `t/t5515/` would have weighed more than 100kB and therefore not made it to the Git mailing list for review). Similar to what we did for the `t5515` script itself in the previous commit, this patch was generated via: sed -i -e 's/master/main/g' -e 's/Master/Main/g' \ -e 's/6c9dec2b923228c9ff994c6cfe4ae16c12408dc5/ecf3b3627b498bdcb735cc4343bf165f76964e9a/g' \ -e 's/8521c3072461fcfe8f32d67f95cc6e6b832a2db2fa29769ffc788bce85ebcd75/fff666109892bb4b1c80cd1649d2d8762a0663db8b5d46c8be98360b64fbba5f/g' \ -e 's/754b754407bf032e9a2f9d5a9ad05ca79a6b228f/b4ab76b1a01ea602209932134a44f1e6bd610832/g' \ -e 's/6c7abaea8a6d8ef4d89877e68462758dc6774690fbbbb0e6d7dd57415c9abde0/380ebae0113f877ce46fcdf39d5bc33e4dc0928db5c5a4d5fdc78381c4d55ae3/g' \ -- t/t5515/fetch.* In addition to that, we need to adjust some file _names_ in `t/t5515/` because they encode the branch name: eval "$(git ls-files t/t5515/fetch.\* | sed -n \ -e 's/\(.*\)master\(.*\)/git mv & \1main\2;/p')" Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-04fetch: do not store peeled tag object names in FETCH_HEADLibravatar Linus Torvalds1-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>
2007-09-19Correct handling of branch.$name.merge in builtin-fetchLibravatar Shawn O. Pearce1-0/+1
My prior bug fix for git-push titled "Don't configure remote "." to fetch everything to itself" actually broke t5520 as we were unable to evaluate a branch configuration of: [branch "copy"] remote = . merge = refs/heads/master as remote "." did not have a "remote...fetch" configuration entry to offer up refs/heads/master as a possible candidate available to be fetched and merged. In shell script git-fetch and prior to the above mentioned commit this was hardcoded for a url of "." to be the set of local branches. Chasing down this bug led me to the conclusion that our prior behavior with regards to branch.$name.merge was incorrect. In the shell script based git-fetch implementation we only fetched and merged a branch if it appeared both in branch.$name.merge *and* in remote.$r.fetch, where $r = branch.$name.remote. In other words in the following config file: [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master [branch "pu"] remote = origin merge = refs/heads/pu Attempting to run `git pull` while on branch "pu" would always give the user "Already up-to-date" as git-fetch did not fetch pu and thus did not mark it for merge in .git/FETCH_HEAD. The configured merge would always be ignored and the user would be left scratching her confused head wondering why merge did not work on "pu" but worked fine on "master". If we are using the "default fetch" specification for the current branch and the current branch has a branch.$name.merge configured we now union it with the list of refs in remote.$r.fetch. This way the above configuration does what the user expects it to do, which is to fetch only "master" by default but when on "pu" to fetch both "master" and "pu". This uncovered some breakage in the test suite where old-style Cogito branches (.git/branches/$r) did not fetch the branches listed in .git/config for merging and thus did not actually merge them if the user tried to use `git pull` on that branch. Junio and I discussed it on list and felt that the union approach here makes more sense to DWIM for the end-user than silently ignoring their configured request so the test vectors for t5515 have been updated to include for-merge lines in .git/FETCH_HEAD where they have been configured for-merge in .git/config. Since we are now performing a union of the fetch specification and the merge specification and we cannot allow a branch to be listed twice (otherwise it comes out twice in .git/FETCH_HEAD) we need to perform a double loop here over all of the branch.$name.merge lines and try to set their merge flag if we have already schedule that branch for fetching by remote.$r.fetch. If no match is found then we must add new specifications to fetch the branch but not store it as no local tracking branch has been designated. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-03-05t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetchLibravatar Santi Béjar1-0/+8
Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>