Move quote_path() from wt-status.c to quote.c and rename it as
quote_path_relative(), because it is a better name for a public function.
Also, instead of handcrafted quoting, quote_c_style_counted() is now used,
to make its quoting more consistent with the rest of the system, also
honoring core.quotepath specified in configuration.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When get_pathspec() was originally made absolute-path capable,
we botched the interface to it, without dying inside the function
when given a path that is outside the work tree, and made it the
responsibility of callers to check the condition in a roundabout
way. This is made unnecessary with the previous patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When get_pathspec() was originally made absolute-path capable,
we botched the interface to it, without dying inside the function
when given a path that is outside the work tree, and made it the
responsibility of callers to check the condition in a roundabout
way. This is made unnecessary with the previous patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When get_pathspec() was originally made absolute-path capable,
we botched the interface to it, without dying inside the function
when given a path that is outside the work tree, and made it the
responsibility of callers to check the condition in a roundabout
way. This is made unnecessary with the previous patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit d089ebaa (setup: sanitize absolute and funny paths) made
get_pathspec() aware of absolute paths, but with a botched interface that
forced the callers to count the resulting pathspecs in order to detect
an error of giving a path that is outside the work tree.
This fixes it, by dying inside the function.
We had ls-tree test that relied on a misfeature in the original
implementation of its pathspec handling. Leading slashes were silently
removed from them. However we allow giving absolute pathnames (people
want to cut and paste from elsewhere) that are inside work tree these
days, so a pathspec that begin with slash _should_ be treated as a full
path. The test is adjusted to match the updated rule for get_pathspec().
Earlier I mistook three tests given by Robin that they should succeed, but
these are attempts to add path outside work tree, which should fail
loudly. These tests also have been fixed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
But still all branches are listed, if -r is present
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ba002f3 (builtin-fsck: move common object checking code to fsck.c) did
more than what it claimed to. Most notably, it wrongly made an empty tree
object an error by pretending to only move code from fsck_tree() in
builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check
to barf on an empty tree.
An empty tree object is _unusual_. Recent porcelains try reasonably hard
not to let the user create a commit that contains such a tree. Perhaps
warning about them in git-fsck may have some merit.
HOWEVER.
Being unusual and being errorneous are two quite different things. This
is especially true now we seem to use the same fsck_$object() code in
places other than git-fsck itself. For example, receive-pack should not
reject unusual objects, even if it would be a good idea to tighten it to
reject incorrect ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Fix 'git remote show' regression on empty repository in 1.5.4
Fix incorrect wording in git-merge.txt.
git-merge.sh: better handling of combined --squash,--no-ff,--no-commit options
Fix random crashes in http_cleanup()
Back in 18f7c51c we switched git-ls-remote/git-peek-remote to
use the transport backend, rather than do everything itself.
As part of that switch we started to produce a non-zero exit
status if no refs were received from the remote peer, which
happens when the remote peer has no commits pushed to it yet.
(E.g. "git --git-dir=foo.git init; git ls-remote foo.git")
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Removing .dotest should actually not be needed, so just test the directory
don't exist after --abort, but exists after starting the rebase.
Also, execute the same tests with rebase --merge, which uses a different code
path.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 3a70cdfa42 made readP4Files abort quickly
when the changeset only contains files that are marked for deletion with an empty return
value, which caused the commit to not do anything.
This commit changes readP4Files to distinguish between files that need to be passed to p4
print and files that have no content ("deleted") and merge them in the returned
list.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Keep the file open to: the OS does not allow removal of open files.
The saner systems just have a saner permission model and chmod 0
is enough for the test.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Existing test checked --long only for exactly tagged commit. We should
make sure it works sensibly for commits that are not tagged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back in 212945d4 ("Teach git-describe to verify annotated tag names
before output") I taught git-describe to output the name shown in the
"tag" header of an annotated tag, rather than the name it is actually
stored under in this repository's ref namespace.
This test case verifies this is working correctly by renaming the ref
for an annotated tag to a different name that what is recorded in the
tag body, and verifying that tag is returned. We also verify there is
a message shown on stderr to inform the user that the tag is possibly
stored under the wrong name locally.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In c374b91c ("git-describe: use tags found in packed-refs correctly")
Junio fixed an issue where git-describe did not parse a tag object it
obtained from a packed-refs file, as the peel information was read in
from packed-refs and not the tag object itself.
This new test case verifies the fix listed above is functioning, and
does not have a regression in the future.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git-describe fails we never execute the test_expect_success,
so we never actually test for failure. This is horribly wrong.
We need to always run the test case, but the test case is only
supposed to succeed if the prior git-describe returned 0.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is implausible for lookup_tag() to return NULL in this particular
codepath but we should protect ourselves against a broken repository
better.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A merge is not necessarily with a remote branch, it can be with any
commit.
Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having
git merge --no-commit --no-ff <branch>
actually commit the merge. Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options. However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that
git merge --squash --no-ff <branch>
fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge. The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.
The unexpected behavior was reported by John Goerzen through
http://bing.sdebian.org/468568
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When your refs are packed, "git-describe" can find the tag that is the
best match without ever parsing the tag itself. But lookup_tag() in
display_name() says "I've never seen it", creates an empty shell, and
returns it. We need to make sure that we actually have parsed the tag
data into it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes for 1.5.4.4
revert: actually check for a dirty index
tests: introduce test_must_fail
git-submodule: Fix typo 'url' which should be '$url'
receive-pack: Initialize PATH to include exec-dir.
Conflicts:
builtin-revert.c
The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.
The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.
Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
! git command
'
but a non-zero exit could come from the "git command" segfaulting.
A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail"). The above example should be written as:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
test_must_fail git command
'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix typo in 'test -z "url"' when checking whether a submodule url is
empty. "url" should be "$url".
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
511707d (use only the $PATH for exec'ing git commands) made it a
requirement to call setup_path() to include the git exec-dir in PATH
before spawning any other git commands. git-receive-pack was not yet
adapted to do this and therefore fails to spawn git-unpack-objects if that
is not in the standard PATH.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git fast-import expects to be run from an existing (possibly
empty) repository. It was dying with a suboptimal message if that
wasn't the case.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
* np/verify-pack:
add storage size output to 'git verify-pack -v'
fix unimplemented packed_object_info_detail() features
make verify_one_pack() a bit less wrong wrt packed_git structure
factorize revindex code out of builtin-pack-objects.c
Conflicts:
Makefile
Earlier, overly-long onelines would not be wrapped at all, and indented
with 6 spaces.
Instead, we now wrap around at 72 characters, with a first-line indent
of 2 spaces, and the rest with 4 spaces.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, when you called "git format-patch --cover-letter -M", the
diffstat in the cover letter would not inherit the "-M". Now it does.
While at it, add a few "|| break" statements in the test's loops;
otherwise, breakages inside the loops would not be caught.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to greediness of a pattern, gitweb used to mark (show) last match
in line, if there are more than one match in line. Now it shows first.
Showing all matches in a line would require further work.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pb/cvsimport:
cvsimport: document that -M can be used multiple times
cvsimport: allow for multiple -M options
cvsimport: have default merge regex allow for dashes in the branch name
* mk/maint-parse-careful:
receive-pack: use strict mode for unpacking objects
index-pack: introduce checking mode
unpack-objects: prevent writing of inconsistent objects
unpack-object: cache for non written objects
add common fsck error printing function
builtin-fsck: move common object checking code to fsck.c
builtin-fsck: reports missing parent commits
Remove unused object-ref code
builtin-fsck: move away from object-refs to fsck_walk
add generic, type aware object chain walker
Conflicts:
Makefile
builtin-fsck.c
Dmitry Potapov
Junio C Hamano
SZEDER Gábor
Shawn O. Pearce
Mike Hommey
Simon Hausmann
Alex Riesen
Matthieu Moy
Gerrit Pape
Martin Koegler
Jeff King
Ping Yin
Björn Steinbrink
Ralf Wildenhues
Jean-Luc Herren
Johannes Schindelin
Jakub Narebski