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
The --max-age=<timestamp> and --min-age=<timestamp> are now shown only
in the git-rev-list manpage (plumbing).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When passing "xyz" to make_absolute_path(), make_absolute_path()
erroneously tried to chdir("xyz"), and then append "/xyz". Instead,
skip the chdir() completely when no slash was found.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ping Yin noticed that "git diff-index --raw" shows 0{40} when work tree
has submodule difference, but "git diff --raw" didn't correctly do so.
There was a mistake in the diffcore_skip_stat_unmatch() that was meant to
clean up the stat-only difference for running diff between the index and
work tree and diff between the tree and the work tree, to cause it re-read
from the submodule repository HEAD. When ce_stat_match() says work tree
is different, we should always say 0{40} on the work tree side.
This patch fixes the issue, and adds tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The internal implementation of diff-index codepath used to use non const
pointer to pass sha1 around, but it did not have to. With this, we can
also lose the private no_sha1[] array, as we can use the public null_sha1[]
array that exists exactly for the same purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now find_unique_abbrev() never returns NULL, there is no need for callers
to prepare for seeing NULL and fall back to giving the full 40-hexdigits.
While we are at it, drop "..." in the "git reset" output that reports the
location of the new HEAD, between the abbreviated commit object name and
the one line commit summary. Because we are always showing the HEAD
(which cannot be missing!), we never had a case where we show the full 40
hexdigits that is not followed by three dots, and these three dots were
stealing 3 columns from the precious horizontal screen real estate out of
80 that can better be used for the one line commit summary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function returned NULL when no object that matches the name
was found, but that made the callers more complicated, as nobody
used that NULL return as an indication that no object with such
a name exists. They (at least the careful ones) instead took
the full 40-hexdigit and used in such a case, and the careless
ones segfaulted.
With this "git rev-parse --short 5555555555555555555555555555555555555555"
would stop segfaulting.
This is based on Jeff King's rewrite to my RFC patch, but "missing"
logic swapped to "exists". The final logic reads:
For existing objects, make sure the abbreviated string uniquely
identifies it. Otherwise, make sure the abbreviated string is
long enough so that it would not name any existing object.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
