git/t/t3200-branch.sh

1385 lines
43 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2005 Amos Waterland
#
test_description='git branch assorted tests'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-rebase.sh
test_expect_success 'prepare a trivial repository' '
echo Hello >A &&
git update-index --add A &&
git commit -m "Initial commit." &&
echo World >>A &&
git update-index --add A &&
git commit -m "Second commit." &&
HEAD=$(git rev-parse --verify HEAD)
'
test_expect_success 'git branch --help should not have created a bogus branch' '
test_might_fail git branch --man --help </dev/null >/dev/null 2>&1 &&
test_path_is_missing .git/refs/heads/--help
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +00:00
'
test_expect_success 'branch -h in broken repository' '
mkdir broken &&
(
cd broken &&
git init &&
>.git/refs/heads/master &&
test_expect_code 129 git branch -h >usage 2>&1
) &&
test_i18ngrep "[Uu]sage" broken/usage
'
test_expect_success 'git branch abc should create a branch' '
git branch abc && test_path_is_file .git/refs/heads/abc
'
test_expect_success 'git branch a/b/c should create a branch' '
git branch a/b/c && test_path_is_file .git/refs/heads/a/b/c
'
test_expect_success 'git branch mb master... should create a branch' '
git branch mb master... && test_path_is_file .git/refs/heads/mb
'
test_expect_success 'git branch HEAD should fail' '
test_must_fail git branch HEAD
'
cat >expect <<EOF
$ZERO_OID $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
EOF
test_expect_success 'git branch --create-reflog d/e/f should create a branch and a log' '
GIT_COMMITTER_DATE="2005-05-26 23:30" \
git -c core.logallrefupdates=false branch --create-reflog d/e/f &&
test_path_is_file .git/refs/heads/d/e/f &&
test_path_is_file .git/logs/refs/heads/d/e/f &&
test_cmp expect .git/logs/refs/heads/d/e/f
'
test_expect_success 'git branch -d d/e/f should delete a branch and a log' '
git branch -d d/e/f &&
test_path_is_missing .git/refs/heads/d/e/f &&
test_must_fail git reflog exists refs/heads/d/e/f
'
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 &&
test_i18ngrep "branch name required" err
'
test_expect_success 'git branch -m m broken_symref should work' '
test_when_finished "git branch -D broken_symref" &&
git branch --create-reflog m &&
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
'
test_expect_success 'git branch -m m m/m should work' '
git branch --create-reflog m &&
git branch -m m m/m &&
git reflog exists refs/heads/m/m
'
test_expect_success 'git branch -m n/n n should work' '
git branch --create-reflog n/n &&
git branch -m n/n n &&
git reflog exists refs/heads/n
'
# 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 &&
test_when_finished git checkout master &&
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" &&
test_when_finished git checkout master &&
git checkout -b foo &&
git branch -m foo/bar &&
git symbolic-ref HEAD >actual &&
echo refs/heads/foo/bar >expect &&
test_cmp expect actual
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
git branch o/p &&
test_must_fail git branch -m o/o o
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +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
'
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
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
test_must_fail git branch -m q r/q
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +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
'
test_expect_success 'git branch -M baz bam should succeed when baz is checked out' '
git checkout -b baz &&
git branch bam &&
git branch -M baz bam &&
test $(git rev-parse --abbrev-ref HEAD) = bam
'
test_expect_success 'git branch -M baz bam should add entries to .git/logs/HEAD' '
msg="Branch: renamed refs/heads/baz to refs/heads/bam" &&
grep " 0\{40\}.*$msg$" .git/logs/HEAD &&
grep "^0\{40\}.*$msg$" .git/logs/HEAD
'
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' '
git init orphan &&
(
cd orphan &&
test_commit initial &&
git checkout --orphan lonely &&
grep lonely .git/HEAD &&
test_path_is_missing .git/refs/head/lonely &&
git branch -M master mistress &&
grep lonely .git/HEAD
)
'
test_expect_success 'resulting reflog can be shown by log -g' '
oid=$(git rev-parse HEAD) &&
cat >expect <<-EOF &&
HEAD@{0} $oid $msg
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 &&
test_cmp expect actual
'
test_expect_success 'git branch -M baz bam should succeed when baz is checked out as linked working tree' '
git checkout master &&
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 &&
test $(git -C bazdir2 rev-parse --abbrev-ref HEAD) = bam
'
test_expect_success 'git branch -M baz bam should succeed within a worktree in which baz is checked out' '
git checkout -b baz &&
git worktree add -f bazdir3 baz &&
(
cd bazdir3 &&
git branch -M baz bam &&
test $(git rev-parse --abbrev-ref HEAD) = bam
) &&
test $(git rev-parse --abbrev-ref HEAD) = bam
'
test_expect_success 'git branch -M master should work when master is checked out' '
git checkout master &&
git branch -M master
'
test_expect_success 'git branch -M master master should work when master is checked out' '
git checkout master &&
git branch -M master master
'
test_expect_success 'git branch -M master2 master2 should work when master is checked out' '
git checkout master &&
git branch master2 &&
git branch -M master2 master2
'
test_expect_success 'git branch -v -d t should work' '
git branch t &&
git rev-parse --verify refs/heads/t &&
git branch -v -d t &&
test_must_fail git rev-parse --verify refs/heads/t
'
test_expect_success 'git branch -v -m t s should work' '
git branch t &&
git rev-parse --verify refs/heads/t &&
git branch -v -m t s &&
test_must_fail git rev-parse --verify refs/heads/t &&
git rev-parse --verify refs/heads/s &&
git branch -d s
'
test_expect_success 'git branch -m -d t s should fail' '
git branch t &&
git rev-parse refs/heads/t &&
test_must_fail git branch -m -d t s &&
git branch -d t &&
test_must_fail git rev-parse refs/heads/t
'
test_expect_success 'git branch --list -d t should fail' '
git branch t &&
git rev-parse refs/heads/t &&
test_must_fail git branch --list -d t &&
git branch -d t &&
test_must_fail git rev-parse refs/heads/t
'
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 &&
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" &&
git init nonbare &&
test_commit -C nonbare x &&
git clone --bare nonbare bare &&
git -C bare worktree add --detach ../secondary master &&
git -C secondary branch -D master
'
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 &&
test_cmp actual.noabbrev actual.0abbrev &&
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
'
test_expect_success 'git branch --column' '
COLUMNS=81 git branch --column=column >actual &&
cat >expected <<\EOF &&
a/b/c bam foo l * master mb o/o q
abc bar j/k m/m master2 n o/p r
EOF
test_cmp expected actual
'
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 &&
cat >expected <<EOF &&
a/b/c
abc
bam
bar
foo
j/k
l
m/m
* master
master2
mb
n
o/o
o/p
q
r
$long
EOF
test_cmp expected actual
'
test_expect_success 'git branch with column.*' '
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 &&
cat >expected <<\EOF &&
a/b/c bam foo l * master mb o/o q
abc bar j/k m/m master2 n o/p r
EOF
test_cmp expected actual
'
test_expect_success 'git branch --column -v should fail' '
test_must_fail git branch --column -v
'
test_expect_success 'git branch -v with column.ui ignored' '
git config column.ui column &&
COLUMNS=80 git branch -v | cut -c -10 | sed "s/ *$//" >actual &&
git config --unset column.ui &&
cat >expected <<\EOF &&
a/b/c
abc
bam
bar
foo
j/k
l
m/m
* master
master2
mb
n
o/o
o/p
q
r
EOF
test_cmp expected actual
'
mv .git/config .git/config-saved
test_expect_success 'git branch -m q q2 without config should succeed' '
git branch -m q q2 &&
git branch -m q2 q
'
mv .git/config-saved .git/config
git config branch.s/s.dummy Hello
test_expect_success 'git branch -m s/s s should work when s/t is deleted' '
git branch --create-reflog s/s &&
git reflog exists refs/heads/s/s &&
git branch --create-reflog s/t &&
git reflog exists refs/heads/s/t &&
git branch -d s/t &&
git branch -m s/s s &&
git reflog exists refs/heads/s
'
test_expect_success 'config information was renamed, too' '
test $(git config branch.s.dummy) = Hello &&
test_must_fail git config branch.s/s.dummy
'
test_expect_success 'git branch -m correctly renames multiple config sections' '
test_when_finished "git checkout master" &&
git checkout -b source master &&
# 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 &&
test_i18ngrep "branch name required" err
'
test_expect_success 'git branch --copy dumps usage' '
test_expect_code 128 git branch --copy 2>err &&
test_i18ngrep "branch name required" err
'
test_expect_success 'git branch -c d e should work' '
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' '
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
'
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 &&
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' '
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' '
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' '
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' '
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' '
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
'
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 &&
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
'
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" &&
! grep "$msg$" .git/logs/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
'
test_expect_success 'git branch -C master should work when master is checked out' '
git checkout master &&
git branch -C master
'
test_expect_success 'git branch -C master master should work when master is checked out' '
git checkout master &&
git branch -C master master
'
test_expect_success 'git branch -C master5 master5 should work when master is checked out' '
git checkout master &&
git branch master5 &&
git branch -C master5 master5
'
test_expect_success 'git branch -C ab cd should overwrite existing config for cd' '
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 &&
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 &&
test_when_finished "git checkout master" &&
git checkout -b source2 master &&
# 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
'
test_expect_success 'deleting a symref' '
git branch target &&
git symbolic-ref refs/heads/symref refs/heads/target &&
echo "Deleted branch symref (was refs/heads/target)." >expect &&
git branch -d symref >actual &&
test_path_is_file .git/refs/heads/target &&
test_path_is_missing .git/refs/heads/symref &&
test_i18ncmp expect actual
'
test_expect_success 'deleting a dangling symref' '
git symbolic-ref refs/heads/dangling-symref nowhere &&
test_path_is_file .git/refs/heads/dangling-symref &&
echo "Deleted branch dangling-symref (was nowhere)." >expect &&
git branch -d dangling-symref >actual &&
test_path_is_missing .git/refs/heads/dangling-symref &&
test_i18ncmp expect actual
'
test_expect_success 'deleting a self-referential symref' '
git symbolic-ref refs/heads/self-reference refs/heads/self-reference &&
test_path_is_file .git/refs/heads/self-reference &&
echo "Deleted branch self-reference (was refs/heads/self-reference)." >expect &&
git branch -d self-reference >actual &&
test_path_is_missing .git/refs/heads/self-reference &&
test_i18ncmp expect actual
'
test_expect_success 'renaming a symref is not allowed' '
git symbolic-ref refs/heads/master2 refs/heads/master &&
test_must_fail git branch -m master2 master3 &&
git symbolic-ref refs/heads/master2 &&
test_path_is_file .git/refs/heads/master &&
test_path_is_missing .git/refs/heads/master3
'
test_expect_success SYMLINKS 'git branch -m u v should fail when the reflog for u is a symlink' '
git branch --create-reflog u &&
mv .git/logs/refs/heads/u real-u &&
ln -s real-u .git/logs/refs/heads/u &&
test_must_fail git branch -m u v
'
test_expect_success 'test tracking setup via --track' '
git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track my1 local/master &&
test $(git config branch.my1.remote) = local &&
test $(git config branch.my1.merge) = refs/heads/master
'
test_expect_success 'test tracking setup (non-wildcard, matching)' '
git config remote.local.url . &&
git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track my4 local/master &&
test $(git config branch.my4.remote) = local &&
test $(git config branch.my4.merge) = refs/heads/master
'
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' '
git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git config remote.local.fetch refs/heads/s:refs/remotes/local/s &&
test_must_fail git branch --track my5 local/master &&
test_must_fail git config branch.my5.remote &&
test_must_fail git config branch.my5.merge
'
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch my3 local/master &&
test $(git config branch.my3.remote) = local &&
test $(git config branch.my3.merge) = refs/heads/master
'
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track my2 local/master &&
git config branch.autosetupmerge false &&
! test "$(git config branch.my2.remote)" = local &&
! test "$(git config branch.my2.merge)" = refs/heads/master
'
test_expect_success 'no tracking without .fetch entries' '
git config branch.autosetupmerge true &&
git branch my6 s &&
git config branch.autosetupmerge false &&
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 &&
test_i18ncmp expect actual
'
test_expect_success 'deleting currently checked out branch fails' '
git worktree add -b my7 my7 &&
test_must_fail git -C my7 branch -d my7 &&
test_must_fail git branch -d my7
'
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
'
test_expect_success '--set-upstream-to fails on multiple branches' '
test_must_fail git branch --set-upstream-to master a b c
'
test_expect_success '--set-upstream-to fails on detached HEAD' '
git checkout HEAD^{} &&
test_must_fail git branch --set-upstream-to master &&
git checkout -
'
test_expect_success '--set-upstream-to fails on a missing dst branch' '
test_must_fail git branch --set-upstream-to master does-not-exist
'
test_expect_success '--set-upstream-to fails on a missing src branch' '
test_must_fail git branch --set-upstream-to does-not-exist master
'
test_expect_success '--set-upstream-to fails on a non-ref' '
test_must_fail git branch --set-upstream-to HEAD^{}
'
test_expect_success '--set-upstream-to fails on locked config' '
test_when_finished "rm -f .git/config.lock" &&
>.git/config.lock &&
git branch locked &&
test_must_fail git branch --set-upstream-to locked
'
test_expect_success 'use --set-upstream-to modify HEAD' '
test_config branch.master.remote foo &&
test_config branch.master.merge foo &&
git branch my12 &&
git branch --set-upstream-to my12 &&
test "$(git config branch.master.remote)" = "." &&
test "$(git config branch.master.merge)" = "refs/heads/my12"
'
test_expect_success 'use --set-upstream-to modify a particular branch' '
git branch my13 &&
git branch --set-upstream-to master my13 &&
test_when_finished "git branch --unset-upstream my13" &&
test "$(git config branch.my13.remote)" = "." &&
test "$(git config branch.my13.merge)" = "refs/heads/master"
'
test_expect_success '--unset-upstream should fail if given a non-existent branch' '
test_must_fail git branch --unset-upstream i-dont-exist
'
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 &&
test_must_fail git branch --unset-upstream
'
test_expect_success 'test --unset-upstream on HEAD' '
git branch my14 &&
test_config branch.master.remote foo &&
test_config branch.master.merge foo &&
git branch --set-upstream-to my14 &&
git branch --unset-upstream &&
test_must_fail git config branch.master.remote &&
test_must_fail git config branch.master.merge &&
# fail for a branch without upstream set
test_must_fail git branch --unset-upstream
'
test_expect_success '--unset-upstream should fail on multiple branches' '
test_must_fail git branch --unset-upstream a b c
'
test_expect_success '--unset-upstream should fail on detached HEAD' '
git checkout HEAD^{} &&
test_must_fail git branch --unset-upstream &&
git checkout -
'
test_expect_success 'test --unset-upstream on a particular branch' '
git branch my15 &&
git branch --set-upstream-to master my14 &&
git branch --unset-upstream my14 &&
test_must_fail git config branch.my14.remote &&
test_must_fail git config branch.my14.merge
'
test_expect_success 'disabled option --set-upstream fails' '
test_must_fail git branch --set-upstream origin/master
'
test_expect_success '--set-upstream-to notices an error to set branch as own upstream' '
git branch --set-upstream-to refs/heads/my13 my13 2>actual &&
cat >expected <<-\EOF &&
warning: Not setting branch my13 as its own upstream.
EOF
test_expect_code 1 git config branch.my13.remote &&
test_expect_code 1 git config branch.my13.merge &&
test_i18ncmp expected actual
'
# Keep this test last, as it changes the current branch
cat >expect <<EOF
$ZERO_OID $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
EOF
test_expect_success 'git checkout -b g/h/i -l should create a branch and a log' '
GIT_COMMITTER_DATE="2005-05-26 23:30" \
git checkout -b g/h/i -l master &&
test_path_is_file .git/refs/heads/g/h/i &&
test_path_is_file .git/logs/refs/heads/g/h/i &&
test_cmp expect .git/logs/refs/heads/g/h/i
'
test_expect_success 'checkout -b makes reflog by default' '
git checkout master &&
git config --unset core.logAllRefUpdates &&
git checkout -b alpha &&
git rev-parse --verify alpha@{0}
'
test_expect_success 'checkout -b does not make reflog when core.logAllRefUpdates = false' '
git checkout master &&
git config core.logAllRefUpdates false &&
git checkout -b beta &&
test_must_fail git rev-parse --verify beta@{0}
'
test_expect_success 'checkout -b with -l makes reflog when core.logAllRefUpdates = false' '
git checkout master &&
git checkout -lb gamma &&
git config --unset core.logAllRefUpdates &&
git rev-parse --verify gamma@{0}
'
test_expect_success 'avoid ambiguous track' '
git config branch.autosetupmerge true &&
git config remote.ambi1.url lalala &&
git config remote.ambi1.fetch refs/heads/lalala:refs/heads/master &&
git config remote.ambi2.url lilili &&
git config remote.ambi2.fetch refs/heads/lilili:refs/heads/master &&
test_must_fail git branch all1 master &&
test -z "$(git config branch.all1.merge)"
'
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 &&
(git show-ref -q refs/remotes/local/o || git fetch local) &&
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 &&
(git show-ref -q refs/remotes/local/o || git fetch local) &&
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 &&
(git show-ref -q refs/remotes/local/o || git fetch local) &&
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 &&
(git show-ref -q refs/remotes/local/o || git fetch local) &&
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 &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track myr5 local/master &&
test "$(git config branch.myr5.remote)" = local &&
test "$(git config branch.myr5.merge)" = refs/heads/master &&
! 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 &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track myr6 local/master &&
test "$(git config branch.myr6.remote)" = local &&
test "$(git config branch.myr6.merge)" = refs/heads/master &&
! 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 &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track myr7 local/master &&
test "$(git config branch.myr7.remote)" = local &&
test "$(git config branch.myr7.merge)" = refs/heads/master &&
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 &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track myr8 local/master &&
test "$(git config branch.myr8.remote)" = local &&
test "$(git config branch.myr8.merge)" = refs/heads/master &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --track myr9 local/master &&
test "$(git config branch.myr9.remote)" = local &&
test "$(git config branch.myr9.merge)" = refs/heads/master &&
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/* &&
(git show-ref -q refs/remotes/local/o || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track myr12 local/master &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track myr17 local/master &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track myr18 local/master &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track myr19 local/master &&
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/* &&
(git show-ref -q refs/remotes/local/master || git fetch local) &&
git branch --no-track myr20 local/master &&
test "z$(git config branch.myr20.remote)" = z &&
test "z$(git config branch.myr20.merge)" = z &&
test "z$(git config branch.myr20.rebase)" = z
'
test_expect_success 'autosetuprebase always on detached HEAD' '
git config branch.autosetupmerge always &&
test_when_finished git checkout master &&
git checkout HEAD^0 &&
git branch my11 &&
test -z "$(git config branch.my11.remote)" &&
test -z "$(git config branch.my11.merge)"
'
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 &&
echo "[branch] autosetuprebase" >>.git/config &&
test_must_fail git branch &&
git config --unset branch.autosetuprebase
'
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
# to my9, but it is set to track master that already has my8
git config branch.my8.merge refs/heads/master &&
git branch -d my8
'
test_expect_success 'attempt to delete a branch merged to its base' '
git checkout master &&
echo Third >>A &&
git commit -m "Third commit" A &&
git branch -t my10 my9 &&
git branch -f my10 HEAD^ &&
# we are on master which is at the third commit, and my10
# 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
'
test_expect_success 'use --edit-description' '
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 &&
test_cmp expect EDITOR_OUTPUT
'
test_expect_success 'detect typo in branch name when using --edit-description' '
write_script editor <<-\EOF &&
echo "New contents" >"$1"
EOF
test_must_fail env EDITOR=./editor git branch --edit-description no-such-branch
'
test_expect_success 'refuse --edit-description on unborn branch for now' '
write_script editor <<-\EOF &&
echo "New contents" >"$1"
EOF
git checkout --orphan unborn &&
test_must_fail env EDITOR=./editor git branch --edit-description
'
test_expect_success '--merged catches invalid object names' '
test_must_fail git branch --merged 0000000000000000000000000000000000000000
'
test_expect_success '--merged is incompatible with --no-merged' '
test_must_fail git branch --merged HEAD --no-merged HEAD
'
test_expect_success '--list during rebase' '
test_when_finished "reset_rebase" &&
git checkout master &&
FAKE_LINES="1 edit 2" &&
export FAKE_LINES &&
set_fake_editor &&
git rebase -i HEAD~2 &&
git branch --list >actual &&
test_i18ngrep "rebasing master" actual
'
test_expect_success '--list during rebase from detached HEAD' '
test_when_finished "reset_rebase && git checkout master" &&
git checkout master^0 &&
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 &&
test_i18ngrep "rebasing detached HEAD $oid" actual
'
branch.c: Relax unnecessary requirement on upstream's remote ref name When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch.<name>.remote and branch.<name>.merge. However, if the matching refspec does not have refs/heads/<something> on the remote side, we end up rejecting the match, and failing the upstream configuration. It could be argued that when we set up an branch's upstream, we want that upstream to also be a proper branch in the remote repo. Although this is typically the common case, there are cases (as demonstrated by the previous patch in this series) where this requirement prevents a useful upstream relationship from being formed. Furthermore: - We have fundamentally no say in how the remote repo have organized its branches. The remote repo may put branches (or branch-like constructs that are insteresting for downstreams to track) outside refs/heads/*. - The user may intentionally want to track a non-branch from a remote repo, by using a branch and configured upstream in the local repo. Relaxing the checking to only require a matching remote/refspec allows the testcase introduced in the previous patch to succeed, and has no negative effect on the rest of the test suite. This patch fixes a behavior (arguably a regression) first introduced in 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) on 2013-04-21 (released in >= v1.8.3.2). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08 20:58:15 +00:00
test_expect_success 'tracking with unexpected .fetch refspec' '
rm -rf a b c 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
git init a &&
(
cd a &&
test_commit a
) &&
git init b &&
(
cd b &&
test_commit b
) &&
git init c &&
(
cd c &&
test_commit c &&
git remote add a ../a &&
git remote add b ../b &&
git fetch --all
) &&
git init d &&
(
cd d &&
git remote add c ../c &&
git config remote.c.fetch "+refs/remotes/*:refs/remotes/*" &&
git fetch c &&
git branch --track local/a/master remotes/a/master &&
test "$(git config branch.local/a/master.remote)" = "c" &&
test "$(git config branch.local/a/master.merge)" = "refs/remotes/a/master" &&
git rev-parse --verify a >expect &&
git rev-parse --verify local/a/master >actual &&
test_cmp expect actual
)
'
test_expect_success 'configured committerdate sort' '
git init sort &&
(
cd sort &&
git config branch.sort committerdate &&
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 &&
master
a
c
* b
EOF
test_cmp expect actual
)
'
test_expect_success 'option override configured sort' '
(
cd sort &&
git config branch.sort committerdate &&
git branch --sort=refname >actual &&
cat >expect <<-\EOF &&
a
* b
c
master
EOF
test_cmp expect actual
)
'
test_expect_success 'invalid sort parameter in configuration' '
(
cd sort &&
git config branch.sort "v:notvalid" &&
test_must_fail git branch
)
'
test_done