summaryrefslogtreecommitdiff
path: root/t/t3200-branch.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-04-18Merge branch 'ky/branch-m-worktree'Libravatar Junio C Hamano1-1/+22
When "git worktree" feature is in use, "git branch -m" renamed a branch that is checked out in another worktree without adjusting the HEAD symbolic ref for the worktree. * ky/branch-m-worktree: set_worktree_head_symref(): fix error message branch -m: update all per-worktree HEADs refs: add a new function set_worktree_head_symref
2016-04-04branch -m: update all per-worktree HEADsLibravatar Kazuki Yamaguchi1-1/+22
When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-29branch -d: refuse deleting a branch which is currently checked outLibravatar Kazuki Yamaguchi1-0/+6
When a branch is checked out by current working tree, deleting the branch is forbidden. However when the branch is checked out only by other working trees, deleting incorrectly succeeds. Use find_shared_symref() to check if the branch is in use, not just comparing with the current working tree's HEAD. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: die on config error when unsetting upstreamLibravatar Patrick Steinhardt1-0/+7
When we try to unset upstream configurations we do not check return codes for the `git_config_set` functions. As those may indicate that we were unable to unset the respective configuration we may exit successfully without any error message while in fact the upstream configuration was not unset. Fix this by dying with an error message when we cannot unset the configuration. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: report errors in tracking branch setupLibravatar Patrick Steinhardt1-1/+8
When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-6/+6
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Merge branch 'mg/branch-d-m-f'Libravatar Junio C Hamano1-0/+14
"git branch -d" (delete) and "git branch -m" (move) learned to honor "-f" (force) flag; unlike many other subcommands, the way to force these have been with separate "-D/-M" options, which was inconsistent. * mg/branch-d-m-f: branch: allow -f with -m and -d t3200-branch: test -M
2014-12-09branch: allow -f with -m and -dLibravatar Michael J Gruber1-0/+5
-f/--force is the standard way to force an action, and is used by branch for the recreation of existing branches, but not for deleting unmerged branches nor for renaming to an existing branch. Make "-m -f" equivalent to "-M" and "-d -f" equivalent to" -D", i.e. allow -f/--force to be used with -m/-d also. For the list modes, "-f" is simply ignored. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-04t3200-branch: test -MLibravatar Michael J Gruber1-0/+9
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15branch -d: avoid repeated symref resolutionLibravatar Jonathan Nieder1-0/+9
If a repository gets in a broken state with too much symref nesting, it cannot be repaired with "git branch -d": $ git symbolic-ref refs/heads/nonsense refs/heads/nonsense $ git branch -d nonsense error: branch 'nonsense' not found. Worse, "git update-ref --no-deref -d" doesn't work for such repairs either: $ git update-ref -d refs/heads/nonsense error: unable to resolve reference refs/heads/nonsense: Too many levels of symbolic links Fix both by teaching resolve_ref_unsafe a new RESOLVE_REF_NO_RECURSE flag and passing it when appropriate. Callers can still read the value of a symref (for example to print a message about it) with that flag set --- resolve_ref_unsafe will resolve one level of symrefs and stop there. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'dt/tests-with-env-not-subshell'Libravatar Junio C Hamano1-10/+2
* dt/tests-with-env-not-subshell: tests: use "env" to run commands with temporary env-var settings
2014-03-19tests: use "env" to run commands with temporary env-var settingsLibravatar David Tran1-10/+2
Ordinarily, we would say "VAR=VAL command" to execute a tested command with environment variable(s) set only for that command. This however does not work if 'command' is a shell function (most notably 'test_must_fail'); the result of the assignment is retained and affects later commands. To avoid this, we used to assign and export environment variables and run such a test in a subshell, like so: ( VAR=VAL && export VAR && test_must_fail git command to be tested ) But with "env" utility, we should be able to say: test_must_fail env VAR=VAL git command to be tested which is much shorter and easier to read. Signed-off-by: David Tran <unsignedzero@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-06t3200-branch: test setting branch as own upstreamLibravatar Brian Gesiak1-0/+10
No test asserts that "git branch -u refs/heads/my-branch my-branch" avoids leaving nonsense configuration and emits a warning. Add a test that does so. Signed-off-by: Brian Gesiak <modocache@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01Merge branch 'js/test-help-format-windows-port-fix'Libravatar Junio C Hamano1-1/+1
* js/test-help-format-windows-port-fix: t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is html
2013-10-30t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is htmlLibravatar Johannes Sixt1-1/+1
We have the build configuration option DEFAULT_MAN_FORMAT to choose a format different from man pages to be used by 'git help' when no format is requested explicitly. Since 65db0443 (Set the default help format to html for msys builds, 2013-06-04) we use html on Windows by default. There is one test in t3200-branch.sh that invokes a help page. The intent of the redirections applied to the command invocation is to avoid that the man page viewer interferes with the automated test. But when the default format is not "man", this does not have the intended effect, and the HTML manual page is opened during the test run. Request "man" format explicitly to keep the test silent. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-20Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano1-1/+37
Fix a minor regression in v1.8.3.2 and later that made it impossible to base your local work on anything but a local branch of the upstream repository you are tracking from. * jh/checkout-auto-tracking: t3200: fix failure on case-insensitive filesystems branch.c: Relax unnecessary requirement on upstream's remote ref name t3200: Add test demonstrating minor regression in 41c21f2 Refer to branch.<name>.remote/merge when documenting --track t3200: Minor fix when preparing for tracking failure t2024: Fix &&-chaining and a couple of typos
2013-09-17t3200: fix failure on case-insensitive filesystemsLibravatar Eric Sunshine1-0/+1
62d94a3a (t3200: Add test demonstrating minor regression in 41c21f2; 2013-09-08) introduced a test which creates a directory named 'a', however, on case-insensitive filesystems, this action fails with a "fatal: cannot mkdir a: File exists" error due to a file named 'A' left over from earlier tests. Resolve this problem. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09branch.c: Relax unnecessary requirement on upstream's remote ref nameLibravatar Per Cederqvist1-1/+1
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-09t3200: Add test demonstrating minor regression in 41c21f2Libravatar Johan Herland1-0/+34
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-09t3200: Minor fix when preparing for tracking failureLibravatar Johan Herland1-1/+2
We're testing that trying to --track a ref that is not covered by any remote refspec should fail. For that, we want to have refs/remotes/local/master present, but we also want the remote.local.fetch refspec to NOT match refs/remotes/local/master (so that the tracking setup will fail, as intended). However, when doing "git fetch local" to ensure the existence of refs/remotes/local/master, we must not already have changed remote.local.fetch so as to cause refs/remotes/local/master not to be fetched. Therefore, set remote.local.fetch to refs/heads/*:refs/remotes/local/* BEFORE we fetch, and then reset it to refs/heads/s:refs/remotes/local/s AFTER we have fetched (but before we test --track). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: fix broken && chainsLibravatar Felipe Contreras1-4/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: fix typoLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: trivial style fixLibravatar Felipe Contreras1-1/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21branch.c: Validate tracking branches with refspecs instead of refs/remotes/*Libravatar Johan Herland1-1/+1
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-21t3200.39: tracking setup should fail if there is no matching refspec.Libravatar Johan Herland1-4/+4
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ "belong" to a configured remote by being matched by the "dst" side of a fetch refspec. This patch encodes the new expected behavior of this test, and marks the test with "test_expect_failure" in anticipation of a following patch to introduce the new behavior. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Merge branch 'jk/set-upstream-error-cases'Libravatar Junio C Hamano1-0/+12
The handing by "git branch --set-upstream-to" against various forms of errorneous inputs were suboptimal. * jk/set-upstream-error-cases: branch: give advice when tracking start-point is missing branch: mention start_name in set-upstream error messages branch: improve error message for missing --set-upstream-to ref branch: factor out "upstream is not a branch" error messages t3200: test --set-upstream-to with bogus refs
2013-04-03Merge branch 'jm/branch-rename-nothing-error'Libravatar Junio C Hamano1-1/+1
"git branch -m" without any argument noticed an error, but with an incorrect error message. * jm/branch-rename-nothing-error: branch: give better message when no names specified for rename
2013-04-02t3200: test --set-upstream-to with bogus refsLibravatar Jeff King1-0/+12
These tests pass with the current code, but let's make sure we don't accidentally break the behavior in the future. Note that our tests expect failure when we try to set the upstream to or from a missing branch. Technically we are just munging config here, so we do not need the refs to exist. But seeing that they do exist is a good check that the user has not made a typo. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'rr/test-3200-style'Libravatar Junio C Hamano1-253/+267
Churns. * rr/test-3200-style: t3200 (branch): modernize style
2013-03-31branch: give better message when no names specified for renameLibravatar Jonathon Mah1-1/+1
Signed-off-by: Jonathon Mah <me@JonathonMah.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20t3200 (branch): modernize styleLibravatar Ramkumar Ramachandra1-233/+244
Style is inconsistent throughout the file. Make the following changes: 1. Indent everything with tabs. 2. Put the opening quote (') for the test in the same line as test_expect_success, and the closing quote on a line by itself. 3. Do not add extra space between redirection operator and filename, i.e. "cmd >dst", not "cmd > dst". Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-23branch: segfault fixes and validationLibravatar Nguyễn Thái Ngọc Duy1-0/+21
branch_get() can return NULL (so far on detached HEAD only) but some code paths in builtin/branch.c cannot deal with that and cause segfaults. While at there, make sure to bail out when the user gives 2 or more branches with --set-upstream-to or --unset-upstream, where only the first branch is processed and the rest silently dropped. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30branch: give a more helpful message on redundant argumentsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: show targets of deleted symrefs, not sha1sLibravatar René Scharfe1-3/+2
git branch reports the abbreviated hash of the head commit of a deleted branch to make it easier for a user to undo the operation. For symref branches this doesn't help. Print the symref target instead for them. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: skip commit checks when deleting symref branchesLibravatar René Scharfe1-0/+9
Before a branch is deleted, we check that it points to a valid commit. With -d we also check that the commit is a merged; this check is not done with -D. The reason for that is that commits pointed to by branches should never go missing; if they do then something broke and it's better to stop instead of adding to the mess. And a non-merged commit may contain changes that are worth preserving, so we require the stronger option -D instead of -d to get rid of them. If a branch consists of a symref, these concerns don't apply. Deleting such a branch can't make a commit become unreferenced, so we don't need to check if it is merged, or even if it is actually a valid commit. Skip them in that case. This allows us to delete dangling symref branches. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: delete symref branch, not its targetLibravatar René Scharfe1-0/+11
If a branch that is to be deleted happens to be a symref to another branch, the current code removes the targeted branch instead of the one it was called for. Change this surprising behaviour and delete the symref branch instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'cn/branch-set-upstream-to'Libravatar Junio C Hamano1-0/+70
"git branch --set-upstream origin/master" is a common mistake to create a local branch 'origin/master' and set it to integrate with the current branch. With a plan to deprecate this option, introduce "git branch (-u|--set-upstream-to) origin/master" that sets the current branch to integrate with 'origin/master' remote tracking branch. * cn/branch-set-upstream-to: branch: deprecate --set-upstream and show help if we detect possible mistaken use branch: add --unset-upstream option branch: introduce --set-upstream-to
2012-08-30branch: deprecate --set-upstream and show help if we detect possible ↵Libravatar Carlos Martín Nieto1-0/+34
mistaken use This interface is error prone, and a better one (--set-upstream-to) exists. Add a message listing the alternatives and suggest how to fix a --set-upstream invocation in case the user only gives one argument which causes a local branch with the same name as a remote-tracking one to be created. The typical case is git branch --set-upstream origin/master when the user meant git branch --set-upstream master origin/master assuming that the current branch is master. Show a message telling the user how to undo their action and get what they wanted. For the command above, the message would be The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch origin/master set up to track local branch master. If you wanted to make 'master' track 'origin/master', do this: git branch -d origin/master git branch --set-upstream-to origin/master Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30branch: add --unset-upstream optionLibravatar Carlos Martín Nieto1-0/+22
We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-2/+2
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-23branch: introduce --set-upstream-toLibravatar Carlos Martín Nieto1-0/+14
The existing --set-uptream option can cause confusion, as it uses the usual branch convention of assuming a starting point of HEAD if none is specified, causing git branch --set-upstream origin/master to create a new local branch 'origin/master' that tracks the current branch. As --set-upstream already exists, we can't simply change its behaviour. To work around this, introduce --set-upstream-to which accepts a compulsory argument indicating what the new upstream branch should be and one optinal argument indicating which branch to change, defaulting to HEAD. The new options allows us to type git branch --set-upstream-to origin/master to set the current branch's upstream to be origin's master. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-03Merge branch 'nd/columns'Libravatar Junio C Hamano1-0/+77
A couple of commands learn --column option to produce columnar output. By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1) * nd/columns: tag: add --column column: support piping stdout to external git-column process status: add --column branch: add --column help: reuse print_columns() for help -a column: add dense layout support t9002: work around shells that are unable to set COLUMNS to 1 column: add columnar layout Stop starting pager recursively Add column layout skeleton and git-column
2012-04-27branch: add --columnLibravatar Nguyễn Thái Ngọc Duy1-0/+77
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01Merge branch 'cn/maint-branch-with-bad'Libravatar Junio C Hamano1-0/+4
* cn/maint-branch-with-bad: branch: don't assume the merge filter ref exists Conflicts: t/t3200-branch.sh
2012-02-27branch: don't assume the merge filter ref existsLibravatar Carlos Martín Nieto1-0/+4
print_ref_list looks up the merge_filter_ref and assumes that a valid pointer is returned. When the object doesn't exist, it tries to dereference a NULL pointer. This can be the case when git branch --merged is given an argument that isn't a valid commit name. Check whether the lookup returns a NULL pointer and die with an error if it does. Add a test, while we're at it. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05branch --edit-description: protect against mistyped branch nameLibravatar Junio C Hamano1-4/+37
It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'rr/test-chaining'Libravatar Junio C Hamano1-2/+2
* rr/test-chaining: t3401: use test_commit in setup t3401: modernize style t3040 (subprojects-basic): fix '&&' chaining, modernize style t1510 (worktree): fix '&&' chaining t3030 (merge-recursive): use test_expect_code test: fix '&&' chaining t3200 (branch): fix '&&' chaining
2011-12-08t3200 (branch): fix '&&' chainingLibravatar Ramkumar Ramachandra1-2/+2
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Fix these breaks. The 'git branch --help' in the test may fail if git manual pages are not installed, but the point of the test is to make sure it does not create a bogus branch "--help", so run it under 'test_might_fail'. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28branch: allow a no-op "branch -M <current-branch> HEAD"Libravatar Jonathan Nieder1-0/+16
Overwriting the current branch with a different commit is forbidden, as it will make the status recorded in the index and the working tree out of sync with respect to the HEAD. There however is no reason to forbid it if the current branch is renamed to itself, which admittedly is something only an insane user would do, but is handy for scripts. Test script is by Conrad Irwin. Reported-by: Soeren Sonnenburg <sonne@debian.org> Reported-by: Josh Chia (谢任中) Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-02t3200: add test case for 'branch -m'Libravatar Stefan Naewe1-0/+5
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>