Commit Graph

83 Commits

Author SHA1 Message Date
Johan Herland
81f339dc3d t3200: Minor fix when preparing for tracking failure
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-09 11:02:52 -07:00
Johan Herland
41c21f22d0 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 15:14:42 -07:00
Johan Herland
9c9cd39a0c t3200.39: tracking setup should fail if there is no matching refspec.
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-21 15:14:41 -07:00
Junio C Hamano
88dccb6c98 Merge branch 'jk/set-upstream-error-cases'
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-07 14:31:08 -07:00
Junio C Hamano
8054b9a615 Merge branch 'jm/branch-rename-nothing-error'
"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-03 09:34:40 -07:00
Jeff King
8a3e5ecdaa t3200: test --set-upstream-to with bogus refs
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-02 16:14:06 -07:00
Junio C Hamano
0cb24fe86e Merge branch 'rr/test-3200-style'
Churns.

* rr/test-3200-style:
  t3200 (branch): modernize style
2013-04-01 08:59:14 -07:00
Jonathon Mah
d1520c4b1a branch: give better message when no names specified for rename
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31 19:58:02 -07:00
Ramkumar Ramachandra
0d158ebb92 t3200 (branch): modernize style
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-03-20 13:42:49 -07:00
Nguyễn Thái Ngọc Duy
8efb8899cf branch: segfault fixes and validation
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-02-23 11:53:21 -08:00
Nguyễn Thái Ngọc Duy
43722c4d9e branch: give a more helpful message on redundant arguments
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30 09:00:41 -08:00
René Scharfe
13baa9fe86 branch: show targets of deleted symrefs, not sha1s
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-18 14:36:17 -07:00
René Scharfe
0fe700e311 branch: skip commit checks when deleting symref branches
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-18 14:36:17 -07:00
René Scharfe
566c7707db branch: delete symref branch, not its target
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-10-18 14:36:16 -07:00
Junio C Hamano
83ce176449 Merge branch 'cn/branch-set-upstream-to'
"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-09-10 15:43:07 -07:00
Carlos Martín Nieto
b347d06bf0 branch: deprecate --set-upstream and show help if we detect possible 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-30 12:07:39 -07:00
Carlos Martín Nieto
b84869ef14 branch: add --unset-upstream option
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-30 12:07:28 -07:00
Jiang Xin
9a0013819e Fix tests under GETTEXT_POISON on parseopt
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-27 09:26:30 -07:00
Carlos Martín Nieto
6183d826ba branch: introduce --set-upstream-to
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-08-23 14:18:02 -07:00
Junio C Hamano
f4ed0af6e2 Merge branch 'nd/columns'
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-05-03 15:13:31 -07:00
Nguyễn Thái Ngọc Duy
ebe31ef2ed branch: add --column
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:38 -07:00
Junio C Hamano
7d47367a47 Merge branch 'cn/maint-branch-with-bad'
* cn/maint-branch-with-bad:
  branch: don't assume the merge filter ref exists

Conflicts:
	t/t3200-branch.sh
2012-03-01 14:44:17 -08:00
Carlos Martín Nieto
6c41e97557 branch: don't assume the merge filter ref exists
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-27 11:35:33 -08:00
Junio C Hamano
c2d17ba3db branch --edit-description: protect against mistyped branch name
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>
2012-02-05 17:28:03 -08:00
Junio C Hamano
9293aac2b1 Merge branch 'rr/test-chaining'
* 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-19 16:05:25 -08:00
Ramkumar Ramachandra
2f139044f9 t3200 (branch): fix '&&' chaining
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-12-08 16:01:47 -08:00
Jonathan Nieder
3f59481e33 branch: allow a no-op "branch -M <current-branch> HEAD"
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-28 11:40:46 -08:00
Stefan Naewe
db85b3a74f t3200: add test case for 'branch -m'
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-02 12:36:56 -07:00
Junio C Hamano
1077bf1ff6 Merge branch 'mg/branch-list'
* mg/branch-list:
  t3200: clean up checks for file existence
  branch: -v does not automatically imply --list
  branch: allow pattern arguments
  branch: introduce --list option
  git-branch: introduce missing long forms for the options
  git-tag: introduce long forms for the options
  t6040: test branch -vv

Conflicts:
	Documentation/git-tag.txt
	t/t3200-branch.sh
2011-10-05 12:36:23 -07:00
Junio C Hamano
fa79937675 branch --set-upstream: regression fix
The "git branch" command, while not in listing mode, calls create_branch()
even when the target branch already exists, and it does so even when it is
not interested in updating the value of the branch (i.e. the name of the
commit object that sits at the tip of the existing branch). This happens
when the command is run with "--set-upstream" option.

The earlier safety-measure to prevent "git branch -f $branch $commit" from
updating the currently checked out branch did not take it into account,
and we no longer can update the tracking information of the current branch.

Minimally fix this regression by telling the validation code if it is
called to really update the value of a potentially existing branch, or if
the caller merely is interested in updating auxiliary aspects of a branch.

Reported-and-Tested-by: Jay Soffian
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-16 21:47:47 -07:00
Jeff King
376eb14a05 t3200: clean up checks for file existence
This patch uses test_path_is_file and test_path_is_missing
instead of "test -f / ! test -f" checks. The former are more
verbose in case of failure and more precise (e.g., is_missing
will check that the entry is actually missing, not just not
a regular file).

As a bonus, this also fixes a few buggy tests that used
"test foo" instead of "test -f foo", and consequently always
reported success.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-13 10:11:39 -07:00
Michael J Gruber
cddd127b9a branch: introduce --list option
Currently, there is no way to invoke the list mode explicitly, without
giving -v to force verbose output.

Introduce a --list option which invokes the list mode. This will be
beneficial for invoking list mode with pattern matching, which otherwise
would be interpreted as branch creation.

Along with --list, test also combinations of existing options.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28 22:56:05 -07:00
Conrad Irwin
55c4a67307 Prevent force-updating of the current branch
"git branch -M <foo> <current-branch>" allows updating the current branch
which HEAD points, without the necessary house-keeping that git reset
normally does to make this operation sensible. It also leaves the reflog
in a confusing state (you would be warned when trying to read it).

"git checkout -B <current branch> <foo>" is also partly vulnerable to this
bug; due to inconsistent pre-flight checks it would perform half of its
task and then abort just before rewriting the branch. Again this
manifested itself as the index file getting out-of-sync with HEAD.

"git branch -f" already guarded against this problem, and aborts with
a fatal error.

Update "git branch -M", "git checkout -B" and "git branch -f" to share the
same check before allowing a branch to be created. These prevent you from
updating the current branch.

We considered suggesting the use of "git reset" in the failure message
but concluded that it was not possible to discern what the user was
actually trying to do.

Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22 16:00:36 -07:00
Junio C Hamano
22dbeee715 Merge branch 'jc/fix-diff-files-unmerged'
* jc/fix-diff-files-unmerged:
  diff-files: show unmerged entries correctly
  diff: remove often unused parameters from diff_unmerge()
  diff.c: return filepair from diff_unmerge()
  test: use $_z40 from test-lib
2011-05-06 10:52:58 -07:00
Junio C Hamano
3749fde561 test: use $_z40 from test-lib
There is no need to duplicate the definition of $_z40 and $_x40 that
test-lib.sh supplies the test scripts.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-23 22:34:43 -07:00
Junio C Hamano
f2c8c8007c i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 15:52:47 -07:00
Junio C Hamano
6c80cd298a Merge branch 'ab/i18n-st'
* ab/i18n-st: (69 commits)
  i18n: git-shortlog basic messages
  i18n: git-revert split up "could not revert/apply" message
  i18n: git-revert literal "me" messages
  i18n: git-revert "Your local changes" message
  i18n: git-revert basic messages
  i18n: git-notes GIT_NOTES_REWRITE_MODE error message
  i18n: git-notes basic commands
  i18n: git-gc "Auto packing the repository" message
  i18n: git-gc basic messages
  i18n: git-describe basic messages
  i18n: git-clean clean.requireForce messages
  i18n: git-clean basic messages
  i18n: git-bundle basic messages
  i18n: git-archive basic messages
  i18n: git-status "renamed: " message
  i18n: git-status "Initial commit" message
  i18n: git-status "Changes to be committed" message
  i18n: git-status shortstatus messages
  i18n: git-status "nothing to commit" messages
  i18n: git-status basic messages
  ...

Conflicts:
	builtin/branch.c
	builtin/checkout.c
	builtin/clone.c
	builtin/commit.c
	builtin/grep.c
	builtin/merge.c
	builtin/push.c
	builtin/revert.c
	t/t3507-cherry-pick-conflict.sh
	t/t7607-merge-overwrite.sh
2011-04-01 17:55:55 -07:00
Junio C Hamano
663ee1a4c9 Merge branch 'jh/maint-do-not-track-non-branches'
* jh/maint-do-not-track-non-branches:
  branch/checkout --track: Ensure that upstream branch is indeed a branch
2011-03-15 14:22:13 -07:00
Ævar Arnfjörð Bjarmason
8af42b0f77 i18n: git-branch "Deleted branch [...]" message
Gettextize the "Deleted %sbranch %s (was %s).\n" messages. test in
t3200-branch.sh explicitly checked for this message. Change it to skip
under GETTEXT_POISON=YesPlease.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 23:52:53 -08:00
Johan Herland
21b5b1e8dc branch/checkout --track: Ensure that upstream branch is indeed a branch
When creating a new branch using the --track option, we must make sure that
we don't try to set an upstream that does not make sense to follow (using
'git pull') or update (using 'git push'). The current code checks against
using HEAD as upstream (since tracking a symref doesn't make sense). However,
tracking a tag doesn't make sense either. Indeed, tracking _any_ ref that is
not a (local or remote) branch doesn't make sense, and should be disallowed.

This patch achieves this by checking that the ref we're trying to --track
resides within refs/heads/* or refs/remotes/*. This new check replaces the
previous check against HEAD.

A couple of testcases are also added, verifying that we cannot create
branches with tags as upstreams.

Finally, some selftests relying on using a non-branch as an upstream have
been reworked or removed:

- t6040: Reverse the meaning of two tests that depend on the ability to
use (lightweight and annotated) tags as upstreams. These two tests were
originally added in commits 1be570f and 57ffc5f, and this patch reverts the
intention of those two commits.

- t7201: Remove part of a test (introduced in 9188ed8) relying on a
non-branch as upstream.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16 16:55:56 -08:00
Nguyễn Thái Ngọc Duy
1dacfbcf13 branch -h: show usage even in an invalid repository
There is no need for "git branch -h" to try to access a repository.

In the spirit of v1.6.6-rc0~34^2~3 (Let 'git <command> -h' show usage
without a git dir, 2009-11-09).  This brings git one step closer to
passing the following (automatically verifiable) test:

 Before any repository access (aside from git_config()), a
 function from the setup_git_directory_* family has been run

and thus one step closer to being able to use an automatic repository
access checker.

[jn: simplified; new commit message, test]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-22 11:02:59 -07:00
Junio C Hamano
6e6842e36f tests: correct "does reflog exist?" tests
These two tests weren't about how "git reflog show <branch>" exits when
there is no reflog, but were about "checkout" and "branch" create or not
create reflog when creating a new <branch>.  Update the tests to check
what we are interested in, using "git rev-parse --verify".

Also lose tests based on "test -f .git/logs/refs/heads/<branch>" from
nearby, to avoid exposing this particular implementation detail
unnecessarily.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-21 12:54:48 -07:00
Brandon Casey
b1edaf669d t/: work around one-shot variable assignment with test_must_fail
See e200783255

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-21 11:54:34 -07:00
Junio C Hamano
8d676d85f7 Merge branch 'gv/portable'
* gv/portable:
  test-lib: use DIFF definition from GIT-BUILD-OPTIONS
  build: propagate $DIFF to scripts
  Makefile: Tru64 portability fix
  Makefile: HP-UX 10.20 portability fixes
  Makefile: HPUX11 portability fixes
  Makefile: SunOS 5.6 portability fix
  inline declaration does not work on AIX
  Allow disabling "inline"
  Some platforms lack socklen_t type
  Make NO_{INET_NTOP,INET_PTON} configured independently
  Makefile: some platforms do not have hstrerror anywhere
  git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition
  test_cmp: do not use "diff -u" on platforms that lack one
  fixup: do not unconditionally disable "diff -u"
  tests: use "test_cmp", not "diff", when verifying the result
  Do not use "diff" found on PATH while building and installing
  enums: omit trailing comma for portability
  Makefile: -lpthread may still be necessary when libc has only pthread stubs
  Rewrite dynamic structure initializations to runtime assignment
  Makefile: pass CPPFLAGS through to fllow customization

Conflicts:
	Makefile
	wt-status.h
2010-06-21 06:02:44 -07:00
Erick Mattos
b209995775 t3200: test -l with core.logAllRefUpdates options
By default reflogs are always created for new local branches by
"checkout -b".  But by setting core.logAllRefUpdates to false this will
not be true anymore.

In that case you only create the reflogs when you use -l switch with
"checkout -b".

Added missing tests to check expected behaviors.

Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-03 14:46:19 -07:00
Gary V. Vaughan
4fdf71be1c tests: use "test_cmp", not "diff", when verifying the result
In tests, call test_cmp rather than raw diff where possible (i.e. if
the output does not go to a pipe), to allow the use of, say, 'cmp'
when the default 'diff -u' is not compatible with a vendor diff.

When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS.

Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31 16:59:27 -07:00
Junio C Hamano
99c419c915 branch -d: base the "already-merged" safety on the branch it merges with
When a branch is marked to merge with another ref (e.g. local 'next' that
merges from and pushes back to origin's 'next', with 'branch.next.merge'
set to 'refs/heads/next'), it makes little sense to base the "branch -d"
safety, whose purpose is not to lose commits that are not merged to other
branches, on the current branch.  It is much more sensible to check if it
is merged with the other branch it merges with.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-30 01:24:56 -08:00
Junio C Hamano
23fd723c9d Merge branch 'bc/maint-1.6.1-branch-deleted-was'
* bc/maint-1.6.1-branch-deleted-was:
  git-branch: display "was sha1" on branch deletion rather than just "sha1"

Conflicts:
	builtin-branch.c
2009-03-26 00:26:47 -07:00
Johannes Sixt
704a3143d5 Use prerequisite tags to skip tests that depend on symbolic links
Many tests depend on that symbolic links work.  This introduces a check
that sets the prerequisite tag SYMLINKS if the file system supports
symbolic links.  Since so many tests have to check for this prerequisite,
we do the check in test-lib.sh, so that we don't need to repeat the test
in many scripts.

To check for 'ln -s' failures, you can use a FAT partition on Linux:

$ mkdosfs -C git-on-fat 1000000
$ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt

Clone git to /mnt and

$ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7
          t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \
        make test

(These additionally skipped tests depend on POSIX permissions that FAT on
Linux does not provide.)

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-22 17:26:44 +01:00
Brandon Casey
76aac71546 git-branch: display "was sha1" on branch deletion rather than just "sha1"
Make it more pleasant to read about a branch deletion by adding "was".
Jeff King suggested this, and I ignored it.  He was right.

Update t3200 test again to match the change in output.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-21 17:30:51 -07:00