2005-09-08 02:13:26 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Amos Waterland
|
|
|
|
#
|
|
|
|
|
2012-02-06 01:13:36 +00:00
|
|
|
test_description='git branch assorted tests'
|
2005-09-08 02:13:26 +00:00
|
|
|
|
2020-11-18 23:44:23 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
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-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2023-06-17 06:41:54 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2005-09-08 02:13:26 +00:00
|
|
|
. ./test-lib.sh
|
2018-04-03 14:47:15 +00:00
|
|
|
. "$TEST_DIRECTORY"/lib-rebase.sh
|
2005-09-08 02:13:26 +00:00
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'prepare a trivial repository' '
|
|
|
|
echo Hello >A &&
|
|
|
|
git update-index --add A &&
|
|
|
|
git commit -m "Initial commit." &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git branch -M main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
echo World >>A &&
|
|
|
|
git update-index --add A &&
|
|
|
|
git commit -m "Second commit." &&
|
2013-08-31 04:31:48 +00:00
|
|
|
HEAD=$(git rev-parse --verify HEAD)
|
|
|
|
'
|
2013-03-20 12:30:12 +00:00
|
|
|
|
|
|
|
test_expect_success 'git branch --help should not have created a bogus branch' '
|
2013-10-26 18:48:46 +00:00
|
|
|
test_might_fail git branch --man --help </dev/null >/dev/null 2>&1 &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_missing refs/heads/--help
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2005-09-08 02:13:26 +00:00
|
|
|
|
2023-11-02 08:47:14 +00:00
|
|
|
test_expect_success REFFILES 'branch -h in broken repository' '
|
2010-10-22 06:42:58 +00:00
|
|
|
mkdir broken &&
|
|
|
|
(
|
|
|
|
cd broken &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main &&
|
|
|
|
>.git/refs/heads/main &&
|
2010-10-22 06:42:58 +00:00
|
|
|
test_expect_code 129 git branch -h >usage 2>&1
|
|
|
|
) &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "[Uu]sage" broken/usage
|
2010-10-22 06:42:58 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'git branch abc should create a branch' '
|
2023-10-31 08:16:59 +00:00
|
|
|
git branch abc &&
|
|
|
|
test_ref_exists refs/heads/abc
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2005-11-14 22:10:59 +00:00
|
|
|
|
2022-01-29 00:04:42 +00:00
|
|
|
test_expect_success 'git branch abc should fail when abc exists' '
|
|
|
|
test_must_fail git branch abc
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --force abc should fail when abc is checked out' '
|
|
|
|
test_when_finished git switch main &&
|
|
|
|
git switch abc &&
|
|
|
|
test_must_fail git branch --force abc HEAD~1
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --force abc should succeed when abc exists' '
|
|
|
|
git rev-parse HEAD~1 >expect &&
|
|
|
|
git branch --force abc HEAD~1 &&
|
|
|
|
git rev-parse abc >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'git branch a/b/c should create a branch' '
|
2023-10-31 08:16:59 +00:00
|
|
|
git branch a/b/c &&
|
|
|
|
test_ref_exists refs/heads/a/b/c
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2005-11-14 22:10:59 +00:00
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch mb main... should create a branch' '
|
2023-10-31 08:16:59 +00:00
|
|
|
git branch mb main... &&
|
|
|
|
test_ref_exists refs/heads/mb
|
2019-04-27 12:02:22 +00:00
|
|
|
'
|
|
|
|
|
2013-04-01 15:59:14 +00:00
|
|
|
test_expect_success 'git branch HEAD should fail' '
|
|
|
|
test_must_fail git branch HEAD
|
|
|
|
'
|
2013-02-23 12:22:27 +00:00
|
|
|
|
2018-06-22 09:23:59 +00:00
|
|
|
test_expect_success 'git branch --create-reflog d/e/f should create a branch and a log' '
|
2013-03-20 12:30:12 +00:00
|
|
|
GIT_COMMITTER_DATE="2005-05-26 23:30" \
|
2018-06-22 09:23:59 +00:00
|
|
|
git -c core.logallrefupdates=false branch --create-reflog d/e/f &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_exists refs/heads/d/e/f &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
$HEAD refs/heads/d/e/f@{0}: branch: Created from main
|
|
|
|
EOF
|
2023-11-02 08:46:53 +00:00
|
|
|
git reflog show --no-abbrev-commit refs/heads/d/e/f >actual &&
|
|
|
|
test_cmp expect actual
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -d d/e/f should delete a branch and a log' '
|
|
|
|
git branch -d d/e/f &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_missing refs/heads/d/e/f &&
|
2015-07-27 22:57:08 +00:00
|
|
|
test_must_fail git reflog exists refs/heads/d/e/f
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch j/k should work after branch j has been deleted' '
|
|
|
|
git branch j &&
|
|
|
|
git branch -d j &&
|
|
|
|
git branch j/k
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch l should work after branch l/m has been deleted' '
|
|
|
|
git branch l/m &&
|
|
|
|
git branch -d l/m &&
|
|
|
|
git branch l
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -m dumps usage' '
|
|
|
|
test_expect_code 128 git branch -m 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "branch name required" err
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
2016-02-24 22:58:51 +00:00
|
|
|
test_expect_success 'git branch -m m broken_symref should work' '
|
|
|
|
test_when_finished "git branch -D broken_symref" &&
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog m &&
|
2016-02-24 22:58:51 +00:00
|
|
|
git symbolic-ref refs/heads/broken_symref refs/heads/i_am_broken &&
|
|
|
|
git branch -m m broken_symref &&
|
|
|
|
git reflog exists refs/heads/broken_symref &&
|
|
|
|
test_must_fail git reflog exists refs/heads/i_am_broken
|
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'git branch -m m m/m should work' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog m &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch -m m m/m &&
|
2015-07-27 22:57:08 +00:00
|
|
|
git reflog exists refs/heads/m/m
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -m n/n n should work' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog n/n &&
|
2011-12-08 13:10:15 +00:00
|
|
|
git branch -m n/n n &&
|
2015-07-27 22:57:08 +00:00
|
|
|
git reflog exists refs/heads/n
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2006-11-28 14:47:40 +00:00
|
|
|
|
2017-06-13 10:47:22 +00:00
|
|
|
# The topmost entry in reflog for branch bbb is about branch creation.
|
|
|
|
# Hence, we compare bbb@{1} (instead of bbb@{0}) with aaa@{0}.
|
|
|
|
|
|
|
|
test_expect_success 'git branch -m bbb should rename checked out branch' '
|
|
|
|
test_when_finished git branch -D bbb &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished git checkout main &&
|
2017-06-13 10:47:22 +00:00
|
|
|
git checkout -b aaa &&
|
|
|
|
git commit --allow-empty -m "a new commit" &&
|
|
|
|
git rev-parse aaa@{0} >expect &&
|
|
|
|
git branch -m bbb &&
|
|
|
|
git rev-parse bbb@{1} >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git symbolic-ref HEAD >actual &&
|
|
|
|
echo refs/heads/bbb >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
refs_resolve_ref_unsafe: handle d/f conflicts for writes
If our call to refs_read_raw_ref() fails, we check errno to
see if the ref is simply missing, or if we encountered a
more serious error. If it's just missing, then in "write"
mode (i.e., when RESOLVE_REFS_READING is not set), this is
perfectly fine.
However, checking for ENOENT isn't sufficient to catch all
missing-ref cases. In the filesystem backend, we may also
see EISDIR when we try to resolve "a" and "a/b" exists.
Likewise, we may see ENOTDIR if we try to resolve "a/b" and
"a" exists. In both of those cases, we know that our
resolved ref doesn't exist, but we return an error (rather
than reporting the refname and returning a null sha1).
This has been broken for a long time, but nobody really
noticed because the next step after resolving without the
READING flag is usually to lock the ref and write it. But in
both of those cases, the write will fail with the same
errno due to the directory/file conflict.
There are two cases where we can notice this, though:
1. If we try to write "a" and there's a leftover directory
already at "a", even though there is no ref "a/b". The
actual write is smart enough to move the empty "a" out
of the way.
This is reasonably rare, if only because the writing
code has to do an independent resolution before trying
its write (because the actual update_ref() code handles
this case fine). The notes-merge code does this, and
before the fix in the prior commit t3308 erroneously
expected this case to fail.
2. When resolving symbolic refs, we typically do not use
the READING flag because we want to resolve even
symrefs that point to unborn refs. Even if those unborn
refs could not actually be written because of d/f
conflicts with existing refs.
You can see this by asking "git symbolic-ref" to report
the target of a symref pointing past a d/f conflict.
We can fix the problem by recognizing the other "missing"
errnos and treating them like ENOENT. This should be safe to
do even for callers who are then going to actually write the
ref, because the actual writing process will fail if the d/f
conflict is a real one (and t1404 checks these cases).
Arguably this should be the responsibility of the
files-backend to normalize all "missing ref" errors into
ENOENT (since something like EISDIR may not be meaningful at
all to a database backend). However other callers of
refs_read_raw_ref() may actually care about the distinction;
putting this into resolve_ref() is the minimal fix for now.
The new tests in t1401 use git-symbolic-ref, which is the
most direct way to check the resolution by itself.
Interestingly we actually had a test that setup this case
already, but we only used it to verify that the funny state
could be overwritten, not that it could be resolved.
We also add a new test in t3200, as "branch -m" was the
original motivation for looking into this. What happens is
this:
0. HEAD is pointing to branch "a"
1. The user asks to rename "a" to "a/b".
2. We create "a/b" and delete "a".
3. We then try to update any worktree HEADs that point to
the renamed ref (including the main repo HEAD). To do
that, we have to resolve each HEAD. But now our HEAD is
pointing at "a", and we get EISDIR due to the loose
"a/b". As a result, we think there is no HEAD, and we
do not update it. It now points to the bogus "a".
Interestingly this case used to work, but only accidentally.
Before 31824d180d (branch: fix branch renaming not updating
HEADs correctly, 2017-08-24), we'd update any HEAD which we
couldn't resolve. That was wrong, but it papered over the
fact that we were incorrectly failing to resolve HEAD.
So while the bug demonstrated by the git-symbolic-ref is
quite old, the regression to "branch -m" is recent.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 14:42:17 +00:00
|
|
|
test_expect_success 'renaming checked out branch works with d/f conflict' '
|
|
|
|
test_when_finished "git branch -D foo/bar || git branch -D foo" &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished git checkout main &&
|
refs_resolve_ref_unsafe: handle d/f conflicts for writes
If our call to refs_read_raw_ref() fails, we check errno to
see if the ref is simply missing, or if we encountered a
more serious error. If it's just missing, then in "write"
mode (i.e., when RESOLVE_REFS_READING is not set), this is
perfectly fine.
However, checking for ENOENT isn't sufficient to catch all
missing-ref cases. In the filesystem backend, we may also
see EISDIR when we try to resolve "a" and "a/b" exists.
Likewise, we may see ENOTDIR if we try to resolve "a/b" and
"a" exists. In both of those cases, we know that our
resolved ref doesn't exist, but we return an error (rather
than reporting the refname and returning a null sha1).
This has been broken for a long time, but nobody really
noticed because the next step after resolving without the
READING flag is usually to lock the ref and write it. But in
both of those cases, the write will fail with the same
errno due to the directory/file conflict.
There are two cases where we can notice this, though:
1. If we try to write "a" and there's a leftover directory
already at "a", even though there is no ref "a/b". The
actual write is smart enough to move the empty "a" out
of the way.
This is reasonably rare, if only because the writing
code has to do an independent resolution before trying
its write (because the actual update_ref() code handles
this case fine). The notes-merge code does this, and
before the fix in the prior commit t3308 erroneously
expected this case to fail.
2. When resolving symbolic refs, we typically do not use
the READING flag because we want to resolve even
symrefs that point to unborn refs. Even if those unborn
refs could not actually be written because of d/f
conflicts with existing refs.
You can see this by asking "git symbolic-ref" to report
the target of a symref pointing past a d/f conflict.
We can fix the problem by recognizing the other "missing"
errnos and treating them like ENOENT. This should be safe to
do even for callers who are then going to actually write the
ref, because the actual writing process will fail if the d/f
conflict is a real one (and t1404 checks these cases).
Arguably this should be the responsibility of the
files-backend to normalize all "missing ref" errors into
ENOENT (since something like EISDIR may not be meaningful at
all to a database backend). However other callers of
refs_read_raw_ref() may actually care about the distinction;
putting this into resolve_ref() is the minimal fix for now.
The new tests in t1401 use git-symbolic-ref, which is the
most direct way to check the resolution by itself.
Interestingly we actually had a test that setup this case
already, but we only used it to verify that the funny state
could be overwritten, not that it could be resolved.
We also add a new test in t3200, as "branch -m" was the
original motivation for looking into this. What happens is
this:
0. HEAD is pointing to branch "a"
1. The user asks to rename "a" to "a/b".
2. We create "a/b" and delete "a".
3. We then try to update any worktree HEADs that point to
the renamed ref (including the main repo HEAD). To do
that, we have to resolve each HEAD. But now our HEAD is
pointing at "a", and we get EISDIR due to the loose
"a/b". As a result, we think there is no HEAD, and we
do not update it. It now points to the bogus "a".
Interestingly this case used to work, but only accidentally.
Before 31824d180d (branch: fix branch renaming not updating
HEADs correctly, 2017-08-24), we'd update any HEAD which we
couldn't resolve. That was wrong, but it papered over the
fact that we were incorrectly failing to resolve HEAD.
So while the bug demonstrated by the git-symbolic-ref is
quite old, the regression to "branch -m" is recent.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06 14:42:17 +00:00
|
|
|
git checkout -b foo &&
|
|
|
|
git branch -m foo/bar &&
|
|
|
|
git symbolic-ref HEAD >actual &&
|
|
|
|
echo refs/heads/foo/bar >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'git branch -m o/o o should fail when o/p exists' '
|
|
|
|
git branch o/o &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch o/p &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git branch -m o/o o
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2006-11-28 14:47:40 +00:00
|
|
|
|
2014-12-04 13:26:44 +00:00
|
|
|
test_expect_success 'git branch -m o/q o/p should fail when o/p exists' '
|
|
|
|
git branch o/q &&
|
|
|
|
test_must_fail git branch -m o/q o/p
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -M o/q o/p should work when o/p exists' '
|
|
|
|
git branch -M o/q o/p
|
|
|
|
'
|
|
|
|
|
2014-12-08 16:28:45 +00:00
|
|
|
test_expect_success 'git branch -m -f o/q o/p should work when o/p exists' '
|
|
|
|
git branch o/q &&
|
|
|
|
git branch -m -f o/q o/p
|
|
|
|
'
|
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'git branch -m q r/q should fail when r exists' '
|
|
|
|
git branch q &&
|
|
|
|
git branch r &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git branch -m q r/q
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2006-11-28 14:47:40 +00:00
|
|
|
|
2011-08-20 21:49:48 +00:00
|
|
|
test_expect_success 'git branch -M foo bar should fail when bar is checked out' '
|
|
|
|
git branch bar &&
|
|
|
|
git checkout -b foo &&
|
|
|
|
test_must_fail git branch -M bar foo
|
|
|
|
'
|
|
|
|
|
2021-12-01 22:15:47 +00:00
|
|
|
test_expect_success 'git branch -M foo bar should fail when bar is checked out in worktree' '
|
|
|
|
git branch -f bar &&
|
|
|
|
test_when_finished "git worktree remove wt && git branch -D wt" &&
|
|
|
|
git worktree add wt &&
|
|
|
|
test_must_fail git branch -M bar wt
|
|
|
|
'
|
|
|
|
|
2011-08-20 21:49:48 +00:00
|
|
|
test_expect_success 'git branch -M baz bam should succeed when baz is checked out' '
|
|
|
|
git checkout -b baz &&
|
|
|
|
git branch bam &&
|
2016-03-27 14:37:14 +00:00
|
|
|
git branch -M baz bam &&
|
|
|
|
test $(git rev-parse --abbrev-ref HEAD) = bam
|
|
|
|
'
|
|
|
|
|
2023-11-02 08:46:53 +00:00
|
|
|
test_expect_success 'git branch -M baz bam should add entries to HEAD reflog' '
|
|
|
|
git reflog show HEAD >actual &&
|
|
|
|
grep "HEAD@{0}: Branch: renamed refs/heads/baz to refs/heads/bam" actual
|
2017-02-21 01:10:34 +00:00
|
|
|
'
|
|
|
|
|
branch: fix branch renaming not updating HEADs correctly
There are two bugs that sort of work together and cause
problems. Let's start with one in replace_each_worktree_head_symref.
Before fa099d2322 (worktree.c: kill parse_ref() in favor of
refs_resolve_ref_unsafe() - 2017-04-24), this code looks like this:
if (strcmp(oldref, worktrees[i]->head_ref))
continue;
set_worktree_head_symref(...);
After fa099d2322, it is possible that head_ref can be NULL. However,
the updated code takes the wrong exit. In the error case (NULL
head_ref), we should "continue;" to the next worktree. The updated
code makes us _skip_ "continue;" and update HEAD anyway.
The NULL head_ref is triggered by the second bug in add_head_info (in
the same commit). With the flag RESOLVE_REF_READING, resolve_ref_unsafe()
will abort if it cannot resolve the target ref. For orphan checkouts,
HEAD always points to an unborned branch, resolving target ref will
always fail. Now we have NULL head_ref. Now we always update HEAD.
Correct the logic in replace_ function so that we don't accidentally
update HEAD on error. As it turns out, correcting the logic bug above
breaks branch renaming completely, thanks to the second bug.
"git branch -[Mm]" does two steps (on a normal checkout, no orphan!):
- rename the branch on disk (e.g. refs/heads/abc to refs/heads/def)
- update HEAD if it points to the branch being renamed.
At the second step, since the branch pointed to by HEAD (e.g. "abc") no
longer exists on disk, we run into a temporary orphan checkout situation
that has been just corrected to _not_ update HEAD. But we need to update
HEAD since it's not actually an orphan checkout. We need to update HEAD
to move out of that orphan state.
Correct add_head_info(), remove RESOLVE_REF_READING flag. With the flag
gone, we should always return good "head_ref" in orphan checkouts (either
temporary or permanent). With good head_ref, things start to work again.
Noticed-by: Nish Aravamudan <nish.aravamudan@canonical.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24 10:41:24 +00:00
|
|
|
test_expect_success 'git branch -M should leave orphaned HEAD alone' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main orphan &&
|
branch: fix branch renaming not updating HEADs correctly
There are two bugs that sort of work together and cause
problems. Let's start with one in replace_each_worktree_head_symref.
Before fa099d2322 (worktree.c: kill parse_ref() in favor of
refs_resolve_ref_unsafe() - 2017-04-24), this code looks like this:
if (strcmp(oldref, worktrees[i]->head_ref))
continue;
set_worktree_head_symref(...);
After fa099d2322, it is possible that head_ref can be NULL. However,
the updated code takes the wrong exit. In the error case (NULL
head_ref), we should "continue;" to the next worktree. The updated
code makes us _skip_ "continue;" and update HEAD anyway.
The NULL head_ref is triggered by the second bug in add_head_info (in
the same commit). With the flag RESOLVE_REF_READING, resolve_ref_unsafe()
will abort if it cannot resolve the target ref. For orphan checkouts,
HEAD always points to an unborned branch, resolving target ref will
always fail. Now we have NULL head_ref. Now we always update HEAD.
Correct the logic in replace_ function so that we don't accidentally
update HEAD on error. As it turns out, correcting the logic bug above
breaks branch renaming completely, thanks to the second bug.
"git branch -[Mm]" does two steps (on a normal checkout, no orphan!):
- rename the branch on disk (e.g. refs/heads/abc to refs/heads/def)
- update HEAD if it points to the branch being renamed.
At the second step, since the branch pointed to by HEAD (e.g. "abc") no
longer exists on disk, we run into a temporary orphan checkout situation
that has been just corrected to _not_ update HEAD. But we need to update
HEAD since it's not actually an orphan checkout. We need to update HEAD
to move out of that orphan state.
Correct add_head_info(), remove RESOLVE_REF_READING flag. With the flag
gone, we should always return good "head_ref" in orphan checkouts (either
temporary or permanent). With good head_ref, things start to work again.
Noticed-by: Nish Aravamudan <nish.aravamudan@canonical.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24 10:41:24 +00:00
|
|
|
(
|
|
|
|
cd orphan &&
|
|
|
|
test_commit initial &&
|
|
|
|
git checkout --orphan lonely &&
|
2023-11-02 08:46:49 +00:00
|
|
|
git symbolic-ref HEAD >expect &&
|
|
|
|
echo refs/heads/lonely >actual &&
|
|
|
|
test_cmp expect actual &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_missing refs/head/lonely &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git branch -M main mistress &&
|
2023-11-02 08:46:49 +00:00
|
|
|
git symbolic-ref HEAD >expect &&
|
|
|
|
test_cmp expect actual
|
branch: fix branch renaming not updating HEADs correctly
There are two bugs that sort of work together and cause
problems. Let's start with one in replace_each_worktree_head_symref.
Before fa099d2322 (worktree.c: kill parse_ref() in favor of
refs_resolve_ref_unsafe() - 2017-04-24), this code looks like this:
if (strcmp(oldref, worktrees[i]->head_ref))
continue;
set_worktree_head_symref(...);
After fa099d2322, it is possible that head_ref can be NULL. However,
the updated code takes the wrong exit. In the error case (NULL
head_ref), we should "continue;" to the next worktree. The updated
code makes us _skip_ "continue;" and update HEAD anyway.
The NULL head_ref is triggered by the second bug in add_head_info (in
the same commit). With the flag RESOLVE_REF_READING, resolve_ref_unsafe()
will abort if it cannot resolve the target ref. For orphan checkouts,
HEAD always points to an unborned branch, resolving target ref will
always fail. Now we have NULL head_ref. Now we always update HEAD.
Correct the logic in replace_ function so that we don't accidentally
update HEAD on error. As it turns out, correcting the logic bug above
breaks branch renaming completely, thanks to the second bug.
"git branch -[Mm]" does two steps (on a normal checkout, no orphan!):
- rename the branch on disk (e.g. refs/heads/abc to refs/heads/def)
- update HEAD if it points to the branch being renamed.
At the second step, since the branch pointed to by HEAD (e.g. "abc") no
longer exists on disk, we run into a temporary orphan checkout situation
that has been just corrected to _not_ update HEAD. But we need to update
HEAD since it's not actually an orphan checkout. We need to update HEAD
to move out of that orphan state.
Correct add_head_info(), remove RESOLVE_REF_READING flag. With the flag
gone, we should always return good "head_ref" in orphan checkouts (either
temporary or permanent). With good head_ref, things start to work again.
Noticed-by: Nish Aravamudan <nish.aravamudan@canonical.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24 10:41:24 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
reflog-walk: skip over double-null oid due to HEAD rename
Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid).
This confuses the reflog-walk code. When walking backwards,
it first sees the null oid in the "old" field of the second
entry. Thanks to the "root commit" logic added by 71abeb753f
(reflog: continue walking the reflog past root commits,
2016-06-03), we keep looking for the next entry by scanning
the "new" field from the previous entry. But that field is
also null! We need to go just a tiny bit further, and look
at its "old" field. But with the current code, we decide the
reflog has nothing else to show and just give up. To the
user this looks like the reflog was truncated by the rename
operation, when in fact those entries are still there.
This patch does the absolute minimal fix, which is to look
back that one extra level and keep traversing.
The resulting behavior may not be the _best_ thing to do in
the long run (for example, we show both reflog entries each
with the same commit id), but it's a simple way to fix the
problem without risking further regressions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-05 07:57:37 +00:00
|
|
|
test_expect_success 'resulting reflog can be shown by log -g' '
|
|
|
|
oid=$(git rev-parse HEAD) &&
|
|
|
|
cat >expect <<-EOF &&
|
2023-11-02 08:46:53 +00:00
|
|
|
HEAD@{0} $oid Branch: renamed refs/heads/baz to refs/heads/bam
|
reflog-walk: skip over double-null oid due to HEAD rename
Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid).
This confuses the reflog-walk code. When walking backwards,
it first sees the null oid in the "old" field of the second
entry. Thanks to the "root commit" logic added by 71abeb753f
(reflog: continue walking the reflog past root commits,
2016-06-03), we keep looking for the next entry by scanning
the "new" field from the previous entry. But that field is
also null! We need to go just a tiny bit further, and look
at its "old" field. But with the current code, we decide the
reflog has nothing else to show and just give up. To the
user this looks like the reflog was truncated by the rename
operation, when in fact those entries are still there.
This patch does the absolute minimal fix, which is to look
back that one extra level and keep traversing.
The resulting behavior may not be the _best_ thing to do in
the long run (for example, we show both reflog entries each
with the same commit id), but it's a simple way to fix the
problem without risking further regressions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-05 07:57:37 +00:00
|
|
|
HEAD@{2} $oid checkout: moving from foo to baz
|
|
|
|
EOF
|
reflog-walk: stop using fake parents
The reflog-walk system works by putting a ref's tip into the
pending queue, and then "traversing" the reflog by
pretending that the parent of each commit is the previous
reflog entry.
This causes a number of user-visible oddities, as documented
in t1414 (and the commit message which introduced it). We
can fix all of them in one go by replacing the fake-reflog
system with a much simpler one: just keeping a list of
reflogs to show, and walking through them entry by entry.
The implementation is fairly straight-forward, but there are
a few items to note:
1. We obviously must skip calling add_parents_to_list()
when we are traversing reflogs, since we do not want to
walk the original parents at all. As a result, we must call
try_to_simplify_commit() ourselves.
There are other parts of add_parents_to_list() we skip,
as well, but none of them should matter for a reflog
traversal:
- We do not allow UNINTERESTING commits, nor
symmetric ranges (and we bail when these are used
with "-g").
- Using --source makes no sense, since we aren't
traversing. The reflog selector shows the same
information with more detail.
- Using --first-parent is still sensible, since you
may want to see the first-parent diff for each
entry. But since we're not traversing, we don't
need to cull the parent list here.
2. Since we now just walk the reflog entries themselves,
rather than starting with the ref tip, we now look at
the "new" field of each entry rather than the "old"
(i.e., we are showing entries, not faking parents).
This removes all of the tricky logic around skipping
past root commits.
But note that we have no way to show an entry with the
null sha1 in its "new" field (because such a commit
obviously does not exist). Normally this would not
happen, since we delete reflogs along with refs, but
there is one special case. When we rename the currently
checked out branch, we write two reflog entries into
the HEAD log: one where the commit goes away, and
another where it comes back.
Prior to this commit, we show both entries with
identical reflog messages. After this commit, we show
only the "comes back" entry. See the update in t3200
which demonstrates this.
Arguably either is fine, as the whole double-entry
thing is a bit hacky in the first place. And until a
recent fix, we truncated the traversal in such a case
anyway, which was _definitely_ wrong.
3. We show individual reflogs in order, but choose which
reflog to show at each stage based on which has the
most recent timestamp. This interleaves the output
from multiple reflogs based on date order, which is
probably what you'd want with limiting like "-n 30".
Note that the implementation aims for simplicity. It
does a linear walk over the reflog queue for each
commit it pulls, which may perform badly if you
interleave an enormous number of reflogs. That seems
like an unlikely use case; if we did want to handle it,
we could probably keep a priority queue of reflogs,
ordered by the timestamp of their current tip entry.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-07 09:14:07 +00:00
|
|
|
git log -g --format="%gd %H %gs" -2 HEAD >actual &&
|
reflog-walk: skip over double-null oid due to HEAD rename
Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid).
This confuses the reflog-walk code. When walking backwards,
it first sees the null oid in the "old" field of the second
entry. Thanks to the "root commit" logic added by 71abeb753f
(reflog: continue walking the reflog past root commits,
2016-06-03), we keep looking for the next entry by scanning
the "new" field from the previous entry. But that field is
also null! We need to go just a tiny bit further, and look
at its "old" field. But with the current code, we decide the
reflog has nothing else to show and just give up. To the
user this looks like the reflog was truncated by the rename
operation, when in fact those entries are still there.
This patch does the absolute minimal fix, which is to look
back that one extra level and keep traversing.
The resulting behavior may not be the _best_ thing to do in
the long run (for example, we show both reflog entries each
with the same commit id), but it's a simple way to fix the
problem without risking further regressions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-05 07:57:37 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2016-03-27 14:37:14 +00:00
|
|
|
test_expect_success 'git branch -M baz bam should succeed when baz is checked out as linked working tree' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2016-03-27 14:37:14 +00:00
|
|
|
git worktree add -b baz bazdir &&
|
|
|
|
git worktree add -f bazdir2 baz &&
|
|
|
|
git branch -M baz bam &&
|
|
|
|
test $(git -C bazdir rev-parse --abbrev-ref HEAD) = bam &&
|
2019-04-29 05:19:43 +00:00
|
|
|
test $(git -C bazdir2 rev-parse --abbrev-ref HEAD) = bam &&
|
|
|
|
rm -r bazdir bazdir2 &&
|
|
|
|
git worktree prune
|
2016-03-27 14:37:14 +00:00
|
|
|
'
|
|
|
|
|
2023-11-02 08:47:14 +00:00
|
|
|
test_expect_success REFFILES 'git branch -M fails if updating any linked working tree fails' '
|
2023-03-26 22:33:02 +00:00
|
|
|
git worktree add -b baz bazdir1 &&
|
|
|
|
git worktree add -f bazdir2 baz &&
|
|
|
|
touch .git/worktrees/bazdir1/HEAD.lock &&
|
|
|
|
test_must_fail git branch -M baz bam &&
|
|
|
|
test $(git -C bazdir2 rev-parse --abbrev-ref HEAD) = bam &&
|
|
|
|
git branch -M bam baz &&
|
|
|
|
rm .git/worktrees/bazdir1/HEAD.lock &&
|
|
|
|
touch .git/worktrees/bazdir2/HEAD.lock &&
|
|
|
|
test_must_fail git branch -M baz bam &&
|
|
|
|
test $(git -C bazdir1 rev-parse --abbrev-ref HEAD) = bam &&
|
|
|
|
rm -rf bazdir1 bazdir2 &&
|
|
|
|
git worktree prune
|
|
|
|
'
|
|
|
|
|
2016-03-27 14:37:14 +00:00
|
|
|
test_expect_success 'git branch -M baz bam should succeed within a worktree in which baz is checked out' '
|
|
|
|
git checkout -b baz &&
|
2019-04-29 05:19:43 +00:00
|
|
|
git worktree add -f bazdir baz &&
|
2016-03-27 14:37:14 +00:00
|
|
|
(
|
2019-04-29 05:19:43 +00:00
|
|
|
cd bazdir &&
|
2016-03-27 14:37:14 +00:00
|
|
|
git branch -M baz bam &&
|
2023-02-06 22:44:30 +00:00
|
|
|
echo bam >expect &&
|
|
|
|
git rev-parse --abbrev-ref HEAD >actual &&
|
|
|
|
test_cmp expect actual
|
2016-03-27 14:37:14 +00:00
|
|
|
) &&
|
2023-02-06 22:44:30 +00:00
|
|
|
echo bam >expect &&
|
|
|
|
git rev-parse --abbrev-ref HEAD >actual &&
|
|
|
|
test_cmp expect actual &&
|
2019-04-29 05:19:43 +00:00
|
|
|
rm -r bazdir &&
|
|
|
|
git worktree prune
|
2011-08-20 21:49:48 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -M main should work when main is checked out' '
|
|
|
|
git checkout main &&
|
|
|
|
git branch -M main
|
2011-11-26 02:30:02 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -M main main should work when main is checked out' '
|
|
|
|
git checkout main &&
|
|
|
|
git branch -M main main
|
2011-11-26 02:30:02 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -M topic topic should work when main is checked out' '
|
|
|
|
git checkout main &&
|
2020-09-21 22:01:24 +00:00
|
|
|
git branch topic &&
|
|
|
|
git branch -M topic topic
|
2011-11-26 02:30:02 +00:00
|
|
|
'
|
|
|
|
|
2022-10-25 23:01:29 +00:00
|
|
|
test_expect_success 'git branch -M and -C fail on detached HEAD' '
|
|
|
|
git checkout HEAD^{} &&
|
|
|
|
test_when_finished git checkout - &&
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: cannot rename the current branch while not on any" >expect &&
|
2022-10-25 23:01:29 +00:00
|
|
|
test_must_fail git branch -M must-fail 2>err &&
|
|
|
|
test_cmp expect err &&
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: cannot copy the current branch while not on any" >expect &&
|
2022-10-25 23:01:29 +00:00
|
|
|
test_must_fail git branch -C must-fail 2>err &&
|
|
|
|
test_cmp expect err
|
|
|
|
'
|
|
|
|
|
2023-03-26 22:33:27 +00:00
|
|
|
test_expect_success 'git branch -m should work with orphan branches' '
|
|
|
|
test_when_finished git checkout - &&
|
|
|
|
test_when_finished git worktree remove -f wt &&
|
|
|
|
git worktree add wt --detach &&
|
|
|
|
# rename orphan in another worktreee
|
|
|
|
git -C wt checkout --orphan orphan-foo-wt &&
|
|
|
|
git branch -m orphan-foo-wt orphan-bar-wt &&
|
|
|
|
test orphan-bar-wt=$(git -C orphan-worktree branch --show-current) &&
|
|
|
|
# rename orphan in the current worktree
|
|
|
|
git checkout --orphan orphan-foo &&
|
|
|
|
git branch -m orphan-foo orphan-bar &&
|
|
|
|
test orphan-bar=$(git branch --show-current)
|
|
|
|
'
|
|
|
|
|
branch: gracefully handle '-d' on orphan HEAD
When deleting a branch, "git branch -d" has a safety check that ensures
the branch is merged to its upstream (if any), or to HEAD. To do that,
naturally we try to resolve HEAD to a commit object. If we're on an
orphan branch (i.e., HEAD points to a branch that does not yet exist),
that will fail, and we'll bail with an error:
$ git branch -d to-delete
fatal: Couldn't look up commit object for HEAD
This usually isn't that big of a deal. The deletion would fail anyway,
since the branch isn't merged to HEAD, and you'd need to use "-D" (or
"-f"). And doing so skips the HEAD resolution, courtesy of 67affd5173
(git-branch -D: make it work even when on a yet-to-be-born branch,
2006-11-24).
But there are still two problems:
1. The error message isn't very helpful. We should give the usual "not
fully merged" message, which points the user at "branch -D". That
was a problem even back in 67affd5173.
2. Even without a HEAD, these days it's still possible for the
deletion to succeed. After 67affd5173, commit 99c419c915 (branch
-d: base the "already-merged" safety on the branch it merges with,
2009-12-29) made it OK to delete a branch if it is merged to its
upstream.
We can fix both by removing the die() in delete_branches() completely,
leaving head_rev NULL in this case. It's tempting to stop there, as it
appears at first glance that the rest of the code does the right thing
with a NULL. But sadly, it's not quite true.
We end up feeding the NULL to repo_is_descendant_of(). In the
traditional code path there, we call repo_in_merge_bases_many(). It
feeds the NULL to repo_parse_commit(), which is smart enough to return
an error, and we immediately return "no, it's not a descendant".
But there's an alternate code path: if we have a commit graph with
generation numbers, we end up in can_all_from_reach(), which does
eventually try to set a flag on the NULL commit and segfaults.
So instead, we'll teach the local branch_merged() helper to treat a NULL
as "not merged". This would be a little more elegant in in_merge_bases()
itself, but that function is called in a lot of places, and it's not
clear that quietly returning "not merged" is the right thing everywhere
(I'd expect in many cases, feeding a NULL is a sign of a bug).
There are four tests here:
a. The first one confirms that deletion succeeds with an orphaned HEAD
when the branch is merged to its upstream. This is case (2) above.
b. Same, but with commit graphs enabled. Even if it is merged to
upstream, we still check head_rev so that we can say "deleting
because it's merged to upstream, even though it's not merged to
HEAD". Without the second hunk in branch_merged(), this test would
segfault in can_all_from_reach().
c. The third one confirms that we correctly say "not merged to HEAD"
when we can't resolve HEAD, and reject the deletion.
d. Same, but with commit graphs enabled. Without the first hunk in
branch_merged(), this one would segfault.
Reported-by: Martin von Zweigbergk <martinvonz@google.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-02 05:27:49 +00:00
|
|
|
test_expect_success 'git branch -d on orphan HEAD (merged)' '
|
|
|
|
test_when_finished git checkout main &&
|
|
|
|
git checkout --orphan orphan &&
|
|
|
|
test_when_finished "rm -rf .git/objects/commit-graph*" &&
|
|
|
|
git commit-graph write --reachable &&
|
|
|
|
git branch --track to-delete main &&
|
|
|
|
git branch -d to-delete
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -d on orphan HEAD (merged, graph)' '
|
|
|
|
test_when_finished git checkout main &&
|
|
|
|
git checkout --orphan orphan &&
|
|
|
|
git branch --track to-delete main &&
|
|
|
|
git branch -d to-delete
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -d on orphan HEAD (unmerged)' '
|
|
|
|
test_when_finished git checkout main &&
|
|
|
|
git checkout --orphan orphan &&
|
|
|
|
test_when_finished "git branch -D to-delete" &&
|
|
|
|
git branch to-delete main &&
|
|
|
|
test_must_fail git branch -d to-delete 2>err &&
|
|
|
|
grep "not fully merged" err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -d on orphan HEAD (unmerged, graph)' '
|
|
|
|
test_when_finished git checkout main &&
|
|
|
|
git checkout --orphan orphan &&
|
|
|
|
test_when_finished "git branch -D to-delete" &&
|
|
|
|
git branch to-delete main &&
|
|
|
|
test_when_finished "rm -rf .git/objects/commit-graph*" &&
|
|
|
|
git commit-graph write --reachable &&
|
|
|
|
test_must_fail git branch -d to-delete 2>err &&
|
|
|
|
grep "not fully merged" err
|
|
|
|
'
|
|
|
|
|
2011-08-28 14:54:31 +00:00
|
|
|
test_expect_success 'git branch -v -d t should work' '
|
|
|
|
git branch t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
git rev-parse --verify refs/heads/t &&
|
2011-08-28 14:54:31 +00:00
|
|
|
git branch -v -d t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
test_must_fail git rev-parse --verify refs/heads/t
|
2011-08-28 14:54:31 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -v -m t s should work' '
|
|
|
|
git branch t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
git rev-parse --verify refs/heads/t &&
|
2011-08-28 14:54:31 +00:00
|
|
|
git branch -v -m t s &&
|
2018-05-23 05:25:17 +00:00
|
|
|
test_must_fail git rev-parse --verify refs/heads/t &&
|
|
|
|
git rev-parse --verify refs/heads/s &&
|
2011-08-28 14:54:31 +00:00
|
|
|
git branch -d s
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -m -d t s should fail' '
|
|
|
|
git branch t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
git rev-parse refs/heads/t &&
|
2011-08-28 14:54:31 +00:00
|
|
|
test_must_fail git branch -m -d t s &&
|
|
|
|
git branch -d t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
test_must_fail git rev-parse refs/heads/t
|
2011-08-28 14:54:31 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --list -d t should fail' '
|
|
|
|
git branch t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
git rev-parse refs/heads/t &&
|
2011-08-28 14:54:31 +00:00
|
|
|
test_must_fail git branch --list -d t &&
|
|
|
|
git branch -d t &&
|
2018-05-23 05:25:17 +00:00
|
|
|
test_must_fail git rev-parse refs/heads/t
|
2011-08-28 14:54:31 +00:00
|
|
|
'
|
|
|
|
|
worktree: update is_bare heuristics
When "git branch -D <name>" is run, Git usually first checks if that
branch is currently checked out. But this check is not performed if the
Git directory of that repository is not at "<repo>/.git", which is the
case if that repository is a submodule that has its Git directory stored
as "super/.git/modules/<repo>", for example. This results in the branch
being deleted even though it is checked out.
This is because get_main_worktree() in worktree.c sets is_bare on a
worktree only using the heuristic that a repo is bare if the worktree's
path does not end in "/.git", and not bare otherwise. This is_bare code
was introduced in 92718b7438 ("worktree: add details to the worktree
struct", 2015-10-08), following a pre-core.bare heuristic. This patch
does 2 things:
- Teach get_main_worktree() to use is_bare_repository() instead,
introduced in 7d1864ce67 ("Introduce is_bare_repository() and
core.bare configuration variable", 2007-01-07) and updated in
e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
the "git branch -D <name>" problem described above. However...
- If a repository has core.bare=1 but the "git" command is being run
from one of its secondary worktrees, is_bare_repository() returns
false (which is fine, since there is a worktree available). However,
treating the main worktree as non-bare when it is bare causes issues:
for example, failure to delete a branch from a secondary worktree
that is referred to by a main worktree's HEAD, even if that main
worktree is bare.
In order to avoid that, also check core.bare when setting is_bare. If
core.bare=1, trust it, and otherwise, use is_bare_repository().
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19 17:21:28 +00:00
|
|
|
test_expect_success 'deleting checked-out branch from repo that is a submodule' '
|
|
|
|
test_when_finished "rm -rf repo1 repo2" &&
|
|
|
|
|
|
|
|
git init repo1 &&
|
|
|
|
git init repo1/sub &&
|
|
|
|
test_commit -C repo1/sub x &&
|
2022-07-29 19:20:28 +00:00
|
|
|
test_config_global protocol.file.allow always &&
|
worktree: update is_bare heuristics
When "git branch -D <name>" is run, Git usually first checks if that
branch is currently checked out. But this check is not performed if the
Git directory of that repository is not at "<repo>/.git", which is the
case if that repository is a submodule that has its Git directory stored
as "super/.git/modules/<repo>", for example. This results in the branch
being deleted even though it is checked out.
This is because get_main_worktree() in worktree.c sets is_bare on a
worktree only using the heuristic that a repo is bare if the worktree's
path does not end in "/.git", and not bare otherwise. This is_bare code
was introduced in 92718b7438 ("worktree: add details to the worktree
struct", 2015-10-08), following a pre-core.bare heuristic. This patch
does 2 things:
- Teach get_main_worktree() to use is_bare_repository() instead,
introduced in 7d1864ce67 ("Introduce is_bare_repository() and
core.bare configuration variable", 2007-01-07) and updated in
e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
the "git branch -D <name>" problem described above. However...
- If a repository has core.bare=1 but the "git" command is being run
from one of its secondary worktrees, is_bare_repository() returns
false (which is fine, since there is a worktree available). However,
treating the main worktree as non-bare when it is bare causes issues:
for example, failure to delete a branch from a secondary worktree
that is referred to by a main worktree's HEAD, even if that main
worktree is bare.
In order to avoid that, also check core.bare when setting is_bare. If
core.bare=1, trust it, and otherwise, use is_bare_repository().
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19 17:21:28 +00:00
|
|
|
git -C repo1 submodule add ./sub &&
|
|
|
|
git -C repo1 commit -m "adding sub" &&
|
|
|
|
|
|
|
|
git clone --recurse-submodules repo1 repo2 &&
|
|
|
|
git -C repo2/sub checkout -b work &&
|
|
|
|
test_must_fail git -C repo2/sub branch -D work
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'bare main worktree has HEAD at branch deleted by secondary worktree' '
|
|
|
|
test_when_finished "rm -rf nonbare base secondary" &&
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main nonbare &&
|
worktree: update is_bare heuristics
When "git branch -D <name>" is run, Git usually first checks if that
branch is currently checked out. But this check is not performed if the
Git directory of that repository is not at "<repo>/.git", which is the
case if that repository is a submodule that has its Git directory stored
as "super/.git/modules/<repo>", for example. This results in the branch
being deleted even though it is checked out.
This is because get_main_worktree() in worktree.c sets is_bare on a
worktree only using the heuristic that a repo is bare if the worktree's
path does not end in "/.git", and not bare otherwise. This is_bare code
was introduced in 92718b7438 ("worktree: add details to the worktree
struct", 2015-10-08), following a pre-core.bare heuristic. This patch
does 2 things:
- Teach get_main_worktree() to use is_bare_repository() instead,
introduced in 7d1864ce67 ("Introduce is_bare_repository() and
core.bare configuration variable", 2007-01-07) and updated in
e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
the "git branch -D <name>" problem described above. However...
- If a repository has core.bare=1 but the "git" command is being run
from one of its secondary worktrees, is_bare_repository() returns
false (which is fine, since there is a worktree available). However,
treating the main worktree as non-bare when it is bare causes issues:
for example, failure to delete a branch from a secondary worktree
that is referred to by a main worktree's HEAD, even if that main
worktree is bare.
In order to avoid that, also check core.bare when setting is_bare. If
core.bare=1, trust it, and otherwise, use is_bare_repository().
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19 17:21:28 +00:00
|
|
|
test_commit -C nonbare x &&
|
|
|
|
git clone --bare nonbare bare &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git -C bare worktree add --detach ../secondary main &&
|
|
|
|
git -C secondary branch -D main
|
worktree: update is_bare heuristics
When "git branch -D <name>" is run, Git usually first checks if that
branch is currently checked out. But this check is not performed if the
Git directory of that repository is not at "<repo>/.git", which is the
case if that repository is a submodule that has its Git directory stored
as "super/.git/modules/<repo>", for example. This results in the branch
being deleted even though it is checked out.
This is because get_main_worktree() in worktree.c sets is_bare on a
worktree only using the heuristic that a repo is bare if the worktree's
path does not end in "/.git", and not bare otherwise. This is_bare code
was introduced in 92718b7438 ("worktree: add details to the worktree
struct", 2015-10-08), following a pre-core.bare heuristic. This patch
does 2 things:
- Teach get_main_worktree() to use is_bare_repository() instead,
introduced in 7d1864ce67 ("Introduce is_bare_repository() and
core.bare configuration variable", 2007-01-07) and updated in
e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
the "git branch -D <name>" problem described above. However...
- If a repository has core.bare=1 but the "git" command is being run
from one of its secondary worktrees, is_bare_repository() returns
false (which is fine, since there is a worktree available). However,
treating the main worktree as non-bare when it is bare causes issues:
for example, failure to delete a branch from a secondary worktree
that is referred to by a main worktree's HEAD, even if that main
worktree is bare.
In order to avoid that, also check core.bare when setting is_bare. If
core.bare=1, trust it, and otherwise, use is_bare_repository().
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19 17:21:28 +00:00
|
|
|
'
|
|
|
|
|
2017-03-08 22:13:09 +00:00
|
|
|
test_expect_success 'git branch --list -v with --abbrev' '
|
|
|
|
test_when_finished "git branch -D t" &&
|
|
|
|
git branch t &&
|
|
|
|
git branch -v --list t >actual.default &&
|
|
|
|
git branch -v --list --abbrev t >actual.abbrev &&
|
|
|
|
test_cmp actual.default actual.abbrev &&
|
|
|
|
|
|
|
|
git branch -v --list --no-abbrev t >actual.noabbrev &&
|
|
|
|
git branch -v --list --abbrev=0 t >actual.0abbrev &&
|
2020-09-01 07:43:55 +00:00
|
|
|
git -c core.abbrev=no branch -v --list t >actual.noabbrev-conf &&
|
2017-03-08 22:13:09 +00:00
|
|
|
test_cmp actual.noabbrev actual.0abbrev &&
|
2020-09-01 07:43:55 +00:00
|
|
|
test_cmp actual.noabbrev actual.noabbrev-conf &&
|
2017-03-08 22:13:09 +00:00
|
|
|
|
|
|
|
git branch -v --list --abbrev=36 t >actual.36abbrev &&
|
|
|
|
# how many hexdigits are used?
|
|
|
|
read name objdefault rest <actual.abbrev &&
|
|
|
|
read name obj36 rest <actual.36abbrev &&
|
|
|
|
objfull=$(git rev-parse --verify t) &&
|
|
|
|
|
|
|
|
# are we really getting abbreviations?
|
|
|
|
test "$obj36" != "$objdefault" &&
|
|
|
|
expr "$obj36" : "$objdefault" >/dev/null &&
|
|
|
|
test "$objfull" != "$obj36" &&
|
|
|
|
expr "$objfull" : "$obj36" >/dev/null
|
|
|
|
|
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch --column' '
|
2012-04-13 10:54:38 +00:00
|
|
|
COLUMNS=81 git branch --column=column >actual &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a/b/c bam foo l * main n o/p r
|
|
|
|
abc bar j/k m/m mb o/o q topic
|
|
|
|
EOF
|
2020-06-15 11:53:18 +00:00
|
|
|
test_cmp expect actual
|
2012-04-13 10:54:38 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --column with an extremely long branch name' '
|
|
|
|
long=this/is/a/part/of/long/branch/name &&
|
|
|
|
long=z$long/$long/$long/$long &&
|
|
|
|
test_when_finished "git branch -d $long" &&
|
|
|
|
git branch $long &&
|
|
|
|
COLUMNS=80 git branch --column=column >actual &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
a/b/c
|
|
|
|
abc
|
|
|
|
bam
|
|
|
|
bar
|
|
|
|
foo
|
|
|
|
j/k
|
|
|
|
l
|
|
|
|
m/m
|
|
|
|
* main
|
|
|
|
mb
|
|
|
|
n
|
|
|
|
o/o
|
|
|
|
o/p
|
|
|
|
q
|
|
|
|
r
|
|
|
|
topic
|
|
|
|
$long
|
|
|
|
EOF
|
2020-06-15 11:53:18 +00:00
|
|
|
test_cmp expect actual
|
2012-04-13 10:54:38 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch with column.*' '
|
2012-04-13 10:54:38 +00:00
|
|
|
git config column.ui column &&
|
|
|
|
git config column.branch "dense" &&
|
|
|
|
COLUMNS=80 git branch >actual &&
|
|
|
|
git config --unset column.branch &&
|
|
|
|
git config --unset column.ui &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a/b/c bam foo l * main n o/p r
|
|
|
|
abc bar j/k m/m mb o/o q topic
|
|
|
|
EOF
|
2020-06-15 11:53:18 +00:00
|
|
|
test_cmp expect actual
|
2012-04-13 10:54:38 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --column -v should fail' '
|
|
|
|
test_must_fail git branch --column -v
|
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -v with column.ui ignored' '
|
2012-04-13 10:54:38 +00:00
|
|
|
git config column.ui column &&
|
2020-10-23 14:00:03 +00:00
|
|
|
COLUMNS=80 git branch -v | cut -c -8 | sed "s/ *$//" >actual &&
|
2012-04-13 10:54:38 +00:00
|
|
|
git config --unset column.ui &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a/b/c
|
|
|
|
abc
|
|
|
|
bam
|
|
|
|
bar
|
|
|
|
foo
|
|
|
|
j/k
|
|
|
|
l
|
|
|
|
m/m
|
|
|
|
* main
|
|
|
|
mb
|
|
|
|
n
|
|
|
|
o/o
|
|
|
|
o/p
|
|
|
|
q
|
|
|
|
r
|
|
|
|
topic
|
|
|
|
EOF
|
2020-06-15 11:53:18 +00:00
|
|
|
test_cmp expect actual
|
2012-04-13 10:54:38 +00:00
|
|
|
'
|
|
|
|
|
2023-12-29 07:26:26 +00:00
|
|
|
test_expect_success DEFAULT_REPO_FORMAT 'git branch -m q q2 without config should succeed' '
|
2024-03-05 20:29:39 +00:00
|
|
|
test_when_finished mv .git/config-saved .git/config &&
|
|
|
|
mv .git/config .git/config-saved &&
|
2007-07-03 05:52:14 +00:00
|
|
|
git branch -m q q2 &&
|
|
|
|
git branch -m q2 q
|
2007-04-05 14:20:55 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'git branch -m s/s s should work when s/t is deleted' '
|
2024-03-05 20:29:39 +00:00
|
|
|
git config branch.s/s.dummy Hello &&
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog s/s &&
|
2015-07-27 22:57:08 +00:00
|
|
|
git reflog exists refs/heads/s/s &&
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog s/t &&
|
2015-07-27 22:57:08 +00:00
|
|
|
git reflog exists refs/heads/s/t &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch -d s/t &&
|
|
|
|
git branch -m s/s s &&
|
2015-07-27 22:57:08 +00:00
|
|
|
git reflog exists refs/heads/s
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2006-11-28 14:47:40 +00:00
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'config information was renamed, too' '
|
|
|
|
test $(git config branch.s.dummy) = Hello &&
|
2017-05-28 17:12:16 +00:00
|
|
|
test_must_fail git config branch.s/s.dummy
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2006-12-16 14:15:02 +00:00
|
|
|
|
2017-06-18 21:17:50 +00:00
|
|
|
test_expect_success 'git branch -m correctly renames multiple config sections' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished "git checkout main" &&
|
|
|
|
git checkout -b source main &&
|
2017-06-18 21:17:50 +00:00
|
|
|
|
|
|
|
# Assert that a config file with multiple config sections has
|
|
|
|
# those sections preserved...
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
branch.dest.key1=value1
|
|
|
|
some.gar.b=age
|
|
|
|
branch.dest.key2=value2
|
|
|
|
EOF
|
|
|
|
cat >config.branch <<\EOF &&
|
|
|
|
;; Note the lack of -\EOF above & mixed indenting here. This is
|
|
|
|
;; intentional, we are also testing that the formatting of copied
|
|
|
|
;; sections is preserved.
|
|
|
|
|
|
|
|
;; Comment for source. Tabs
|
|
|
|
[branch "source"]
|
|
|
|
;; Comment for the source value
|
|
|
|
key1 = value1
|
|
|
|
;; Comment for some.gar. Spaces
|
|
|
|
[some "gar"]
|
|
|
|
;; Comment for the some.gar value
|
|
|
|
b = age
|
|
|
|
;; Comment for source, again. Mixed tabs/spaces.
|
|
|
|
[branch "source"]
|
|
|
|
;; Comment for the source value, again
|
|
|
|
key2 = value2
|
|
|
|
EOF
|
|
|
|
cat config.branch >>.git/config &&
|
|
|
|
git branch -m source dest &&
|
|
|
|
git config -f .git/config -l | grep -F -e source -e dest -e some.gar >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
# ...and that the comments for those sections are also
|
|
|
|
# preserved.
|
|
|
|
cat config.branch | sed "s/\"source\"/\"dest\"/" >expect &&
|
|
|
|
sed -n -e "/Note the lack/,\$p" .git/config >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
test_expect_success 'git branch -c dumps usage' '
|
|
|
|
test_expect_code 128 git branch -c 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "branch name required" err
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --copy dumps usage' '
|
|
|
|
test_expect_code 128 git branch --copy 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "branch name required" err
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c d e should work' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog d &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/d &&
|
|
|
|
git config branch.d.dummy Hello &&
|
|
|
|
git branch -c d e &&
|
|
|
|
git reflog exists refs/heads/d &&
|
|
|
|
git reflog exists refs/heads/e &&
|
|
|
|
echo Hello >expect &&
|
|
|
|
git config branch.e.dummy >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
echo Hello >expect &&
|
|
|
|
git config branch.d.dummy >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch --copy is a synonym for -c' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog copy &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/copy &&
|
|
|
|
git config branch.copy.dummy Hello &&
|
|
|
|
git branch --copy copy copy-to &&
|
|
|
|
git reflog exists refs/heads/copy &&
|
|
|
|
git reflog exists refs/heads/copy-to &&
|
|
|
|
echo Hello >expect &&
|
|
|
|
git config branch.copy.dummy >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
echo Hello >expect &&
|
|
|
|
git config branch.copy-to.dummy >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
branch: fix "copy" to never touch HEAD
When creating a new branch B by copying the branch A that happens to
be the current branch, it also updates HEAD to point at the new
branch. It probably was made this way because "git branch -c A B"
piggybacked its implementation on "git branch -m A B",
This does not match the usual expectation. If I were sitting on a
blue chair, and somebody comes and repaints it to red, I would
accept ending up sitting on a chair that is now red (I am also OK to
stand, instead, as there no longer is my favourite blue chair). But
if somebody creates a new red chair, modelling it after the blue
chair I am sitting on, I do not expect to be booted off of the blue
chair and ending up on sitting on the new red one.
Let's fix this before it hits 'next'. Those who want to create a
new branch and switch to it can do "git checkout B" after doing a
"git branch -c B", and if that operation is so useful and deserves a
short-hand way to do so, perhaps extend "git checkout -b B" to copy
configurations while creating the new branch B.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22 03:24:50 +00:00
|
|
|
test_expect_success 'git branch -c ee ef should copy ee to create branch ef' '
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git checkout -b ee &&
|
|
|
|
git reflog exists refs/heads/ee &&
|
|
|
|
git config branch.ee.dummy Hello &&
|
|
|
|
git branch -c ee ef &&
|
|
|
|
git reflog exists refs/heads/ee &&
|
|
|
|
git reflog exists refs/heads/ef &&
|
|
|
|
test $(git config branch.ee.dummy) = Hello &&
|
|
|
|
test $(git config branch.ef.dummy) = Hello &&
|
branch: fix "copy" to never touch HEAD
When creating a new branch B by copying the branch A that happens to
be the current branch, it also updates HEAD to point at the new
branch. It probably was made this way because "git branch -c A B"
piggybacked its implementation on "git branch -m A B",
This does not match the usual expectation. If I were sitting on a
blue chair, and somebody comes and repaints it to red, I would
accept ending up sitting on a chair that is now red (I am also OK to
stand, instead, as there no longer is my favourite blue chair). But
if somebody creates a new red chair, modelling it after the blue
chair I am sitting on, I do not expect to be booted off of the blue
chair and ending up on sitting on the new red one.
Let's fix this before it hits 'next'. Those who want to create a
new branch and switch to it can do "git checkout B" after doing a
"git branch -c B", and if that operation is so useful and deserves a
short-hand way to do so, perhaps extend "git checkout -b B" to copy
configurations while creating the new branch B.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22 03:24:50 +00:00
|
|
|
test $(git rev-parse --abbrev-ref HEAD) = ee
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c f/f g/g should work' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog f/f &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/f/f &&
|
|
|
|
git config branch.f/f.dummy Hello &&
|
|
|
|
git branch -c f/f g/g &&
|
|
|
|
git reflog exists refs/heads/f/f &&
|
|
|
|
git reflog exists refs/heads/g/g &&
|
|
|
|
test $(git config branch.f/f.dummy) = Hello &&
|
|
|
|
test $(git config branch.g/g.dummy) = Hello
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c m2 m2 should work' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog m2 &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/m2 &&
|
|
|
|
git config branch.m2.dummy Hello &&
|
|
|
|
git branch -c m2 m2 &&
|
|
|
|
git reflog exists refs/heads/m2 &&
|
|
|
|
test $(git config branch.m2.dummy) = Hello
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c zz zz/zz should fail' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog zz &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/zz &&
|
|
|
|
test_must_fail git branch -c zz zz/zz
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c b/b b should fail' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog b/b &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
test_must_fail git branch -c b/b b
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -C o/q o/p should work when o/p exists' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog o/q &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/o/q &&
|
|
|
|
git reflog exists refs/heads/o/p &&
|
|
|
|
git branch -C o/q o/p
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c -f o/q o/p should work when o/p exists' '
|
|
|
|
git reflog exists refs/heads/o/q &&
|
|
|
|
git reflog exists refs/heads/o/p &&
|
|
|
|
git branch -c -f o/q o/p
|
|
|
|
'
|
|
|
|
|
2018-03-10 15:54:16 +00:00
|
|
|
test_expect_success 'git branch -c qq rr/qq should fail when rr exists' '
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git branch qq &&
|
|
|
|
git branch rr &&
|
|
|
|
test_must_fail git branch -c qq rr/qq
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -C b1 b2 should fail when b2 is checked out' '
|
|
|
|
git branch b1 &&
|
|
|
|
git checkout -b b2 &&
|
|
|
|
test_must_fail git branch -C b1 b2
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -C c1 c2 should succeed when c1 is checked out' '
|
|
|
|
git checkout -b c1 &&
|
|
|
|
git branch c2 &&
|
|
|
|
git branch -C c1 c2 &&
|
branch: fix "copy" to never touch HEAD
When creating a new branch B by copying the branch A that happens to
be the current branch, it also updates HEAD to point at the new
branch. It probably was made this way because "git branch -c A B"
piggybacked its implementation on "git branch -m A B",
This does not match the usual expectation. If I were sitting on a
blue chair, and somebody comes and repaints it to red, I would
accept ending up sitting on a chair that is now red (I am also OK to
stand, instead, as there no longer is my favourite blue chair). But
if somebody creates a new red chair, modelling it after the blue
chair I am sitting on, I do not expect to be booted off of the blue
chair and ending up on sitting on the new red one.
Let's fix this before it hits 'next'. Those who want to create a
new branch and switch to it can do "git checkout B" after doing a
"git branch -c B", and if that operation is so useful and deserves a
short-hand way to do so, perhaps extend "git checkout -b B" to copy
configurations while creating the new branch B.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22 03:24:50 +00:00
|
|
|
test $(git rev-parse --abbrev-ref HEAD) = c1
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
branch: fix "copy" to never touch HEAD
When creating a new branch B by copying the branch A that happens to
be the current branch, it also updates HEAD to point at the new
branch. It probably was made this way because "git branch -c A B"
piggybacked its implementation on "git branch -m A B",
This does not match the usual expectation. If I were sitting on a
blue chair, and somebody comes and repaints it to red, I would
accept ending up sitting on a chair that is now red (I am also OK to
stand, instead, as there no longer is my favourite blue chair). But
if somebody creates a new red chair, modelling it after the blue
chair I am sitting on, I do not expect to be booted off of the blue
chair and ending up on sitting on the new red one.
Let's fix this before it hits 'next'. Those who want to create a
new branch and switch to it can do "git checkout B" after doing a
"git branch -c B", and if that operation is so useful and deserves a
short-hand way to do so, perhaps extend "git checkout -b B" to copy
configurations while creating the new branch B.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22 03:24:50 +00:00
|
|
|
test_expect_success 'git branch -C c1 c2 should never touch HEAD' '
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
msg="Branch: copied refs/heads/c1 to refs/heads/c2" &&
|
2023-11-02 08:46:53 +00:00
|
|
|
git reflog HEAD >actual &&
|
|
|
|
! grep "$msg$" actual
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -C main should work when main is checked out' '
|
|
|
|
git checkout main &&
|
|
|
|
git branch -C main
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -C main main should work when main is checked out' '
|
|
|
|
git checkout main &&
|
|
|
|
git branch -C main main
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
2020-12-17 01:07:01 +00:00
|
|
|
test_expect_success 'git branch -C main5 main5 should work when main is checked out' '
|
|
|
|
git checkout main &&
|
2020-09-21 22:01:24 +00:00
|
|
|
git branch main5 &&
|
|
|
|
git branch -C main5 main5
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -C ab cd should overwrite existing config for cd' '
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog cd &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/cd &&
|
|
|
|
git config branch.cd.dummy CD &&
|
2018-06-22 09:23:59 +00:00
|
|
|
git branch --create-reflog ab &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
git reflog exists refs/heads/ab &&
|
|
|
|
git config branch.ab.dummy AB &&
|
|
|
|
git branch -C ab cd &&
|
|
|
|
git reflog exists refs/heads/ab &&
|
|
|
|
git reflog exists refs/heads/cd &&
|
|
|
|
test $(git config branch.ab.dummy) = AB &&
|
|
|
|
test $(git config branch.cd.dummy) = AB
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git branch -c correctly copies multiple config sections' '
|
|
|
|
FOO=1 &&
|
|
|
|
export FOO &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished "git checkout main" &&
|
|
|
|
git checkout -b source2 main &&
|
branch: add a --copy (-c) option to go with --move (-m)
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after submitting the work topic to the list, while
preserving all the tracking info and other configuration that goes
with the branch, and unlike --move keeping the other already-submitted
branch around for reference.
Like --move, when the source branch is the currently checked out
branch the HEAD is moved to the destination branch. In the case of
--move we don't really have a choice (other than remaining on a
detached HEAD) and in order to keep the functionality consistent, we
are doing it in similar way for --copy too.
The most common usage of this feature is expected to be moving to a
new topic branch which is a copy of the current one, in that case
moving to the target branch is what the user wants, and doesn't
unexpectedly behave differently than --move would.
One outstanding caveat of this implementation is that:
git checkout maint &&
git checkout master &&
git branch -c topic &&
git checkout -
Will check out 'maint' instead of 'master'. This is because the @{-N}
feature (or its -1 shorthand "-") relies on HEAD reflogs created by
the checkout command, so in this case we'll checkout maint instead of
master, as the user might expect. What to do about that is left to a
future change.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18 21:19:16 +00:00
|
|
|
|
|
|
|
# Assert that a config file with multiple config sections has
|
|
|
|
# those sections preserved...
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
branch.source2.key1=value1
|
|
|
|
branch.dest2.key1=value1
|
|
|
|
more.gar.b=age
|
|
|
|
branch.source2.key2=value2
|
|
|
|
branch.dest2.key2=value2
|
|
|
|
EOF
|
|
|
|
cat >config.branch <<\EOF &&
|
|
|
|
;; Note the lack of -\EOF above & mixed indenting here. This is
|
|
|
|
;; intentional, we are also testing that the formatting of copied
|
|
|
|
;; sections is preserved.
|
|
|
|
|
|
|
|
;; Comment for source2. Tabs
|
|
|
|
[branch "source2"]
|
|
|
|
;; Comment for the source2 value
|
|
|
|
key1 = value1
|
|
|
|
;; Comment for more.gar. Spaces
|
|
|
|
[more "gar"]
|
|
|
|
;; Comment for the more.gar value
|
|
|
|
b = age
|
|
|
|
;; Comment for source2, again. Mixed tabs/spaces.
|
|
|
|
[branch "source2"]
|
|
|
|
;; Comment for the source2 value, again
|
|
|
|
key2 = value2
|
|
|
|
EOF
|
|
|
|
cat config.branch >>.git/config &&
|
|
|
|
git branch -c source2 dest2 &&
|
|
|
|
git config -f .git/config -l | grep -F -e source2 -e dest2 -e more.gar >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
# ...and that the comments and formatting for those sections
|
|
|
|
# is also preserved.
|
|
|
|
cat >expect <<\EOF &&
|
|
|
|
;; Comment for source2. Tabs
|
|
|
|
[branch "source2"]
|
|
|
|
;; Comment for the source2 value
|
|
|
|
key1 = value1
|
|
|
|
;; Comment for more.gar. Spaces
|
|
|
|
[branch "dest2"]
|
|
|
|
;; Comment for the source2 value
|
|
|
|
key1 = value1
|
|
|
|
;; Comment for more.gar. Spaces
|
|
|
|
[more "gar"]
|
|
|
|
;; Comment for the more.gar value
|
|
|
|
b = age
|
|
|
|
;; Comment for source2, again. Mixed tabs/spaces.
|
|
|
|
[branch "source2"]
|
|
|
|
;; Comment for the source2 value, again
|
|
|
|
key2 = value2
|
|
|
|
[branch "dest2"]
|
|
|
|
;; Comment for the source2 value, again
|
|
|
|
key2 = value2
|
|
|
|
EOF
|
|
|
|
sed -n -e "/Comment for source2/,\$p" .git/config >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2012-10-18 12:05:17 +00:00
|
|
|
test_expect_success 'deleting a symref' '
|
|
|
|
git branch target &&
|
|
|
|
git symbolic-ref refs/heads/symref refs/heads/target &&
|
2012-10-18 12:08:03 +00:00
|
|
|
echo "Deleted branch symref (was refs/heads/target)." >expect &&
|
2012-10-18 12:05:17 +00:00
|
|
|
git branch -d symref >actual &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_exists refs/heads/target &&
|
|
|
|
test_ref_missing refs/heads/symref &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual
|
2012-10-18 12:05:17 +00:00
|
|
|
'
|
|
|
|
|
2012-10-18 12:07:11 +00:00
|
|
|
test_expect_success 'deleting a dangling symref' '
|
|
|
|
git symbolic-ref refs/heads/dangling-symref nowhere &&
|
2023-11-02 08:46:49 +00:00
|
|
|
git symbolic-ref --no-recurse refs/heads/dangling-symref &&
|
2012-10-18 12:08:03 +00:00
|
|
|
echo "Deleted branch dangling-symref (was nowhere)." >expect &&
|
2012-10-18 12:07:11 +00:00
|
|
|
git branch -d dangling-symref >actual &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_missing refs/heads/dangling-symref &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual
|
2012-10-18 12:07:11 +00:00
|
|
|
'
|
|
|
|
|
2014-09-11 01:22:48 +00:00
|
|
|
test_expect_success 'deleting a self-referential symref' '
|
|
|
|
git symbolic-ref refs/heads/self-reference refs/heads/self-reference &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_exists refs/heads/self-reference &&
|
2014-09-11 01:22:48 +00:00
|
|
|
echo "Deleted branch self-reference (was refs/heads/self-reference)." >expect &&
|
|
|
|
git branch -d self-reference >actual &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_missing refs/heads/self-reference &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual
|
2014-09-11 01:22:48 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'renaming a symref is not allowed' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git symbolic-ref refs/heads/topic refs/heads/main &&
|
2020-09-21 22:01:24 +00:00
|
|
|
test_must_fail git branch -m topic new-topic &&
|
|
|
|
git symbolic-ref refs/heads/topic &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_exists refs/heads/main &&
|
|
|
|
test_ref_missing refs/heads/new-topic
|
2008-10-26 02:33:56 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'test tracking setup via --track' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track my1 local/main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
test $(git config branch.my1.remote) = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test $(git config branch.my1.merge) = refs/heads/main
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test tracking setup (non-wildcard, matching)' '
|
|
|
|
git config remote.local.url . &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git config remote.local.fetch refs/heads/main:refs/remotes/local/main &&
|
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track my4 local/main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
test $(git config branch.my4.remote) = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test $(git config branch.my4.merge) = refs/heads/main
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- If "refs/remotes/foo/bar" exists without any association to a remote
(i.e. there is no remote named "foo", or no remote with a refspec
that matches "refs/remotes/foo/bar"), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using "refs/remotes/foo/bar" from repo "." as the upstream, which
works, but is probably not what the user had in mind when running
"git branch baz --track foo/bar".
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 21:52:05 +00:00
|
|
|
test_expect_success 'tracking setup fails on non-matching refspec' '
|
2013-03-20 12:30:12 +00:00
|
|
|
git config remote.local.url . &&
|
2013-09-08 20:58:12 +00:00
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2013-09-08 20:58:12 +00:00
|
|
|
git config remote.local.fetch refs/heads/s:refs/remotes/local/s &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --track my5 local/main &&
|
2013-04-21 21:52:02 +00:00
|
|
|
test_must_fail git config branch.my5.remote &&
|
|
|
|
test_must_fail git config branch.my5.merge
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test tracking setup via config' '
|
|
|
|
git config branch.autosetupmerge true &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch my3 local/main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
test $(git config branch.my3.remote) = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test $(git config branch.my3.merge) = refs/heads/main
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test overriding tracking setup via --no-track' '
|
|
|
|
git config branch.autosetupmerge true &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track my2 local/main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git config branch.autosetupmerge false &&
|
|
|
|
! test "$(git config branch.my2.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
! test "$(git config branch.my2.merge)" = refs/heads/main
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no tracking without .fetch entries' '
|
|
|
|
git config branch.autosetupmerge true &&
|
|
|
|
git branch my6 s &&
|
2013-08-31 04:31:49 +00:00
|
|
|
git config branch.autosetupmerge false &&
|
2013-03-20 12:30:12 +00:00
|
|
|
test -z "$(git config branch.my6.remote)" &&
|
|
|
|
test -z "$(git config branch.my6.merge)"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test tracking setup via --track but deeper' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
(git show-ref -q refs/remotes/local/o/o || git fetch local) &&
|
|
|
|
git branch --track my7 local/o/o &&
|
|
|
|
test "$(git config branch.my7.remote)" = local &&
|
|
|
|
test "$(git config branch.my7.merge)" = refs/heads/o/o
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test deleting branch deletes branch config' '
|
|
|
|
git branch -d my7 &&
|
|
|
|
test -z "$(git config branch.my7.remote)" &&
|
|
|
|
test -z "$(git config branch.my7.merge)"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test deleting branch without config' '
|
|
|
|
git branch my7 s &&
|
|
|
|
sha1=$(git rev-parse my7 | cut -c 1-7) &&
|
|
|
|
echo "Deleted branch my7 (was $sha1)." >expect &&
|
|
|
|
git branch -d my7 >actual 2>&1 &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
2016-03-29 09:38:39 +00:00
|
|
|
test_expect_success 'deleting currently checked out branch fails' '
|
|
|
|
git worktree add -b my7 my7 &&
|
|
|
|
test_must_fail git -C my7 branch -d my7 &&
|
2023-08-07 20:42:36 +00:00
|
|
|
test_must_fail git branch -d my7 2>actual &&
|
2023-10-23 16:06:56 +00:00
|
|
|
grep "^error: cannot delete branch .my7. used by worktree at " actual &&
|
2023-08-07 20:42:36 +00:00
|
|
|
rm -r my7 &&
|
|
|
|
git worktree prune
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'deleting in-use branch fails' '
|
|
|
|
git worktree add my7 &&
|
|
|
|
test_commit -C my7 bt7 &&
|
|
|
|
git -C my7 bisect start HEAD HEAD~2 &&
|
|
|
|
test_must_fail git -C my7 branch -d my7 &&
|
|
|
|
test_must_fail git branch -d my7 2>actual &&
|
2023-10-23 16:06:56 +00:00
|
|
|
grep "^error: cannot delete branch .my7. used by worktree at " actual &&
|
2019-04-29 05:19:43 +00:00
|
|
|
rm -r my7 &&
|
|
|
|
git worktree prune
|
2016-03-29 09:38:39 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'test --track without .fetch entries' '
|
|
|
|
git branch --track my8 &&
|
|
|
|
test "$(git config branch.my8.remote)" &&
|
|
|
|
test "$(git config branch.my8.merge)"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'branch from non-branch HEAD w/autosetupmerge=always' '
|
|
|
|
git config branch.autosetupmerge always &&
|
|
|
|
git branch my9 HEAD^ &&
|
|
|
|
git config branch.autosetupmerge false
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'branch from non-branch HEAD w/--track causes failure' '
|
|
|
|
test_must_fail git branch --track my10 HEAD^
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'branch from tag w/--track causes failure' '
|
|
|
|
git tag foobar &&
|
|
|
|
test_must_fail git branch --track my11 foobar
|
|
|
|
'
|
|
|
|
|
branch: new autosetupmerge option 'simple' for matching branches
With the default push.default option, "simple", beginners are
protected from accidentally pushing to the "wrong" branch in
centralized workflows: if the remote tracking branch they would push
to does not have the same name as the local branch, and they try to do
a "default push", they get an error and explanation with options.
There is a particular centralized workflow where this often happens:
a user branches to a new local topic branch from an existing
remote branch, eg with "checkout -b feature1 origin/master". With
the default branch.autosetupmerge configuration (value "true"), git
will automatically add origin/master as the upstream tracking branch.
When the user pushes with a default "git push", with the intention of
pushing their (new) topic branch to the remote, they get an error, and
(amongst other things) a suggestion to run "git push origin HEAD".
If they follow this suggestion the push succeeds, but on subsequent
default pushes they continue to get an error - so eventually they
figure out to add "-u" to change the tracking branch, or they spelunk
the push.default config doc as proposed and set it to "current", or
some GUI tooling does one or the other of these things for them.
When one of their coworkers later works on the same topic branch,
they don't get any of that "weirdness". They just "git checkout
feature1" and everything works exactly as they expect, with the shared
remote branch set up as remote tracking branch, and push and pull
working out of the box.
The "stable state" for this way of working is that local branches have
the same-name remote tracking branch (origin/feature1 in this
example), and multiple people can work on that remote feature branch
at the same time, trusting "git pull" to merge or rebase as required
for them to be able to push their interim changes to that same feature
branch on that same remote.
(merging from the upstream "master" branch, and merging back to it,
are separate more involved processes in this flow).
There is a problem in this flow/way of working, however, which is that
the first user, when they first branched from origin/master, ended up
with the "wrong" remote tracking branch (different from the stable
state). For a while, before they pushed (and maybe longer, if they
don't use -u/--set-upstream), their "git pull" wasn't getting other
users' changes to the feature branch - it was getting any changes from
the remote "master" branch instead (a completely different class of
changes!)
An experienced git user might say "well yeah, that's what it means to
have the remote tracking branch set to origin/master!" - but the
original user above didn't *ask* to have the remote master branch
added as remote tracking branch - that just happened automatically
when they branched their feature branch. They didn't necessarily even
notice or understand the meaning of the "set up to track 'origin/master'"
message when they created the branch - especially if they are using a
GUI.
Looking at how to fix this, you might think "OK, so disable auto setup
of remote tracking - set branch.autosetupmerge to false" - but that
will inconvenience the *second* user in this story - the one who just
wanted to start working on the topic branch. The first and second
users swap roles at different points in time of course - they should
both have a sane configuration that does the right thing in both
situations.
Make this "branches have the same name locally as on the remote"
workflow less painful / more obvious by introducing a new
branch.autosetupmerge option called "simple", to match the same-name
"push.default" option that makes similar assumptions.
This new option automatically sets up tracking in a *subset* of the
current default situations: when the original ref is a remote tracking
branch *and* has the same branch name on the remote (as the new local
branch name).
Update the error displayed when the 'push.default=simple' configuration
rejects a mismatching-upstream-name default push, to offer this new
branch.autosetupmerge option that will prevent this class of error.
With this new configuration, in the example situation above, the first
user does *not* get origin/master set up as the tracking branch for
the new local branch. If they "git pull" in their new local-only
branch, they get an error explaining there is no upstream branch -
which makes sense and is helpful. If they "git push", they get an
error explaining how to push *and* suggesting they specify
--set-upstream - which is exactly the right thing to do for them.
This new option is likely not appropriate for users intentionally
implementing a "triangular workflow" with a shared upstream tracking
branch, that they "git pull" in and a "private" feature branch that
they push/force-push to just for remote safe-keeping until they are
ready to push up to the shared branch explicitly/separately. Such
users are likely to prefer keeping the current default
merge.autosetupmerge=true behavior, and change their push.default to
"current".
Also extend the existing branch tests with three new cases testing
this option - the obvious matching-name and non-matching-name cases,
and also a non-matching-ref-type case. The matching-name case needs to
temporarily create an independent repo to fetch from, as the general
strategy of using the local repo as the remote in these tests
precludes locally branching with the same name as in the "remote".
Signed-off-by: Tao Klerks <tao@klerks.biz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-29 09:56:44 +00:00
|
|
|
test_expect_success 'simple tracking works when remote branch name matches' '
|
|
|
|
test_when_finished "rm -rf otherserver" &&
|
|
|
|
git init otherserver &&
|
|
|
|
test_commit -C otherserver my_commit 1 &&
|
|
|
|
git -C otherserver branch feature &&
|
|
|
|
test_config branch.autosetupmerge simple &&
|
|
|
|
test_config remote.otherserver.url otherserver &&
|
|
|
|
test_config remote.otherserver.fetch refs/heads/*:refs/remotes/otherserver/* &&
|
|
|
|
git fetch otherserver &&
|
|
|
|
git branch feature otherserver/feature &&
|
|
|
|
test_cmp_config otherserver branch.feature.remote &&
|
|
|
|
test_cmp_config refs/heads/feature branch.feature.merge
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'simple tracking skips when remote branch name does not match' '
|
|
|
|
test_config branch.autosetupmerge simple &&
|
|
|
|
test_config remote.local.url . &&
|
|
|
|
test_config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git fetch local &&
|
|
|
|
git branch my-other local/main &&
|
|
|
|
test_cmp_config "" --default "" branch.my-other.remote &&
|
|
|
|
test_cmp_config "" --default "" branch.my-other.merge
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'simple tracking skips when remote ref is not a branch' '
|
|
|
|
test_config branch.autosetupmerge simple &&
|
|
|
|
test_config remote.localtags.url . &&
|
|
|
|
test_config remote.localtags.fetch refs/tags/*:refs/remotes/localtags/* &&
|
|
|
|
git tag mytag12 main &&
|
|
|
|
git fetch localtags &&
|
|
|
|
git branch mytag12 localtags/mytag12 &&
|
|
|
|
test_cmp_config "" --default "" branch.mytag12.remote &&
|
|
|
|
test_cmp_config "" --default "" branch.mytag12.merge
|
|
|
|
'
|
|
|
|
|
2013-04-01 15:59:14 +00:00
|
|
|
test_expect_success '--set-upstream-to fails on multiple branches' '
|
2020-06-15 11:53:19 +00:00
|
|
|
echo "fatal: too many arguments to set new upstream" >expect &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --set-upstream-to main a b c 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-01 15:59:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--set-upstream-to fails on detached HEAD' '
|
|
|
|
git checkout HEAD^{} &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_when_finished git checkout - &&
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: could not set upstream of HEAD to main when it does not point to any branch" >expect &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --set-upstream-to main 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-01 15:59:14 +00:00
|
|
|
'
|
|
|
|
|
2013-04-02 19:02:53 +00:00
|
|
|
test_expect_success '--set-upstream-to fails on a missing dst branch' '
|
2020-06-15 11:53:19 +00:00
|
|
|
echo "fatal: branch '"'"'does-not-exist'"'"' does not exist" >expect &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --set-upstream-to main does-not-exist 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-02 19:02:53 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--set-upstream-to fails on a missing src branch' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --set-upstream-to does-not-exist main 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "the requested upstream branch '"'"'does-not-exist'"'"' does not exist" err
|
2013-04-02 19:02:53 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--set-upstream-to fails on a non-ref' '
|
2021-12-01 22:15:42 +00:00
|
|
|
echo "fatal: cannot set up tracking information; starting point '"'"'HEAD^{}'"'"' is not a branch" >expect &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --set-upstream-to HEAD^{} 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-02 19:02:53 +00:00
|
|
|
'
|
|
|
|
|
2016-02-22 11:23:23 +00:00
|
|
|
test_expect_success '--set-upstream-to fails on locked config' '
|
|
|
|
test_when_finished "rm -f .git/config.lock" &&
|
|
|
|
>.git/config.lock &&
|
|
|
|
git branch locked &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --set-upstream-to locked 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "could not lock config file .git/config" err
|
2016-02-22 11:23:23 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'use --set-upstream-to modify HEAD' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_config branch.main.remote foo &&
|
|
|
|
test_config branch.main.merge foo &&
|
2013-08-31 04:31:50 +00:00
|
|
|
git branch my12 &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch --set-upstream-to my12 &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.main.remote)" = "." &&
|
|
|
|
test "$(git config branch.main.merge)" = "refs/heads/my12"
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'use --set-upstream-to modify a particular branch' '
|
2013-08-31 04:31:50 +00:00
|
|
|
git branch my13 &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git branch --set-upstream-to main my13 &&
|
2017-08-17 02:54:23 +00:00
|
|
|
test_when_finished "git branch --unset-upstream my13" &&
|
2013-03-20 12:30:12 +00:00
|
|
|
test "$(git config branch.my13.remote)" = "." &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.my13.merge)" = "refs/heads/main"
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--unset-upstream should fail if given a non-existent branch' '
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: branch '"'"'i-dont-exist'"'"' has no upstream information" >expect &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --unset-upstream i-dont-exist 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
2016-02-22 11:23:24 +00:00
|
|
|
test_expect_success '--unset-upstream should fail if config is locked' '
|
|
|
|
test_when_finished "rm -f .git/config.lock" &&
|
|
|
|
git branch --set-upstream-to locked &&
|
|
|
|
>.git/config.lock &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --unset-upstream 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "could not lock config file .git/config" err
|
2016-02-22 11:23:24 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'test --unset-upstream on HEAD' '
|
2013-08-31 04:31:50 +00:00
|
|
|
git branch my14 &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_config branch.main.remote foo &&
|
|
|
|
test_config branch.main.merge foo &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch --set-upstream-to my14 &&
|
|
|
|
git branch --unset-upstream &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git config branch.main.remote &&
|
|
|
|
test_must_fail git config branch.main.merge &&
|
2013-03-20 12:30:12 +00:00
|
|
|
# fail for a branch without upstream set
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: branch '"'"'main'"'"' has no upstream information" >expect &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --unset-upstream 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
|
|
|
|
2013-04-01 15:59:14 +00:00
|
|
|
test_expect_success '--unset-upstream should fail on multiple branches' '
|
2020-06-15 11:53:19 +00:00
|
|
|
echo "fatal: too many arguments to unset upstream" >expect &&
|
|
|
|
test_must_fail git branch --unset-upstream a b c 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-01 15:59:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--unset-upstream should fail on detached HEAD' '
|
|
|
|
git checkout HEAD^{} &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_when_finished git checkout - &&
|
2023-10-23 16:06:56 +00:00
|
|
|
echo "fatal: could not unset upstream of HEAD when it does not point to any branch" >expect &&
|
2020-06-15 11:53:19 +00:00
|
|
|
test_must_fail git branch --unset-upstream 2>err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect err
|
2013-04-01 15:59:14 +00:00
|
|
|
'
|
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'test --unset-upstream on a particular branch' '
|
2013-08-31 04:31:50 +00:00
|
|
|
git branch my15 &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git branch --set-upstream-to main my14 &&
|
2013-03-20 12:30:12 +00:00
|
|
|
git branch --unset-upstream my14 &&
|
|
|
|
test_must_fail git config branch.my14.remote &&
|
|
|
|
test_must_fail git config branch.my14.merge
|
|
|
|
'
|
|
|
|
|
2018-06-17 11:56:27 +00:00
|
|
|
test_expect_success 'disabled option --set-upstream fails' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_must_fail git branch --set-upstream origin/main
|
2012-08-30 17:23:13 +00:00
|
|
|
'
|
|
|
|
|
2021-12-21 03:30:22 +00:00
|
|
|
test_expect_success '--set-upstream-to notices an error to set branch as own upstream' "
|
2014-03-05 07:31:55 +00:00
|
|
|
git branch --set-upstream-to refs/heads/my13 my13 2>actual &&
|
2020-06-15 11:53:18 +00:00
|
|
|
cat >expect <<-\EOF &&
|
2022-01-10 19:52:54 +00:00
|
|
|
warning: not setting branch 'my13' as its own upstream
|
2014-03-05 07:31:55 +00:00
|
|
|
EOF
|
|
|
|
test_expect_code 1 git config branch.my13.remote &&
|
|
|
|
test_expect_code 1 git config branch.my13.merge &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect actual
|
2021-12-21 03:30:22 +00:00
|
|
|
"
|
2014-03-05 07:31:55 +00:00
|
|
|
|
2013-03-20 12:30:12 +00:00
|
|
|
test_expect_success 'git checkout -b g/h/i -l should create a branch and a log' '
|
2024-03-05 20:29:39 +00:00
|
|
|
test_when_finished git checkout main &&
|
2013-03-20 12:30:12 +00:00
|
|
|
GIT_COMMITTER_DATE="2005-05-26 23:30" \
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout -b g/h/i -l main &&
|
2023-10-31 08:16:59 +00:00
|
|
|
test_ref_exists refs/heads/g/h/i &&
|
2024-03-05 20:29:39 +00:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
$HEAD refs/heads/g/h/i@{0}: branch: Created from main
|
|
|
|
EOF
|
2023-11-02 08:46:53 +00:00
|
|
|
git reflog show --no-abbrev-commit refs/heads/g/h/i >actual &&
|
|
|
|
test_cmp expect actual
|
2013-03-20 12:30:12 +00:00
|
|
|
'
|
2007-03-08 09:58:35 +00:00
|
|
|
|
2010-05-22 00:28:38 +00:00
|
|
|
test_expect_success 'checkout -b makes reflog by default' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2010-05-22 00:28:38 +00:00
|
|
|
git config --unset core.logAllRefUpdates &&
|
|
|
|
git checkout -b alpha &&
|
2010-07-21 19:47:48 +00:00
|
|
|
git rev-parse --verify alpha@{0}
|
2010-05-22 00:28:38 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'checkout -b does not make reflog when core.logAllRefUpdates = false' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2010-05-22 00:28:38 +00:00
|
|
|
git config core.logAllRefUpdates false &&
|
|
|
|
git checkout -b beta &&
|
2010-07-21 19:47:48 +00:00
|
|
|
test_must_fail git rev-parse --verify beta@{0}
|
2010-05-22 00:28:38 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'checkout -b with -l makes reflog when core.logAllRefUpdates = false' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2010-05-22 00:28:38 +00:00
|
|
|
git checkout -lb gamma &&
|
|
|
|
git config --unset core.logAllRefUpdates &&
|
2010-07-21 19:47:48 +00:00
|
|
|
git rev-parse --verify gamma@{0}
|
2010-05-22 00:28:38 +00:00
|
|
|
'
|
|
|
|
|
2022-04-01 06:05:13 +00:00
|
|
|
test_expect_success 'avoid ambiguous track and advise' '
|
2008-03-18 02:04:40 +00:00
|
|
|
git config branch.autosetupmerge true &&
|
|
|
|
git config remote.ambi1.url lalala &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git config remote.ambi1.fetch refs/heads/lalala:refs/heads/main &&
|
2008-03-18 02:04:40 +00:00
|
|
|
git config remote.ambi2.url lilili &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git config remote.ambi2.fetch refs/heads/lilili:refs/heads/main &&
|
2022-04-01 06:05:13 +00:00
|
|
|
cat <<-EOF >expected &&
|
|
|
|
fatal: not tracking: ambiguous information for ref '\''refs/heads/main'\''
|
|
|
|
hint: There are multiple remotes whose fetch refspecs map to the remote
|
|
|
|
hint: tracking ref '\''refs/heads/main'\'':
|
|
|
|
hint: ambi1
|
|
|
|
hint: ambi2
|
|
|
|
hint: ''
|
|
|
|
hint: This is typically a configuration error.
|
|
|
|
hint: ''
|
|
|
|
hint: To support setting up tracking branches, ensure that
|
|
|
|
hint: different remotes'\'' fetch refspecs map into different
|
|
|
|
hint: tracking namespaces.
|
|
|
|
EOF
|
|
|
|
test_must_fail git branch all1 main 2>actual &&
|
|
|
|
test_cmp expected actual &&
|
2008-03-18 02:04:40 +00:00
|
|
|
test -z "$(git config branch.all1.merge)"
|
|
|
|
'
|
|
|
|
|
2008-05-10 22:36:29 +00:00
|
|
|
test_expect_success 'autosetuprebase local on a tracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase local &&
|
2008-09-03 08:59:27 +00:00
|
|
|
(git show-ref -q refs/remotes/local/o || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch mybase &&
|
|
|
|
git branch --track myr1 mybase &&
|
|
|
|
test "$(git config branch.myr1.remote)" = . &&
|
|
|
|
test "$(git config branch.myr1.merge)" = refs/heads/mybase &&
|
|
|
|
test "$(git config branch.myr1.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase always on a tracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase always &&
|
2008-09-03 08:59:27 +00:00
|
|
|
(git show-ref -q refs/remotes/local/o || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch mybase2 &&
|
|
|
|
git branch --track myr2 mybase &&
|
|
|
|
test "$(git config branch.myr2.remote)" = . &&
|
|
|
|
test "$(git config branch.myr2.merge)" = refs/heads/mybase &&
|
|
|
|
test "$(git config branch.myr2.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase remote on a tracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase remote &&
|
2008-09-03 08:59:27 +00:00
|
|
|
(git show-ref -q refs/remotes/local/o || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch mybase3 &&
|
|
|
|
git branch --track myr3 mybase2 &&
|
|
|
|
test "$(git config branch.myr3.remote)" = . &&
|
|
|
|
test "$(git config branch.myr3.merge)" = refs/heads/mybase2 &&
|
|
|
|
! test "$(git config branch.myr3.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase never on a tracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase never &&
|
2008-09-03 08:59:27 +00:00
|
|
|
(git show-ref -q refs/remotes/local/o || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch mybase4 &&
|
|
|
|
git branch --track myr4 mybase2 &&
|
|
|
|
test "$(git config branch.myr4.remote)" = . &&
|
|
|
|
test "$(git config branch.myr4.merge)" = refs/heads/mybase2 &&
|
|
|
|
! test "$(git config branch.myr4.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase local on a tracked remote branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track myr5 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr5.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.myr5.merge)" = refs/heads/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
! test "$(git config branch.myr5.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase never on a tracked remote branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase never &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track myr6 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr6.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.myr6.merge)" = refs/heads/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
! test "$(git config branch.myr6.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase remote on a tracked remote branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase remote &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track myr7 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr7.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.myr7.merge)" = refs/heads/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr7.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase always on a tracked remote branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
|
|
|
git config branch.autosetuprebase remote &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track myr8 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr8.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.myr8.merge)" = refs/heads/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr8.rebase)" = true
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase unconfigured on a tracked remote branch' '
|
|
|
|
git config --unset branch.autosetuprebase &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --track myr9 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "$(git config branch.myr9.remote)" = local &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test "$(git config branch.myr9.merge)" = refs/heads/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr9.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase unconfigured on a tracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2008-09-03 08:59:27 +00:00
|
|
|
(git show-ref -q refs/remotes/local/o || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch mybase10 &&
|
|
|
|
git branch --track myr10 mybase2 &&
|
|
|
|
test "$(git config branch.myr10.remote)" = . &&
|
|
|
|
test "$(git config branch.myr10.merge)" = refs/heads/mybase2 &&
|
|
|
|
test "z$(git config branch.myr10.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase unconfigured on untracked local branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch --no-track myr11 mybase2 &&
|
|
|
|
test "z$(git config branch.myr11.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr11.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr11.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase unconfigured on untracked remote branch' '
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track myr12 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr12.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr12.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr12.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase never on an untracked local branch' '
|
|
|
|
git config branch.autosetuprebase never &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch --no-track myr13 mybase2 &&
|
|
|
|
test "z$(git config branch.myr13.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr13.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr13.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase local on an untracked local branch' '
|
|
|
|
git config branch.autosetuprebase local &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch --no-track myr14 mybase2 &&
|
|
|
|
test "z$(git config branch.myr14.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr14.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr14.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase remote on an untracked local branch' '
|
|
|
|
git config branch.autosetuprebase remote &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch --no-track myr15 mybase2 &&
|
|
|
|
test "z$(git config branch.myr15.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr15.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr15.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase always on an untracked local branch' '
|
|
|
|
git config branch.autosetuprebase always &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
2008-05-10 22:36:29 +00:00
|
|
|
git branch --no-track myr16 mybase2 &&
|
|
|
|
test "z$(git config branch.myr16.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr16.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr16.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase never on an untracked remote branch' '
|
|
|
|
git config branch.autosetuprebase never &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track myr17 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr17.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr17.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr17.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase local on an untracked remote branch' '
|
|
|
|
git config branch.autosetuprebase local &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track myr18 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr18.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr18.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr18.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase remote on an untracked remote branch' '
|
|
|
|
git config branch.autosetuprebase remote &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track myr19 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr19.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr19.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr19.rebase)" = z
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'autosetuprebase always on an untracked remote branch' '
|
|
|
|
git config branch.autosetuprebase always &&
|
|
|
|
git config remote.local.url . &&
|
|
|
|
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
|
2020-12-17 01:07:01 +00:00
|
|
|
(git show-ref -q refs/remotes/local/main || git fetch local) &&
|
|
|
|
git branch --no-track myr20 local/main &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test "z$(git config branch.myr20.remote)" = z &&
|
|
|
|
test "z$(git config branch.myr20.merge)" = z &&
|
|
|
|
test "z$(git config branch.myr20.rebase)" = z
|
|
|
|
'
|
|
|
|
|
2011-02-16 23:12:20 +00:00
|
|
|
test_expect_success 'autosetuprebase always on detached HEAD' '
|
|
|
|
git config branch.autosetupmerge always &&
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished git checkout main &&
|
2011-02-16 23:12:20 +00:00
|
|
|
git checkout HEAD^0 &&
|
|
|
|
git branch my11 &&
|
|
|
|
test -z "$(git config branch.my11.remote)" &&
|
|
|
|
test -z "$(git config branch.my11.merge)"
|
|
|
|
'
|
|
|
|
|
2008-05-10 22:36:29 +00:00
|
|
|
test_expect_success 'detect misconfigured autosetuprebase (bad value)' '
|
|
|
|
git config branch.autosetuprebase garbage &&
|
|
|
|
test_must_fail git branch
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'detect misconfigured autosetuprebase (no value)' '
|
|
|
|
git config --unset branch.autosetuprebase &&
|
2013-03-20 12:30:12 +00:00
|
|
|
echo "[branch] autosetuprebase" >>.git/config &&
|
2008-05-10 22:36:29 +00:00
|
|
|
test_must_fail git branch &&
|
|
|
|
git config --unset branch.autosetuprebase
|
|
|
|
'
|
|
|
|
|
2009-12-30 06:43:04 +00:00
|
|
|
test_expect_success 'attempt to delete a branch without base and unmerged to HEAD' '
|
|
|
|
git checkout my9 &&
|
|
|
|
git config --unset branch.my8.merge &&
|
|
|
|
test_must_fail git branch -d my8
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'attempt to delete a branch merged to its base' '
|
|
|
|
# we are on my9 which is the initial commit; traditionally
|
|
|
|
# we would not have allowed deleting my8 that is not merged
|
2020-12-17 01:07:01 +00:00
|
|
|
# to my9, but it is set to track main that already has my8
|
|
|
|
git config branch.my8.merge refs/heads/main &&
|
2009-12-30 06:43:04 +00:00
|
|
|
git branch -d my8
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'attempt to delete a branch merged to its base' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2009-12-30 06:43:04 +00:00
|
|
|
echo Third >>A &&
|
|
|
|
git commit -m "Third commit" A &&
|
|
|
|
git branch -t my10 my9 &&
|
|
|
|
git branch -f my10 HEAD^ &&
|
2020-12-17 01:07:01 +00:00
|
|
|
# we are on main which is at the third commit, and my10
|
2009-12-30 06:43:04 +00:00
|
|
|
# is behind us, so traditionally we would have allowed deleting
|
|
|
|
# it; but my10 is set to track my9 that is further behind.
|
|
|
|
test_must_fail git branch -d my10
|
|
|
|
'
|
|
|
|
|
2021-08-27 18:35:35 +00:00
|
|
|
test_expect_success 'branch --delete --force removes dangling branch' '
|
|
|
|
git checkout main &&
|
|
|
|
test_commit unstable &&
|
|
|
|
hash=$(git rev-parse HEAD) &&
|
|
|
|
objpath=$(echo $hash | sed -e "s|^..|.git/objects/&/|") &&
|
|
|
|
git branch --no-track dangling &&
|
|
|
|
mv $objpath $objpath.x &&
|
|
|
|
test_when_finished "mv $objpath.x $objpath" &&
|
|
|
|
git branch --delete --force dangling &&
|
|
|
|
git for-each-ref refs/heads/dangling >actual &&
|
|
|
|
test_must_be_empty actual
|
|
|
|
'
|
|
|
|
|
2012-02-06 01:13:36 +00:00
|
|
|
test_expect_success 'use --edit-description' '
|
branch: do not fail a no-op --edit-desc
Imagine running "git branch --edit-description" while on a branch
without the branch description, and then exit the editor after
emptying the edit buffer, which is the way to tell the command that
you changed your mind and you do not want the description after all.
The command should just happily oblige, adding no branch description
for the current branch, and exit successfully. But it fails to do
so:
$ git init -b main
$ git commit --allow-empty -m commit
$ GIT_EDITOR=: git branch --edit-description
fatal: could not unset 'branch.main.description'
The end result is OK in that the configuration variable does not
exist in the resulting repository, but we should do better. If we
know we didn't have a description, and if we are asked not to have a
description by the editor, we can just return doing nothing.
This of course introduces TOCTOU. If you add a branch description
to the same branch from another window, while you had the editor
open to edit the description, and then exit the editor without
writing anything there, we'd end up not removing the description you
added in the other window. But you are fooling yourself in your own
repository at that point, and if it hurts, you'd be better off not
doing so ;-).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-30 18:06:22 +00:00
|
|
|
EDITOR=: git branch --edit-description &&
|
2022-10-25 22:57:18 +00:00
|
|
|
test_expect_code 1 git config branch.main.description &&
|
branch: do not fail a no-op --edit-desc
Imagine running "git branch --edit-description" while on a branch
without the branch description, and then exit the editor after
emptying the edit buffer, which is the way to tell the command that
you changed your mind and you do not want the description after all.
The command should just happily oblige, adding no branch description
for the current branch, and exit successfully. But it fails to do
so:
$ git init -b main
$ git commit --allow-empty -m commit
$ GIT_EDITOR=: git branch --edit-description
fatal: could not unset 'branch.main.description'
The end result is OK in that the configuration variable does not
exist in the resulting repository, but we should do better. If we
know we didn't have a description, and if we are asked not to have a
description by the editor, we can just return doing nothing.
This of course introduces TOCTOU. If you add a branch description
to the same branch from another window, while you had the editor
open to edit the description, and then exit the editor without
writing anything there, we'd end up not removing the description you
added in the other window. But you are fooling yourself in your own
repository at that point, and if it hurts, you'd be better off not
doing so ;-).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-30 18:06:22 +00:00
|
|
|
|
2012-02-06 01:13:36 +00:00
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
echo "New contents" >"$1"
|
|
|
|
EOF
|
|
|
|
EDITOR=./editor git branch --edit-description &&
|
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
git stripspace -s <"$1" >"EDITOR_OUTPUT"
|
|
|
|
EOF
|
|
|
|
EDITOR=./editor git branch --edit-description &&
|
|
|
|
echo "New contents" >expect &&
|
2018-10-05 21:54:04 +00:00
|
|
|
test_cmp expect EDITOR_OUTPUT
|
2012-02-06 01:13:36 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'detect typo in branch name when using --edit-description' '
|
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
echo "New contents" >"$1"
|
|
|
|
EOF
|
2014-03-18 18:54:05 +00:00
|
|
|
test_must_fail env EDITOR=./editor git branch --edit-description no-such-branch
|
2012-02-06 01:13:36 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'refuse --edit-description on unborn branch for now' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished "git checkout main" &&
|
2012-02-06 01:13:36 +00:00
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
echo "New contents" >"$1"
|
|
|
|
EOF
|
|
|
|
git checkout --orphan unborn &&
|
2014-03-18 18:54:05 +00:00
|
|
|
test_must_fail env EDITOR=./editor git branch --edit-description
|
2012-02-06 01:13:36 +00:00
|
|
|
'
|
|
|
|
|
2012-02-27 15:11:53 +00:00
|
|
|
test_expect_success '--merged catches invalid object names' '
|
|
|
|
test_must_fail git branch --merged 0000000000000000000000000000000000000000
|
|
|
|
'
|
|
|
|
|
2018-04-03 14:47:15 +00:00
|
|
|
test_expect_success '--list during rebase' '
|
|
|
|
test_when_finished "reset_rebase" &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git checkout main &&
|
2018-04-03 14:47:15 +00:00
|
|
|
FAKE_LINES="1 edit 2" &&
|
|
|
|
export FAKE_LINES &&
|
|
|
|
set_fake_editor &&
|
|
|
|
git rebase -i HEAD~2 &&
|
|
|
|
git branch --list >actual &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "rebasing main" actual
|
2018-04-03 14:47:15 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--list during rebase from detached HEAD' '
|
2020-12-17 01:07:01 +00:00
|
|
|
test_when_finished "reset_rebase && git checkout main" &&
|
|
|
|
git checkout main^0 &&
|
2018-04-03 14:47:15 +00:00
|
|
|
oid=$(git rev-parse --short HEAD) &&
|
|
|
|
FAKE_LINES="1 edit 2" &&
|
|
|
|
export FAKE_LINES &&
|
|
|
|
set_fake_editor &&
|
|
|
|
git rebase -i HEAD~2 &&
|
|
|
|
git branch --list >actual &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "rebasing detached HEAD $oid" actual
|
2018-04-03 14:47:15 +00:00
|
|
|
'
|
|
|
|
|
2013-09-08 20:58:15 +00:00
|
|
|
test_expect_success 'tracking with unexpected .fetch refspec' '
|
2013-09-14 07:36:24 +00:00
|
|
|
rm -rf a b c d &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main a &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
(
|
|
|
|
cd a &&
|
|
|
|
test_commit a
|
|
|
|
) &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main b &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
(
|
|
|
|
cd b &&
|
|
|
|
test_commit b
|
|
|
|
) &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main c &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
(
|
|
|
|
cd c &&
|
|
|
|
test_commit c &&
|
|
|
|
git remote add a ../a &&
|
|
|
|
git remote add b ../b &&
|
|
|
|
git fetch --all
|
|
|
|
) &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main d &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
(
|
|
|
|
cd d &&
|
|
|
|
git remote add c ../c &&
|
|
|
|
git config remote.c.fetch "+refs/remotes/*:refs/remotes/*" &&
|
|
|
|
git fetch c &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git branch --track local/a/main remotes/a/main &&
|
|
|
|
test "$(git config branch.local/a/main.remote)" = "c" &&
|
|
|
|
test "$(git config branch.local/a/main.merge)" = "refs/remotes/a/main" &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
git rev-parse --verify a >expect &&
|
2020-12-17 01:07:01 +00:00
|
|
|
git rev-parse --verify local/a/main >actual &&
|
t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact within
the domain of a remote, and we then use that information to deduce the
upstream configuration (branch.<name>.remote and branch.<name>.merge).
However, with that change, we also check that - in addition to a matching
refspec - the result of mapping the tracking branch through that refspec
(i.e. the corresponding ref name in the remote repo) happens to start with
"refs/heads/". In other words, we require that a tracking branch refers to
a _branch_ in the remote repo.
Now, consider that you are e.g. setting up an automated building/testing
infrastructure for a group of similar "source" repositories. The build/test
infrastructure consists of a central scheduler, and a number of build/test
"slave" machines that perform the actual build/test work. The scheduler
monitors the group of similar repos for changes (e.g. with a periodic
"git fetch"), and triggers builds/tests to be run on one or more slaves.
Graphically the changes flow between the repos like this:
Source #1 -------v ----> Slave #1
/
Source #2 -----> Scheduler -----> Slave #2
\
Source #3 -------^ ----> Slave #3
... ...
The scheduler maintains a single Git repo with each of the source repos set
up as distinct remotes. The slaves also need access to all the changes from
all of the source repos, so they pull from the scheduler repo, but using the
following custom refspec:
remote.origin.fetch = "+refs/remotes/*:refs/remotes/*"
This makes all of the scheduler's remote-tracking branches automatically
available as identical remote-tracking branches in each of the slaves.
Now, consider what happens if a slave tries to create a local branch with
one of the remote-tracking branches as upstream:
git branch local_branch --track refs/remotes/source-1/some_branch
Git now looks at the configured remotes (in this case there is only "origin",
pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch
matching origin's refspec. Mapping through that refspec we find that the
corresponding remote ref name is "refs/remotes/source-1/some_branch".
However, since this remote ref name does not start with "refs/heads/", we
discard it as a suitable upstream, and the whole command fails.
This patch adds a testcase demonstrating this failure by creating two
source repos ("a" and "b") that are forwarded through a scheduler ("c")
to a slave repo ("d"), that then tries create a local branch with an
upstream. See the next patch in this series for the exciting conclusion
to this story...
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:14 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2018-08-16 09:35:08 +00:00
|
|
|
test_expect_success 'configured committerdate sort' '
|
2020-12-17 01:07:01 +00:00
|
|
|
git init -b main sort &&
|
ref-filter.c: really don't sort when using --no-sort
When '--no-sort' is passed to 'for-each-ref', 'tag', and 'branch', the
printed refs are still sorted by ascending refname. Change the handling of
sort options in these commands so that '--no-sort' to truly disables
sorting.
'--no-sort' does not disable sorting in these commands is because their
option parsing does not distinguish between "the absence of '--sort'"
(and/or values for tag.sort & branch.sort) and '--no-sort'. Both result in
an empty 'sorting_options' string list, which is parsed by
'ref_sorting_options()' to create the 'struct ref_sorting *' for the
command. If the string list is empty, 'ref_sorting_options()' interprets
that as "the absence of '--sort'" and returns the default ref sorting
structure (equivalent to "refname" sort).
To handle '--no-sort' properly while preserving the "refname" sort in the
"absence of --sort'" case, first explicitly add "refname" to the string list
*before* parsing options. This alone doesn't actually change any behavior,
since 'compare_refs()' already falls back on comparing refnames if two refs
are equal w.r.t all other sort keys.
Now that the string list is populated by default, '--no-sort' is the only
way to empty the 'sorting_options' string list. Update
'ref_sorting_options()' to return a NULL 'struct ref_sorting *' if the
string list is empty, and add a condition to 'ref_array_sort()' to skip the
sort altogether if the sort structure is NULL. Note that other functions
using 'struct ref_sorting *' do not need any changes because they already
ignore NULL values.
Finally, remove the condition around sorting in 'ls-remote', since it's no
longer necessary. Unlike 'for-each-ref' et. al., it does *not* do any
sorting by default. This default is preserved by simply leaving its sort key
string list empty before parsing options; if no additional sort keys are
set, 'struct ref_sorting *' is NULL and sorting is skipped.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-14 19:53:49 +00:00
|
|
|
test_config -C sort branch.sort "committerdate" &&
|
|
|
|
|
2018-08-16 09:35:08 +00:00
|
|
|
(
|
|
|
|
cd sort &&
|
|
|
|
test_commit initial &&
|
|
|
|
git checkout -b a &&
|
|
|
|
test_commit a &&
|
|
|
|
git checkout -b c &&
|
|
|
|
test_commit c &&
|
|
|
|
git checkout -b b &&
|
|
|
|
test_commit b &&
|
|
|
|
git branch >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
2020-12-17 01:07:01 +00:00
|
|
|
main
|
2018-08-16 09:35:08 +00:00
|
|
|
a
|
|
|
|
c
|
|
|
|
* b
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'option override configured sort' '
|
ref-filter.c: really don't sort when using --no-sort
When '--no-sort' is passed to 'for-each-ref', 'tag', and 'branch', the
printed refs are still sorted by ascending refname. Change the handling of
sort options in these commands so that '--no-sort' to truly disables
sorting.
'--no-sort' does not disable sorting in these commands is because their
option parsing does not distinguish between "the absence of '--sort'"
(and/or values for tag.sort & branch.sort) and '--no-sort'. Both result in
an empty 'sorting_options' string list, which is parsed by
'ref_sorting_options()' to create the 'struct ref_sorting *' for the
command. If the string list is empty, 'ref_sorting_options()' interprets
that as "the absence of '--sort'" and returns the default ref sorting
structure (equivalent to "refname" sort).
To handle '--no-sort' properly while preserving the "refname" sort in the
"absence of --sort'" case, first explicitly add "refname" to the string list
*before* parsing options. This alone doesn't actually change any behavior,
since 'compare_refs()' already falls back on comparing refnames if two refs
are equal w.r.t all other sort keys.
Now that the string list is populated by default, '--no-sort' is the only
way to empty the 'sorting_options' string list. Update
'ref_sorting_options()' to return a NULL 'struct ref_sorting *' if the
string list is empty, and add a condition to 'ref_array_sort()' to skip the
sort altogether if the sort structure is NULL. Note that other functions
using 'struct ref_sorting *' do not need any changes because they already
ignore NULL values.
Finally, remove the condition around sorting in 'ls-remote', since it's no
longer necessary. Unlike 'for-each-ref' et. al., it does *not* do any
sorting by default. This default is preserved by simply leaving its sort key
string list empty before parsing options; if no additional sort keys are
set, 'struct ref_sorting *' is NULL and sorting is skipped.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-14 19:53:49 +00:00
|
|
|
test_config -C sort branch.sort "committerdate" &&
|
|
|
|
|
2018-08-16 09:35:08 +00:00
|
|
|
(
|
|
|
|
cd sort &&
|
|
|
|
git branch --sort=refname >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a
|
|
|
|
* b
|
|
|
|
c
|
2020-12-17 01:07:01 +00:00
|
|
|
main
|
2018-08-16 09:35:08 +00:00
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
ref-filter.c: really don't sort when using --no-sort
When '--no-sort' is passed to 'for-each-ref', 'tag', and 'branch', the
printed refs are still sorted by ascending refname. Change the handling of
sort options in these commands so that '--no-sort' to truly disables
sorting.
'--no-sort' does not disable sorting in these commands is because their
option parsing does not distinguish between "the absence of '--sort'"
(and/or values for tag.sort & branch.sort) and '--no-sort'. Both result in
an empty 'sorting_options' string list, which is parsed by
'ref_sorting_options()' to create the 'struct ref_sorting *' for the
command. If the string list is empty, 'ref_sorting_options()' interprets
that as "the absence of '--sort'" and returns the default ref sorting
structure (equivalent to "refname" sort).
To handle '--no-sort' properly while preserving the "refname" sort in the
"absence of --sort'" case, first explicitly add "refname" to the string list
*before* parsing options. This alone doesn't actually change any behavior,
since 'compare_refs()' already falls back on comparing refnames if two refs
are equal w.r.t all other sort keys.
Now that the string list is populated by default, '--no-sort' is the only
way to empty the 'sorting_options' string list. Update
'ref_sorting_options()' to return a NULL 'struct ref_sorting *' if the
string list is empty, and add a condition to 'ref_array_sort()' to skip the
sort altogether if the sort structure is NULL. Note that other functions
using 'struct ref_sorting *' do not need any changes because they already
ignore NULL values.
Finally, remove the condition around sorting in 'ls-remote', since it's no
longer necessary. Unlike 'for-each-ref' et. al., it does *not* do any
sorting by default. This default is preserved by simply leaving its sort key
string list empty before parsing options; if no additional sort keys are
set, 'struct ref_sorting *' is NULL and sorting is skipped.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-14 19:53:49 +00:00
|
|
|
test_expect_success '--no-sort cancels config sort keys' '
|
|
|
|
test_config -C sort branch.sort "-refname" &&
|
|
|
|
|
|
|
|
(
|
|
|
|
cd sort &&
|
|
|
|
|
|
|
|
# objecttype is identical for all of them, so sort falls back on
|
|
|
|
# default (ascending refname)
|
|
|
|
git branch \
|
|
|
|
--no-sort \
|
|
|
|
--sort="objecttype" >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a
|
|
|
|
* b
|
|
|
|
c
|
|
|
|
main
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-sort cancels command line sort keys' '
|
|
|
|
(
|
|
|
|
cd sort &&
|
|
|
|
|
|
|
|
# objecttype is identical for all of them, so sort falls back on
|
|
|
|
# default (ascending refname)
|
|
|
|
git branch \
|
|
|
|
--sort="-refname" \
|
|
|
|
--no-sort \
|
|
|
|
--sort="objecttype" >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a
|
|
|
|
* b
|
|
|
|
c
|
|
|
|
main
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-sort without subsequent --sort prints expected branches' '
|
|
|
|
(
|
|
|
|
cd sort &&
|
|
|
|
|
|
|
|
# Sort the results with `sort` for a consistent comparison
|
|
|
|
# against expected
|
|
|
|
git branch --no-sort | sort >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
a
|
|
|
|
c
|
|
|
|
main
|
|
|
|
* b
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2018-08-16 09:35:08 +00:00
|
|
|
test_expect_success 'invalid sort parameter in configuration' '
|
ref-filter.c: really don't sort when using --no-sort
When '--no-sort' is passed to 'for-each-ref', 'tag', and 'branch', the
printed refs are still sorted by ascending refname. Change the handling of
sort options in these commands so that '--no-sort' to truly disables
sorting.
'--no-sort' does not disable sorting in these commands is because their
option parsing does not distinguish between "the absence of '--sort'"
(and/or values for tag.sort & branch.sort) and '--no-sort'. Both result in
an empty 'sorting_options' string list, which is parsed by
'ref_sorting_options()' to create the 'struct ref_sorting *' for the
command. If the string list is empty, 'ref_sorting_options()' interprets
that as "the absence of '--sort'" and returns the default ref sorting
structure (equivalent to "refname" sort).
To handle '--no-sort' properly while preserving the "refname" sort in the
"absence of --sort'" case, first explicitly add "refname" to the string list
*before* parsing options. This alone doesn't actually change any behavior,
since 'compare_refs()' already falls back on comparing refnames if two refs
are equal w.r.t all other sort keys.
Now that the string list is populated by default, '--no-sort' is the only
way to empty the 'sorting_options' string list. Update
'ref_sorting_options()' to return a NULL 'struct ref_sorting *' if the
string list is empty, and add a condition to 'ref_array_sort()' to skip the
sort altogether if the sort structure is NULL. Note that other functions
using 'struct ref_sorting *' do not need any changes because they already
ignore NULL values.
Finally, remove the condition around sorting in 'ls-remote', since it's no
longer necessary. Unlike 'for-each-ref' et. al., it does *not* do any
sorting by default. This default is preserved by simply leaving its sort key
string list empty before parsing options; if no additional sort keys are
set, 'struct ref_sorting *' is NULL and sorting is skipped.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-14 19:53:49 +00:00
|
|
|
test_config -C sort branch.sort "v:notvalid" &&
|
|
|
|
|
2018-08-16 09:35:08 +00:00
|
|
|
(
|
|
|
|
cd sort &&
|
for-each-ref: delay parsing of --sort=<atom> options
The for-each-ref family of commands invoke parsers immediately when
it sees each --sort=<atom> option, and die before even seeing the
other options on the command line when the <atom> is unrecognised.
Instead, accumulate them in a string list, and have them parsed into
a ref_sorting structure after the command line parsing is done. As
a consequence, "git branch --sort=bogus -h" used to fail to give the
brief help, which arguably may have been a feature, now does so,
which is more consistent with how other options work.
The patch is smaller than the actual extent of the "damage" to the
codebase, thanks to the fact that the original code consistently
used OPT_REF_SORT() macro to handle command line options. We only
needed to replace the variable used for the list, and implementation
of the callback function used in the macro.
The old rule was for the users of the API to:
- Declare ref_sorting and ref_sorting_tail variables;
- OPT_REF_SORT() macro will instantiate ref_sorting instance (which
may barf and die) and append it to the tail;
- Append to the tail each ref_sorting read from the configuration
by parsing in the config callback (which may barf and die);
- See if ref_sorting is null and use ref_sorting_default() instead.
Now the rule is not all that different but is simpler:
- Declare ref_sorting_options string list.
- OPT_REF_SORT() macro will append it to the string list;
- Append to the string list the sort key read from the
configuration;
- call ref_sorting_options() to turn the string list to ref_sorting
structure (which also deals with the default value).
As side effects, this change also cleans up a few issues:
- 95be717c (parse_opt_ref_sorting: always use with NONEG flag,
2019-03-20) muses that "git for-each-ref --no-sort" should simply
clear the sort keys accumulated so far; it now does.
- The implementation detail of "struct ref_sorting" and the helper
function parse_ref_sorting() can now be private to the ref-filter
API implementation.
- If you set branch.sort to a bogus value, the any "git branch"
invocation, not only the listing mode, would abort with the
original code; now it doesn't
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-20 19:23:53 +00:00
|
|
|
|
|
|
|
# this works in the "listing" mode, so bad sort key
|
|
|
|
# is a dying offence.
|
|
|
|
test_must_fail git branch &&
|
|
|
|
|
|
|
|
# these do not need to use sorting, and should all
|
|
|
|
# succeed
|
|
|
|
git branch newone main &&
|
|
|
|
git branch -c newone newerone &&
|
|
|
|
git branch -m newone newestone &&
|
|
|
|
git branch -d newerone newestone
|
2018-08-16 09:35:08 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
branch: add flags and config to inherit tracking
It can be helpful when creating a new branch to use the existing
tracking configuration from the branch point. However, there is
currently not a method to automatically do so.
Teach git-{branch,checkout,switch} an "inherit" argument to the
"--track" option. When this is set, creating a new branch will cause the
tracking configuration to default to the configuration of the branch
point, if set.
For example, if branch "main" tracks "origin/main", and we run
`git checkout --track=inherit -b feature main`, then branch "feature"
will track "origin/main". Thus, `git status` will show us how far
ahead/behind we are from origin, and `git pull` will pull from origin.
This is particularly useful when creating branches across many
submodules, such as with `git submodule foreach ...` (or if running with
a patch such as [1], which we use at $job), as it avoids having to
manually set tracking info for each submodule.
Since we've added an argument to "--track", also add "--track=direct" as
another way to explicitly get the original "--track" behavior ("--track"
without an argument still works as well).
Finally, teach branch.autoSetupMerge a new "inherit" option. When this
is set, "--track=inherit" becomes the default behavior.
[1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21 03:30:23 +00:00
|
|
|
test_expect_success 'tracking info copied with --track=inherit' '
|
|
|
|
git branch --track=inherit foo2 my1 &&
|
|
|
|
test_cmp_config local branch.foo2.remote &&
|
|
|
|
test_cmp_config refs/heads/main branch.foo2.merge
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'tracking info copied with autoSetupMerge=inherit' '
|
|
|
|
test_unconfig branch.autoSetupMerge &&
|
|
|
|
# default config does not copy tracking info
|
|
|
|
git branch foo-no-inherit my1 &&
|
|
|
|
test_cmp_config "" --default "" branch.foo-no-inherit.remote &&
|
|
|
|
test_cmp_config "" --default "" branch.foo-no-inherit.merge &&
|
|
|
|
# with autoSetupMerge=inherit, we copy tracking info from my1
|
|
|
|
test_config branch.autoSetupMerge inherit &&
|
|
|
|
git branch foo3 my1 &&
|
|
|
|
test_cmp_config local branch.foo3.remote &&
|
|
|
|
test_cmp_config refs/heads/main branch.foo3.merge &&
|
|
|
|
# no tracking info to inherit from main
|
|
|
|
git branch main2 main &&
|
|
|
|
test_cmp_config "" --default "" branch.main2.remote &&
|
|
|
|
test_cmp_config "" --default "" branch.main2.merge
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--track overrides branch.autoSetupMerge' '
|
|
|
|
test_config branch.autoSetupMerge inherit &&
|
|
|
|
git branch --track=direct foo4 my1 &&
|
|
|
|
test_cmp_config . branch.foo4.remote &&
|
|
|
|
test_cmp_config refs/heads/my1 branch.foo4.merge &&
|
|
|
|
git branch --no-track foo5 my1 &&
|
|
|
|
test_cmp_config "" --default "" branch.foo5.remote &&
|
|
|
|
test_cmp_config "" --default "" branch.foo5.merge
|
|
|
|
'
|
|
|
|
|
2024-03-05 20:29:43 +00:00
|
|
|
test_expect_success 'errors if given a bad branch name' '
|
|
|
|
cat <<-\EOF >expect &&
|
|
|
|
fatal: '\''foo..bar'\'' is not a valid branch name
|
|
|
|
hint: See `man git check-ref-format`
|
|
|
|
hint: Disable this message with "git config advice.refSyntax false"
|
|
|
|
EOF
|
|
|
|
test_must_fail git branch foo..bar >actual 2>&1 &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2005-09-08 02:13:26 +00:00
|
|
|
test_done
|