We cannot tell a node that has been checked and found not to be
interesting (which does not have the TREECHANGE flag) from a
node that hasn't been checked if it is interesting or not,
without relying on something else, such as object->parsed.
But an object can get the "parsed" flag for other reasons.
Which means that "TREECHANGE" has the wrong polarity.
This changes the way how the path pruning logic marks an
uninteresting commits. From now on, we consider a commit
interesting by default, and explicitly mark the ones we decided
to prune. The flag is renamed to "TREESAME".
Then, this fixes the logic to show the early output with
incomplete pruning. It basically says "a commit that has
TREESAME set is kind-of-UNINTERESTING", but obviously in a
different way than an outright UNINTERESTING commit. Until we
parse and examine enough parents to determine if a commit
becomes surely "kind-of-UNINTERESTING", we avoid rewriting
the ancestry so that later rounds can fix things up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees. This is not so. Since we do
not traverse into submodules (yet), the gitlinks should be ignored.
In general, we should try to start moving away from using the
"S_ISLNK()" like things for internal git state. It was a mistake to
just assume the numbers all were same across all systems in the first
place. This implementation converts to the "object_type", and then
uses a case statement.
Noticed by Ilari on IRC.
Test script taken from an earlier version by Dscho.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-clean: honor core.excludesfile
Documentation: Fix man page breakage with DocBook XSL v1.72
git-remote.txt: fix typo
core-tutorial.txt: Fix argument mistake in an example.
replace reference to git-rm with git-reset in git-commit doc
Grammar fixes for gitattributes documentation
Don't allow fast-import tree delta chains to exceed maximum depth
revert/cherry-pick: allow starting from dirty work tree.
t/t3404: fix test for a bogus todo file.
Conflicts:
fast-import.c
A stale test-parse-options can break t0040 otherwise.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean did not honor core.excludesfile configuration
variable, although some other commands such as git-add and
git-status did. Fix this inconsistency.
Original report and patch from Shun'ichi Fuji. Rewritten by me
and bugs and tests are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
From version 1.72 it will replace all dots in roff requests with U+2302
("house" character), and add escaping in output for all instances of dot
that are not in roff requests. This caused the ".ft" hack forcing
monospace font in listingblocks to end up as "\&.ft" and being visible
in the resulting man page.
The fix adds a DOCBOOK_XSL_172 build variable that will disable the
hack. To allow this variable to be defined in config.mak it also moves
build variable handling below the inclusion of config.mak.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Solaris 9's vsnprintf implementation returns -1 if we pass it a
buffer of length 0. The only way to get it to give us the actual
length necessary for the formatted string is to grow the buffer
out to have at least 1 byte available in the strbuf and then ask
it to compute the length.
If the available space is 0 I'm growing it out by 64 to ensure
we will get an accurate length estimate from all implementations.
Some callers may need to grow the strbuf again but 64 should be a
reasonable enough initial growth.
We also no longer silently fail to append to the string when we are
faced with a broken vsnprintf implementation. On Solaris 9 this
silent failure caused me to no longer be able to execute "git clone"
as we tried to exec the empty string rather than "git-clone".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One of examples has wrong output given the arguments provided.
Fix arguments to match the output.
Fix a minor syntax mistake in another place.
Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The message in git-commit suggesting to use 'git rm --cached'
to unstage is just plain wrong. It really should mention 'git reset'.
Suggested by Jan Hudec.
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tweak the "filter" section of the gitattributes documentation to add
some
missing articles and improve some word choices without changing the
semantics of the section.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brian Downing noticed fast-import can produce tree depths of up
to 6,035 objects and even deeper. Long delta chains can create
very small packfiles but cause problems during repacking as git
needs to unpack each tree to count the reachable blobs.
What's happening here is the active branch cache isn't big enough.
We're swapping out the branch and thus recycling the tree information
(struct tree_content) back into the free pool. When we later reload
the tree we set the delta_depth to 0 but we kept the tree we just
reloaded as a delta base.
So if the tree we reloaded was already at the maximum depth we
wouldn't know it and make the new tree a delta. Multiply the
number of times the branch cache has to swap out the tree times
max_depth (10) and you get the maximum delta depth of a tree created
by fast-import. In Brian's case above the active branch cache had
to swap the branch out 603/604 times during this import to produce
a tree with a delta depth of 6035.
Acked-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I had to scratch my head for quite some time figuring out why we
cannot optimize out write_tree() we do when --no-commit option
is given, whose purpose seem to be only to check if the index is
unmerged, with a simple loop over the active_cache[].
So add a comment to describe why the write_tree() is there, and
resurrect the last scripted version as a reference material in
contrib/example directory with others.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no reason to forbid a dirty work tree when reverting or
cherry-picking a change, as long as the index is clean.
The scripted version used to allow it:
case "$no_commit" in
t)
# We do not intend to commit immediately. We just want to
# merge the differences in.
head=$(git-write-tree) ||
die "Your index file is unmerged."
;;
*)
head=$(git-rev-parse --verify HEAD) ||
die "You do not have a valid HEAD"
files=$(git-diff-index --cached --name-only $head) || exit
if [ "$files" ]; then
die "Dirty index: cannot $me (dirty: $files)"
fi
;;
esac
but C rewrite tightened the check, probably by mistake.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When converting git-quiltimport.sh to the new git-rev-part --parseopt
system, the handling of --patches was broken. We inadvertantly always
attempt to use '--patches' as the value.
This was introduced in the following commit:
commit e01fbf1a8f
Author: Pierre Habouzit <madcoder@debian.org>
Date: Sun Nov 4 11:31:01 2007 +0100
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit was/is broken in that it accepts paths together with -a or
--interactive, which it shouldn't. There tests check those usage errors.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apart from the error in the condition (&& should actually be ||), the
construct
#if !defined(A) || !A
leads to a syntax error in the C preprocessor if A is indeed not defined.
Tested-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was distracting to see this error message:
clean.requireForce set and -n or -f not given; refusing to clean
even though clean.requireForce was not set at all. This patch distinguishes
the cases and gives a different message depending on whether the
configuration variable is not set or set to true.
While we are here, we also divert the error messages to stderr.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --skip case was handled properly when rebasing without --merge,
but the --continue case was not.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SVN requires that paths be URI-escaped for HTTP(S) repositories.
file:// and svn:// repositories do not need these rules.
Additionally, accessing individual paths inside repositories
(check_path() and get_log() do NOT require escapes to function
and in fact it breaks things).
Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
for-each-ref: fix off by one read.
git-branch: remove mention of non-existent '-b' option
git-svn: prevent dcommitting if the index is dirty.
Fix memory leak in traverse_commit_list
This looks like a cut and paste error from the git-checkout
explanation of --no-track.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dcommit uses rebase to sync the history with what has just been pushed to
SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now
the user will get an error message if he attempts to dcommit with a dirty
index.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back in e3c6f240fd Junio taught
git-fetch to avoid copying objects when we are fetching from
a repository that is already registered as an alternate object
database. In such a case there is no reason to copy any objects
as we can already obtain them through the alternate.
However we need to ensure the objects are all reachable, so we
run `git rev-list --objects $theirs --not --all` to verify this.
If any object is missing or unreadable then we need to fetch/copy
the objects from the remote. When a missing object is detected
the git-rev-list process will exit with a non-zero exit status,
making this condition quite easy to detect.
Although git-fetch is currently a builtin (and so is rev-list)
we cannot invoke the traverse_objects() API at this point in the
transport code. The object walker within traverse_objects() calls
die() as soon as it finds an object it cannot read. If that happens
we want to resume the fetch process by calling do_fetch_pack().
To get around this we spawn git-rev-list into a background process
to prevent a die() from killing the foreground fetch process,
thus allowing the fetch process to resume into do_fetch_pack()
if copying is necessary.
We aren't interested in the output of rev-list (a list of SHA-1
object names that are reachable) or its errors (a "spurious" error
about an object not being found as we need to copy it) so we redirect
both stdout and stderr to /dev/null.
We run this git-rev-list based check before any fetch as we may
already have the necessary objects local from a prior fetch. If we
don't then its very likely the first $theirs object listed on the
command line won't exist locally and git-rev-list will die very
quickly, allowing us to start the network transfer. This test even
on remote URLs may save bandwidth if someone runs `git pull origin`,
sees a merge conflict, resets out, then redoes the same pull just
a short time later. If the remote hasn't changed between the two
pulls and the local repository hasn't had git-gc run in it then
there is probably no need to perform network transfer as all of
the objects are local.
Documentation for the new quickfetch function was suggested and
written by Junio, based on his original comment in git-fetch.sh.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some uses of git-rev-list are to run it with --objects to see if
a range of objects between two or more commits is fully connected
or not. In such a case the caller doesn't care about the actual
object names or hash hints so formatting this data only for it to
be dumped to /dev/null by a redirect is a waste of CPU time. If
all the caller needs is the exit status then --quiet can be used
to bypass the commit and object formatting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some callers may wish to redirect stderr to /dev/null in some
contexts, such as if they are executing a command only to get
the exit status and don't want users to see whatever output it
may produce as a side-effect of computing that exit status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previously git-fetch.sh used `git cat-file -t` to determine if an
object referenced by a tag exists, and if so fetch that tag locally.
This was subtly broken during the port to C based builtin-fetch as
lookup_object() only works to locate an object if it was previously
accessed by the transport. Not all transports will access all
objects in this way, so tags were not always being fetched.
The rsync transport never loads objects into the internal object
table so automated tag following didn't work if rsync was used.
Automated tag following also didn't work on the native transport
if the new tag was behind the common point(s) negotiated between
the two ends of the connection as the tag's referrant would not
be loaded into the internal object table. Further the automated
tag following was broken with the HTTP commit walker if the new
tag's referrant was behind an existing ref, as the walker would
stop before loading the tag's referrant into the object table.
Switching to has_sha1_file() restores the original behavior from
the shell script by checking if the object exists in the ODB,
without relying on the state left behind by a transport.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
reverse_diff was a bit-value in disguise, it's merged in the flags now.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
options flags:
~~~~~~~~~~~~~
PARSE_OPT_NONEG allow the caller to disallow the negated option to exists.
option types:
~~~~~~~~~~~~
OPTION_BIT: ORs (or NANDs) a mask.
OPTION_SET_INT: force the value to be set to this integer.
OPTION_SET_PTR: force the value to be set to this pointer.
helper:
~~~~~~
HAS_MULTI_BITS (in git-compat-util.h) is a bit-hack to check if an
unsigned integer has more than one bit set, useful to check if conflicting
options have been used.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git wrapper executable always prepends the GIT_EXEC_PATH build
variable to the current PATH, so prepending "." to the PATH is not
enough to give precedence to the fake vi executable.
The --exec-path option allows to prepend a directory to PATH even before
GIT_EXEC_PATH (which is added anyway), so we can use that instead.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
fix index-pack with packs >4GB containing deltas on 32-bit machines
git-hash-object should honor config variables
gitweb: correct month in date display for atom feeds
A --verbose option to push should also be passed to the
transport layer, i.e. git-send-pack, git-http-push.
git push is modified to do so.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
