There are times when gitk needs to know that the commits it has sent
to git-diff-tree --stdin did not match, and it needs to know in a
timely fashion even if none of them match. At the moment,
git-diff-tree outputs nothing for non-matching commits, so it is
impossible for gitk to distinguish between git-diff-tree being slow
and git-diff-tree saying no.
This makes git-diff-tree flush its output and echo back the
input line when it is not a valid-looking object name. Gitk, or
other users of git-diff-tree --stdin, can use a blank line or
any other "marker line" to indicate that git-diff-tree has
processed all the commits on its input up to the echoed back
marker line, and any commits that have not been output do not
match.
[jc: re-done after a couple of back-and-forth discussion on the list.]
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Moved the setup commands into test_expect_success blocks so their
output is hidden unless -v is used. This makes the test suite look
a little cleaner when the rm test-file setup step fails (and was
expected to fail for most cases).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/cache-tree: (26 commits)
builtin-rm: squelch compiler warnings.
git-write-tree writes garbage on sparc64
Fix crash when reading the empty tree
fsck-objects: do not segfault on missing tree in cache-tree
cache-tree: a bit more debugging support.
read-tree: invalidate cache-tree entry when a new index entry is added.
Fix test-dump-cache-tree in one-tree disappeared case.
fsck-objects: mark objects reachable from cache-tree
cache-tree: replace a sscanf() by two strtol() calls
cache-tree.c: typefix
test-dump-cache-tree: validate the cached data as well.
cache_tree_update: give an option to update cache-tree only.
read-tree: teach 1-way merege and plain read to prime cache-tree.
read-tree: teach 1 and 2 way merges about cache-tree.
update-index: when --unresolve, smudge the relevant cache-tree entries.
test-dump-cache-tree: report number of subtrees.
cache-tree: sort the subtree entries.
Teach fsck-objects about cache-tree.
index: make the index file format extensible.
cache-tree: protect against "git prune".
...
Conflicts:
Makefile, builtin.h, git.c: resolved the same way as in next.
Merge branch 'jc/dirwalk-n-cache-tree' into jc/cache-tree
* jc/dirwalk-n-cache-tree: (212 commits)
builtin-rm: squelch compiler warnings.
Add builtin "git rm" command
Move pathspec matching from builtin-add.c into dir.c
Prevent bogus paths from being added to the index.
builtin-add: fix unmatched pathspec warnings.
Remove old "git-add.sh" remnants
builtin-add: warn on unmatched pathspecs
Do "git add" as a builtin
Clean up git-ls-file directory walking library interface
libify git-ls-files directory traversal
Add a conversion tool to migrate remote information into the config
fetch, pull: ask config for remote information
Fix build procedure for builtin-init-db
read-tree -m -u: do not overwrite or remove untracked working tree files.
apply --cached: do not check newly added file in the working tree
Implement a --dry-run option to git-quiltimport
Implement git-quiltimport
Revert "builtin-grep: workaround for non GNU grep."
builtin-grep: workaround for non GNU grep.
builtin-grep: workaround for non GNU grep.
...
Doing an oprofile run on the result of my git rev-list memory leak fixes
and tree parsing cleanups, I was surprised by the third-highest entry
being
samples % image name app name symbol name
179751 2.7163 libc-2.4.so libc-2.4.so _IO_vfscanf@@GLIBC_2.4
where that 2.7% is actually more than 5% of one CPU, because this was run
on a dual CPU setup with the other CPU just being idle.
That seems to all be from the use of 'sscanf(tree, "%o", &mode)' for the
tree buffer parsing.
So do the trivial octal parsing by hand, which also gives us where the
first space in the string is (and thus where the pathname starts) so we
can get rid of the "strchr(tree, ' ')" call too.
This brings the "git rev-list --all --objects" time down from 63 seconds
to 55 seconds on the historical kernel archive for me, so it's quite
noticeable - tree parsing is a lot of what we end up doing when following
all the objects.
[ I also see a 5% speedup on a full "git fsck-objects" on the current
kernel archive, so that sscanf() really does seem to have hurt our
performance by a surprising amount ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
NetBSD ash chokes on the optional open parenthesis for case arms. Inside
$(command substitution), however, bash barfs without. So adjust things
accordingly.
* eb/mailinfo:
mailinfo: More carefully parse header lines in read_one_header_line()
Allow in body headers beyond the in body header prefix.
More accurately detect header lines in read_one_header_line
In handle_body only read a line if we don't already have one.
Refactor commit messge handling.
Move B and Q decoding into check header.
Make read_one_header_line return a flag not a length.
In the "next" branch, write_index_ext_header() writes garbage on a
64-bit big-endian machine; the written index file will be unreadable.
I noticed this on NetBSD/sparc64. Reproducible with:
$ git init-db
$ :>file
$ git-update-index --add file
$ git-write-tree
$ git-update-index
error: index uses extension, which we do not understand
fatal: index file corrupt
Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Langhoff points out that "git repack -a" ends up using up a lot of
memory for big archives, and that git cvsimport probably should do only
incremental repacks in order to avoid having repacking flush all the
caches.
The big majority of the memory usage of repacking is from git rev-list
tracking all objects, and this patch should go a long way in avoiding the
excessive memory usage: the bulk of it was due to the object names being
leaked from the tree parser.
For the historic Linux kernel archive, this simple patch does:
where we do end up wasting a bit of time on some extra strdup()s (which
could be avoided, but that would require tracking where the pathnames came
from), but we avoid a lot of memory usage.
Minor page faults track maximum RSS very closely (each page fault maps in
one page into memory), so the reduction from 125376 page faults to 43921
means a rough reduction of VM footprint from almost half a gigabyte to
about a third of that. Those numbers were also double-checked by looking
at "top" while the process was running.
(Side note: at least part of the remaining VM footprint is the mapping of
the 177MB pack-file, so the remaining memory use is at least partly "well
behaved" from a project caching perspective).
For the current git archive itself, the memory usage for a "--all
--objects" rev-list invocation dropped from 7128 pages to 2318 (27MB to
9MB), so the reduction seems to hold for much smaller projects too.
For regular "git-rev-list" usage (ie without the "--objects" flag) this
patch has no impact.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
I cannot find when that flag was removed if it ever existed, I can find
nothing about it in the ChangeLog and NEWS file of GNU diff. The current
flag is -s aka --quiet aka --silent, so let's use -s, assuming it is a
portable flag. Feel free to lart me with a POSIX bible if needed.
Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The revision argument parsing was happily parsing "--abbrev", but it
didn't parse "--abbrev=<n>".
Which was hidden by the fact that the diff options _would_ parse
--abbrev=<n>, so it would actually silently parse it, it just
wouldn't use it for the same things that a plain "--abbrev" was
used for.
Which seems a bit insane.
With this patch, if you do "git log --abbrev=10" it will abbreviate the
merge parent commit ID's to ten hex characters, which was probably what
you expected.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
mailinfo: More carefully parse header lines in read_one_header_line()
We exited prematurely from header parsing loop when the header
field did not have a space after the colon but we insisted on
it, and we got the check wrong because we forgot that we strip
the trailing whitespace before we do the check.
The space after the colon is not even required by RFC2822, so
stop requiring it. While we are at it, the header line is
specified to be more strict than "anything with a colon in it"
(there must be one or more characters before the colon, and they
must not be controls, SP or non US-ASCII), so implement that
check as well, lest we mistakenly think something like:
Since the "a..b c..d" syntax is interpreted as "b ^a d ^c" as other
range-ish commands, if you want to format a..b and then c..d and end
up with files consecutively numbered, the second run needs to be able
to tell the command what number to start from.
This does not imply --numbered (which gives [PATCH n/m] to the subject).
Otherwise, if make is suspended, or killed with prejudice, or if the
system crashes, you could be left with an up-to-date, yet corrupt,
generated file.
I left off the `clean' addition, because I believe "make clean" should
not remove wildcard patterns like "*+", on the off-chance that someone
uses names like that for files they care about. Besides, in practice,
those temporary files are left behind so rarely that they're not a bother,
and they're removed again as part of the next build.
I was just testing that "git ls-remote" change by Junio, and when you're
not in a git repository, it gives this totally bogus warning. The _target_
obviously has to be a git repository, but there's no reason why you'd have
to be in a local git repo when doing an ls-remote.
The reason is commit 73136b2e8a8ee024320c5ac6a0f14f912432bf03 by Dscho: it
adds calls to git-repo-config in git-parse-remote.sh to get the remote
shorthands etc.
Now, either we should just hide and ignore the error from git-repo-config
(probably bad, because some errors _are_ valid - like git-repo-config
failing due to bad syntax in the config file), or we should just make
git-repo-config quietly handle the case of not being in a git repository.
This does the latter: just quietly accepting (and doing nothing - trying
to set a value will result in the lock-file failing) our lot in life
sounds better than dying with a bogus error message.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Acked-By: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
As both DESTDIR and the prefix are supposed to be absolute pathnames
they can simply be concatenated without an extra / (like in the main Makefile).
The extra slash may even break installation on Windows.
[jc: adjusted an earlier workaround for this problem in the dist-doc
target in the main Makefile as well. ]
Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Avoid "use POSIX qw(strftime dup2 :errno_h)"; it was reported
that a Perl installations on Mandrake 9.1 did not like it, even
though it understood "use POSIX qw(:errno_h)". Funny.
* master: (40 commits)
Clean up sha1 file writing
Builtin git-cat-file
builtin format-patch: squelch content-type for 7-bit ASCII
CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.
add more informative error messages to git-mktag
remove the artificial restriction tagsize < 8kb
git-rebase: use canonical A..B syntax to format-patch
git-format-patch: now built-in.
fmt-patch: Support --attach
fmt-patch: understand old <his> notation
Teach fmt-patch about --keep-subject
Teach fmt-patch about --numbered
fmt-patch: implement -o <dir>
fmt-patch: output file names to stdout
Teach fmt-patch to write individual files.
Use RFC2822 dates from "git fmt-patch".
git-fmt-patch: thinkofix to show [PATCH] properly.
rename internal format-patch wip
Minor tweak on subject line in --pretty=email
Tentative built-in format-patch.
...
This cleans up and future-proofs the sha1 file writing in sha1_file.c.
In particular, instead of doing a simple "write()" call and just verifying
that it succeeds (or - as in one place - just assuming it does), it uses
"write_buffer()" to write data to the file descriptor while correctly
checking for partial writes, EINTR etc.
It also splits up write_sha1_to_fd() to be a lot more readable: if we need
to re-create the compressed object, we do so in a separate helper
function, making the logic a whole lot more modular and obvious.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When there is no leading context, the patch must match at the
beginning of preimage; otherwise there is a "patch adds these
lines while the other lines were added to the original file"
conflict.
This is the opposite of match_end fix earlier in this series.
Unlike matching at the end case, we can additionally check the
preimage line number recorded in the patch, so the change is not
symmetrical with the earlier one.
* js/fmt-patch:
git-rebase: use canonical A..B syntax to format-patch
git-format-patch: now built-in.
fmt-patch: Support --attach
fmt-patch: understand old <his> notation
Teach fmt-patch about --keep-subject
Teach fmt-patch about --numbered
fmt-patch: implement -o <dir>
fmt-patch: output file names to stdout
Teach fmt-patch to write individual files.
Use RFC2822 dates from "git fmt-patch".
git-fmt-patch: thinkofix to show [PATCH] properly.
rename internal format-patch wip
Minor tweak on subject line in --pretty=email
Tentative built-in format-patch.
* lt/dirwalk:
Add builtin "git rm" command
Move pathspec matching from builtin-add.c into dir.c
Prevent bogus paths from being added to the index.
builtin-add: fix unmatched pathspec warnings.
Remove old "git-add.sh" remnants
builtin-add: warn on unmatched pathspecs
Do "git add" as a builtin
Clean up git-ls-file directory walking library interface
libify git-ls-files directory traversal
--summary output should print immediately after stats.
Currently the summary is displayed after the patch. Fix this so
that the output order is stat-summary-patch. As a consequence of
the way this is coded, the --summary option will only actually
display summary data if combined with either the --stat or
--patch-with-stat option.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
Catalin noticed that we do not treat end-of-file condition shown
in the patch text as the patch context. This causes a patch
that appends at the end of the file to cleanly apply even if
something else has been appended to the file. If this happened
in the middle, we would refuse by saying that the file has
conflicting modifications.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Unlike my earlier test patch, this also checks svn:eol-style and
makes sure it's applied to working copy updates. This is
definitely more correct than my original attempt at killing
keyword expansions, but I still haven't tested it enough to
know. Feedback would be much appreciated.
Also changed assert_svn_wc_clean() to only work on the svn
working copy. This requires a separate call to assert_tree() to
check wc integrity against git in preparation for another change
I'm planning.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
In handle_body only read a line if we don't already have one.
This prepares for detecting non-email patches that don't have
mail headers. In which case we have already read the first
line so handle_body should not ignore it.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
- Move handle_info into main so it is called once
after everything has been parsed. This allows the removal
of a static variable and removes two duplicate calls.
- Move parsing of inbody headers into handle_commit.
This means we parse the in-body headers after we have decoded
the character set, and it removes code duplication between
handle_multipart_one_part and handle_body.
- Change the flag indicating that we have seen an in body
prefix header into another bit in seen.
This is a little more general and allows the possibility of parsing
in body headers after the body message has begun.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make read_one_header_line return a flag not a length.
Currently we only use the return value from read_one_header line
to tell if the line we have read is a header or not. So make
it a flag. This paves the way for better email detection.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This change attempts to clean up the commit function to make it a bit
easier to read (or at least the first half of it). It also improves
robustness and performance. Specifically:
- report get_headref errors on opening ref unless the error is ENOENT
- use regex to check for sha1 instead of length
- use lexically scoped filehandles which get cleaned up automagically
- check for error on both 'print' and 'close' (since output is buffered)
- avoid "fork, do some perl, then exec" in commit(). It's not necessary,
and we probably end up COW'ing parts of the perl process. Plus the code
is much smaller because we can use open2()
- avoid calling strftime over and over (mainly a readability cleanup)
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
This should reduce the number of git-update-index forks required per
commit. We now do adds/removes in one call, and we are no longer forced to
deal with argv limitations.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git status: skip empty directories, and add -u to show all untracked files
By default, we use --others --directory to show uninteresting
directories (to get user's attention) without their contents (to
unclutter output). Showing empty directories do not make sense,
so pass --no-empty-directory when we do so.
Giving -u (or --untracked) disables this uncluttering to let the
user get all untracked files.
Change GIT-VERSION-GEN to call git commands with "git" not "git-".
GIT-VERSION-GEN can incorrectly return a default version of
"v1.3.GIT" because it tries to execute git commands using the
"git-cmd" format that expects all git commands to be in the $PATH.
Convert these to "git cmd" format so that a proper answer is
returned even when the git commands have been moved out of the
$PATH and into a $gitexecdir.
fetch-pack: output refs in the order they were given on the command line.
Currently, fetched refs are output in the order the remote side
happened to send them. This changes the order to match the
order of refs that were given on the command line. To the
existing core callers (git-fetch and git-clone) this does not
make any difference, but for other Porcelain use, it would be
more intuitive.
builtin format-patch: squelch content-type for 7-bit ASCII
When --attach is not used, usually we do not say Content-Type:
and fluff, but if the commit message is not 7-bit ASCII, mark
it as "text/plain; charset=UTF-8". This unclutters output
somewhat.
CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.
By convention, the commit message and the author/committer names
in the commit objects are UTF-8 encoded. When formatting for
e-mails, Q-encode them according to RFC 2047.
While we are at it, generate the content-type and
content-transfer-encoding headers as well.
Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.
This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Its nice to have git-check-ref-format actually get mentioned in
git-branch's documentation as the syntax of a ref name must conform
to what is described in git-check-ref-format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch touches a couple of files, because it adds options to print a
custom text just after the subject of a commit, and just after the
diffstat.
[jc: made "many dashes" used as the boundary leader into a single
variable, to reduce the possibility of later tweaks to miscount the
number of dashes to break it.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>