Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-11-20t7[5-9]*: adjust the references to the default branch name "main"Johannes Schindelin
Excluding t7817, which is added in an unrelated patch series at the time of writing, this adjusts t7[5-9]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t7[5-9]*.sh) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-20tests: mark tests relying on the current default for `init.defaultBranch`Johannes Schindelin
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Revert "fmt-merge-msg: stop treating `master` specially"Junio C Hamano
This reverts commit 489947cee5095b168cbac111ff7bd1eadbbd90dd, which stopped treating merges into the 'master' branch as special when preparing the default merge message. As the goal was not to have any single branch designated as special, it solved it by leaving the "into <branchname>" at the end of the title of the default merge message for any and all branches. An obvious and easy alternative to treat everybody equally could have been to remove it for every branch, but that involves loss of information. We'll introduce a new mechanism to let end-users specify merges into which branches would omit the "into <branchname>" from the title of the default merge message, and make the mechanism, when unconfigured, treat the traditional 'master' special again, so all the changes to the tests we made earlier will become unnecessary, as these tests will be run without configuring the said new mechanism. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24fmt-merge-msg: stop treating `master` speciallyJohannes Schindelin
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: notice local merging of tags and keep it unwrappedJunio C Hamano
This also updates the autogenerated merge title message from "merge commit X" to "merge tag X", and its effect can be seen in the changes to the test suite. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeMatthieu Moy
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09merge: indicate remote tracking branches in merge messageJeff King
Previously when merging directly from a local tracking branch like: git merge origin/master The merge message said: Merge commit 'origin/master' * commit 'origin/master': ... Instead, let's be more explicit about what we are merging: Merge remote branch 'origin/master' * origin/master: ... We accomplish this by recognizing remote tracking branches in git-merge when we build the simulated FETCH_HEAD output that we feed to fmt-merge-msg. In addition to a new test in t7608, we have to tweak the expected output of t3409, which does such a merge. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09merge: fix incorrect merge message for ambiguous tag/branchJeff King
If we have both a tag and a branch named "foo", then calling "git merge foo" will warn about the ambiguous ref, but merge the tag. When generating the commit message, though, we simply checked whether "refs/heads/foo" existed, and if it did, assumed it was a branch. This led to the statement "Merge branch 'foo'" in the commit message, which is quite wrong. Instead, we should use dwim_ref to find the actual ref used, and describe it appropriately. In addition to the test in t7608, we must also tweak the expected output of t4202, which was accidentally triggering this bug. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09add tests for merge message headingsJeff King
When calling "git merge $X", we automatically generate a commit message containing something like "Merge branch '$X'". This test script checks that those messages say what they should, and exposes a failure when merging a refname that is ambiguous between a tag and a branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>