Certain characters such as "?" can be present in a CVS tag name, but
git does not allow these characters in tags. If git-cvsimport
encounters a CVS tag that git cannot handle, cvsimport will error and
refuse to continue the import beyond that point.
When importing CVS tags, strip all the inappropriate strings from the
tag names as we translate them to git tag names.
Provide more debugging information to the user if we've altered the
tag and the "git tag" command still fails. Also, warn the user if we
end up skipping an (unusable) tag altogether.
Signed-off-by: Ken Dreyer <ktdreyer@ktdreyer.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generate po/git.pot from v1.7.12-146-g16d26, and there are 2 new,
4 removed l10n messages.
* 2 new messages are added at lines:
4151, 4172
* 4 old messages are deleted from the previous version at lines:
350, 354, 2069, 4166
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
In addition to updating the xstrdup(mkpath(...)) call sites with
mkpathdup(), we also fix a memory leak (in merge_3way()) caused by
neglecting to free the memory allocated to the 'base_name' variable.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In addition to updating the two xstrdup(git_path("...")) call sites
with git_pathdup(), we also fix a memory leak by freeing the memory
allocated to the ADD_EDIT.patch 'file' in the edit_patch() function.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current implementation of git_path() is essentially the same as
that of vsnpath(), with two minor differences. First, git_path()
currently insists that the git directory path is no longer than
PATH_MAX-100 characters in length. However, vsnpath() does not
attempt this arbitrary 100 character reservation for the remaining
path components. Second, vsnpath() uses the "is_dir_sep()" macro,
rather than comparing directly to '/', to determine if the git_dir
path component ends with a path separator.
In order to benefit from the above improvements, along with increased
compatability with git_snpath() and git_pathdup(), we reimplement the
git_path() function using vsnpath().
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git_snpath() and git_pathdup() functions both use the (static)
function vsnpath() in their implementation. Also, they both discard
the return value of vsnpath(), which has the effect of ignoring the
side effect of calling cleanup_path() in the non-error return path.
In order to ensure that the required cleanup happens, we use the
pointer returned by vsnpath(), rather than the buffer passed into
vsnpath(), to derive the return value from git_snpath() and
git_pathdup().
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, the git_vsnpath() function, despite the 'git_' prefix
suggesting otherwise, is (correctly) declared with file scope.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce get_max_fd_limit() to absorb platforms that do not have
getrlimit(RLIMIT_NOFILE) and/or sysconf(_SC_OPEN_MAX).
* js/use-sc-open-max:
sha1_file.c: introduce get_max_fd_limit() helper
Some mkdir(2) implementations do not want to see trailing slash in
its parameter.
* js/compat-mkdir:
compat: some mkdir() do not like a slash at the end
Done to support compilation on __TANDEM, but is independently useful
for people with older version of libcURL.
* js/no-curl-easy-strerror-on-old-curl:
http.c: don't use curl_easy_strerror prior to curl-7.12.0
"git submodule update --force" used to leave the working tree of the
submodule intact when there were local changes. It is more intiutive
to make "--force" a sign to run "checkout -f" to overwrite them.
* sz/submodule-force-update:
Make 'git submodule update --force' always check out submodules.
"git stash" internally used "git merge-recursive" backend, which did
not trigger "rerere" upon conflicts unlike other mergy operations.
* ph/stash-rerere:
stash: invoke rerere in case of conflict
test: git-stash conflict sets up rerere
Allow an external command to tell git-daemon to decline service
based on the client address, repository path, etc.
* jc/daemon-access-hook:
daemon: --access-hook option
Validate interactive input to "git send-email" to avoid common
mistakes such as saying "y<RETURN>" to sender mail address whose
prompt is given with a correctly guessed default.
* jc/send-email-reconfirm:
send-email: validate & reconfirm interactive responses
"git cherry-pick" by default stops when it sees a commit without any
log message. The "--allow-empty-message" option can be used to
silently proceed.
* cw/cherry-pick-allow-empty-message:
cherry-pick: add --allow-empty-message option
"git foo" errored out with "Not a directory" when the user had a non
directory on $PATH, and worse yet it masked an alias "foo" to run.
* jc/maint-sane-execvp-notdir:
sane_execvp(): ignore non-directory on $PATH
The exit status code from "git config" was way overspecified while
being incorrect. Update the implementation to give the documented
status for a case that was documented, and introduce a new code for
"all other errors".
* jc/maint-config-exit-status:
config: "git config baa" should exit with status 1
fetch_populated_submodules() allocates the full argv array it uses to
recurse into the submodules from the number of given options plus the six
argv values it is going to add. It then initializes it with those values
which won't change during the iteration and copies the given options into
it. Inside the loop the two argv values different for each submodule get
replaced with those currently valid.
However, this technique is brittle and error-prone (as the comment to
explain the magic number 6 indicates), so let's replace it with an
argv_array. Instead of replacing the argv values, push them to the
argv_array just before the run_command() call (including the option
separating them) and pop them from the argv_array right after that.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fetch invokes itself recursively when recursing into
submodules or handling "fetch --multiple". In both cases, it
builds the child's command line by pushing options onto a
statically-sized array. In both cases, the array is
currently just big enough to handle the largest possible
case. However, this technique is brittle and error-prone, so
let's replace it with a dynamic argv_array.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the array struct stores a "const char **" argv member
(for compatibility with most of our argv-taking functions),
we have to cast away the const-ness when freeing its
elements.
However, we used the wrong type when doing so. It doesn't
make a difference since free() take a void pointer anyway,
but it can be slightly confusing to a reader.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes we build a set of similar command lines, differing
only in the final arguments (e.g., "fetch --multiple"). To
use argv_array for this, you have to either push the same
set of elements repeatedly, or break the abstraction by
manually manipulating the array's internal members.
Instead, let's provide a sanctioned "pop" function to remove
elements from the end.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a test script issues a test_done without executing any tests, for
example when using the 'skip_all' facility, the output looks something
like this:
$ ./t9159-git-svn-no-parent-mergeinfo.sh
# passed all 0 test(s)
1..0 # SKIP skipping git svn tests, svn not found
$
The "passed all 0 test(s)" comment line, while correct, looks a little
strange. Add a check to suppress this message if no tests have actually
been run.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'skip_all' facility cannot be used after one or more tests
have been executed using (for example) 'test_expect_success'.
To do so results in invalid TAP output, which leads to 'prove'
complaining of "Parse errors: No plan found in TAP output".
Add a check for such invalid usage and abort the test with an
error message to alert the test author.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Each test in this file is skipped if the TABS_IN_FILENAMES test
prerequisite is set. Use the 'skip_all' facility at the head of
the file to skip all of the tests instead.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Each test in this file is skipped if the TABS_IN_FILENAMES test
prerequisite is set. Use the 'skip_all' facility at the head of
the file to skip all of the tests instead.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At present, running the t3300-*.sh test on cygwin looks like:
$ cd t
$ ./t3300-funny-names.sh
ok 1 - setup
# passed all 1 test(s)
1..1 # SKIP Your filesystem does not allow tabs in filenames
$
Unfortunately, this is not valid TAP output, which prove notes
as follows:
$ prove --exec sh t3300-funny-names.sh
t3300-funny-names.sh .. All 1 subtests passed
Test Summary Report
-------------------
t3300-funny-names.sh (Wstat: 0 Tests: 1 Failed: 0)
Parse errors: No plan found in TAP output
Files=1, Tests=1, 2 wallclock secs ( 0.05 usr 0.00 sys + \
0.90 cusr 0.49 csys = 1.43 CPU)
Result: FAIL
$
This is due to the 'trailing_plan' having a 'skip_directive'
attached to it. This is not allowed by the TAP grammar, which
only allows a 'leading_plan' to be followed by an optional
'skip_directive'. (see perldoc TAP::Parser::Grammar).
A trailing_plan is one that appears in the TAP output after one or
more test status lines (that start 'not '? 'ok ' ...), whereas a
leading_plan must appear before all test status lines (if any).
In practice, this means that the test script cannot contain a use
of the 'skip all' facility:
skip_all='Some reason to skip *all* tests in this file'
test_done
after having already executed one or more tests with (for example)
'test_expect_success'. Unfortunately, this is exactly what this
test script is doing. The first 'setup' test is actually used to
determine if the test prerequisite is satisfied by the filesystem
(ie does it allow tabs in filenames?).
In order to fix the parse errors, place the code to determine the
test prerequisite at the top level of the script, prior to the
first test, rather than as a parameter to test_expect_success.
This allows us to correctly use 'skip_all', thus:
$ ./t3300-funny-names.sh
# passed all 0 test(s)
1..0 # SKIP Your filesystem does not allow tabs in filenames
$
$ prove --exec sh t3300-funny-names.sh
t3300-funny-names.sh .. skipped: Your filesystem does not \
allow tabs in filenames
Files=1, Tests=0, 2 wallclock secs ( 0.02 usr 0.03 sys + \
0.84 cusr 0.41 csys = 1.29 CPU)
Result: NOTESTS
$
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits made by ancient version of Git allowed committer without
human readable name, like this (00213b17c in the kernel history):
tree 6947dba41f8b0e7fe7bccd41a4840d6de6a27079
parent 352dd1df32e672be4cff71132eb9c06a257872fe
author Petr Baudis <pasky@ucw.cz> 1135223044 +0100
committer <sam@mars.ravnborg.org> 1136151043 +0100
kconfig: Remove support for lxdialog --checklist
...
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
When fed such a commit, --format='%ci' fails to parse it, and gives
back an empty string. Update the split_ident_line() to be a bit
more lenient when parsing, but make sure the caller that wants to
pick up sane value from its return value does its own validation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is used by "git merge" and "git merge-base --independent" but
used to use a similar N*(N-1) traversals to reject commits that are
ancestors of other commits.
Reimplement it on top of remove_redundant(). Note that the callers
of this function are allowed to pass the same commit more than once,
but remove_redundant() is designed to be fed each commit only once.
The function removes duplicates before calling remove_redundant().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many scripted Porcelain commands, we find this idiom:
if test "$(git rev-parse --verify A)" = "$(git merge-base A B)"
then
... A is an ancestor of B ...
fi
But you do not have to compute exact merge-base only to see if A is
an ancestor of B. Give them a more direct way to use the underlying
machinery.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The get_merge_bases_many() function reduces the result returned by
the merge_bases_many() function, which is a set of possible merge
bases, by excluding commits that can be reached from other commits.
We used to do N*(N-1) traversals for this, but we can check if one
commit reaches which other (N-1) commits by a single traversal, and
repeat it for all the candidates to find the answer.
Introduce remove_redundant() helper function to do this painting; we
should be able to use it to reimplement reduce_heads() as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With paint_down_to_common(), we can tell if "commit" is reachable
from "reference" by simply looking at its object flag, instead of
iterating over the merge bases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a new helper function paint_down_to_common() that takes
the same parameters as merge_bases_many(), but without the first
optimization of not painting anything when "one" is one of the
"twos" (or vice versa), and the last clean-up of removing the common
ancestor that is known to be an ancestor of another common one.
This way, the caller of the new function could tell if "one" is
reachable from any of the "twos" by simply looking at the flag bits
of "one". If (and only if) it is painted in PARENT2, it is
reachable from one of the "twos".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for "cherry-pick" and in reverse chronological order for
"revert". This matches the order in which one would usually give them
on the command line, making this bug somewhat hard to notice. Still,
it has been reported at least once before [1].
It seems like the chronological sorting happened by accident because
the revision walker has traditionally always sorted commits in reverse
chronological order when rev_info.no_walk was enabled. In the case of
'git revert B A' where B is newer than A, this sorting is a no-op. For
'git cherry-pick A B', the sorting would reverse the arguments, but
because the sequencer also flips the rev_info.reverse flag when
picking (as opposed to reverting), the end result is a chronological
order. The rev_info.reverse flag was probably flipped so that the
revision walker emits B before C in 'git cherry-pick A..C'; that it
happened to effectively undo the unexpected sorting done when not
walking, was probably a coincidence that allowed this bug to happen at
all.
Fix the bug by telling the revision walker not to sort the commits
when not walking. The only case we want to reverse the order is now
when cherry-picking and walking revisions (rev_info.no_walk = 0).
[1] http://thread.gmane.org/gmane.comp.version-control.git/164794
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
currently work. Add a test case to demonstrate it.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
