* sp/run-command:
Use run_command within send-pack
Use run_command within receive-pack to invoke index-pack
Use run_command within merge-index
Use run_command for proxy connections
Use RUN_GIT_CMD to run push backends
Correct new compiler warnings in builtin-revert
Replace fork_with_pipe in bundle with run_command
Teach run-command to redirect stdout to /dev/null
Teach run-command about stdout redirection
In the Linux kernel, for example, it's common to include Cc: lines
for cases when you want to remember to cc someone on a patch without
necessarily claiming they signed off on it. Make git-send-email
aware of these.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was using "branch" to mean "head", but that's perhaps a little
sloppy; so instead start by using the terms "branch head" and "head",
while still quickly falling back on "branch", since that's what
people actually say more frequently.
Also include glossary references on the first uses of "head" and "tag".
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The sort_glossary.pl script sorts the glossary, checks for duplicates,
and automatically adds cross-references.
But it's not so hard to do all that by hand, and sometimes the automatic
cross-references are a little wrong; so let's run the script one last
time and check in its output.
Note: to make the output fit better into the user manual I also deleted
the acknowledgements at the end, which was maybe a little rude; feel
free to object and I can find a different solution.
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I'd like to start using references to the glossary in the user manual.
The "ref_" prefix for these references seems a little generic; so
replace with "def_".
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
"file patch" was doubtless intended to be "file path",
but "directory name" is clearer.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The --nonet option prevents xsltproc from going to the network to find
anything. But it always tries to find them locally first, so for a
user with the necessary docbook stylesheets installed the build will
work just fine without xsltproc attempting to use the network; all
--nonet does is make it fail rather than falling back on that. That
doesn't seem particularly helpful.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
* ar/diff:
Add tests for --quiet option of diff programs
try-to-simplify-commit: use diff-tree --quiet machinery.
revision.c: explain what tree_difference does
Teach --quiet to diff backends.
diff --quiet
Remove unused diffcore_std_no_resolve
Allow git-diff exit with codes similar to diff(1)
This is a micro-optimization that grew out of the mailing list discussion
about "strlen()" showing up in profiles.
We used to pass regular C strings around to the low-level tree walking
routines, and while this worked fine, it meant that we needed to call
strlen() on strings that the caller always actually knew the size of
anyway.
So pass the length of the string down wih the string, and avoid
unnecessary calls to strlen(). Also, when extracting a pathname from a
tree entry, use "tree_entry_len()" instead of strlen(), since the length
of the pathname is directly calculable from the decoded tree entry itself
without having to actually do another strlen().
This shaves off another ~5-10% from some loads that are very tree
intensive (notably doing commit filtering by a pathspec).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>"
Signed-off-by: Junio C Hamano <junkio@cox.net>
A malloc() + memcpy() will always be faster than mmap() +
malloc() + inflate(). If the data is already there it is
certainly better to copy it straight away.
With this patch below I can do 'git log drivers/scsi/ >
/dev/null' about 7% faster. I bet it might be even more on
those platforms with bad mmap() support.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This trivial 256-entry delta_base cache improves performance for some
loads by a factor of 2.5 or so.
Instead of always re-generating the delta bases (possibly over and over
and over again), just cache the last few ones. They often can get re-used.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't change any code, it just creates a point for where we'd
actually do the caching of delta bases that have been generated.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Especially with the new index format to come, it is more appropriate
to encapsulate more into check_packed_git_idx() and assume less of the
index format in struct packed_git.
To that effect, the index_base is renamed to index_data with void * type
so it is not used directly but other pointers initialized with it. This
allows for a couple pointer cast removal, as well as providing a better
generic name to grep for when adding support for new index versions or
formats.
And index_data is declared const too while at it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure pack-objects with --delta-base-offset works fine, and that
it actually produces smaller packs as expected.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'use packed deltified objects' test was flawed as it failed to
remove the pack and index from the previous test, effectively preventing
the desired pack from being exercised as objects could be found in that
other pack instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier patch 87ab7992 broke applymbox by blindly copying piece
from git-am, causing a harmless but annoying series of error messages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The message formating (commit v1.5.0.3-28-gbe242d5) broke the && chain.
Noticed by Dmitry Torokhov.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We generally prefer xstrdup to just plain strdup.
Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If your development history does not have fast-forward merges,
i.e. the "first parent" of commits in your history are special
than other parents, this option gives a better overview of the
evolution of a particular branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses diff-tree --quiet machinery to terminate the internal
diff-tree between a commit and its parents via revs.pruning (not
revs.diffopt) as soon as we find enough about the tree change.
With respect to the optionally given pathspec, we are interested
if the tree of commit is identical to the parent's, only adds
new paths to the parent's, or there are other differences. As
soon as we find out that there is one such other kind of
difference, we do not have to compare the rest of the tree.
Because we do not call standard diff_addremove/diff_change, we
instruct the diff-tree machinery to stop early by setting
has_changes when we say we found the trees to be different.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This explains how tree_difference variable is used, and updates two
places where the code knows symbolic constant REV_TREE_SAME is 0.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches git-diff-files, git-diff-index and git-diff-tree
backends to exit early under --quiet option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the command line option 'quiet' to tell 'git diff-*'
that we are not interested in the actual diff contents but only
want to know if there is any change. This option automatically
turns --exit-code on, and turns off output formatting, as it
does not make much sense to show the first hit we happened to
have found.
The --quiet option is silently turned off (but --exit-code is
still in effect, so is silent output) if postprocessing filters
such as pickaxe and diff-filter are used. For all practical
purposes I do not think of a reason to want to use these filters
and not viewing the diff output.
The backends have not been taught about the option with this patch.
That is a topic for later rounds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This introduces a new command-line option: --exit-code. The diff
programs will return 1 for differences, return 0 for equality, and
something else for errors.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previous formulation could make it appear as removing all lines
matching a regexp (at least, I was looking for such a flag, and
confused this flag for what I was looking for).
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The symbolic notation of the fork point can contain whitespaces (e.g.
"git checkout -m 'HEAD@{9 hours ago}'"). Quote strings properly
when using eval to prepare GITHEAD_$new
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously git-describe would output lines of the form
v1.1.1-gf509d56
The update hook found the dash and stripped it off using
sed 's/-g.*//'
The remainder was then used as the previous tag name.
However, git-describe has changed format. The output is now of the form
v1.1.1-23-gf509d56
The above sed fragment doesn't strip the middle "-23", and so the
previous tag name used would be "v1.1.1-23". This is incorrect.
Since the hook script was written, git-describe now gained support for
"--abbrev=0", which it uses as a special flag to tell it not to output
anything other than the nearest tag name. This patch fixes the problem,
and prevents any future recurrence by using this new flag rather than
sed to find the previous tag.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit: Also print the old revision similar to how cvs does it and
prepend a line stating the filename so that one can actually
understand what happened when commiting more than one file.
status: Fix the RCS filename displayed. The directory was
printed twice.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Submit some additional messages to the client on commit and update.
Inspired by the standard CVS server though a little more terse.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/fetch:
.gitignore: add git-fetch--tool
builtin-fetch--tool: fix reflog notes.
git-fetch: retire update-local-ref which is not used anymore.
builtin-fetch--tool: make sure not to overstep ls-remote-result buffer.
fetch--tool: fix uninitialized buffer when reading from stdin
builtin-fetch--tool: adjust to updated sha1_object_info().
git-fetch--tool takes flags before the subcommand.
Use stdin reflist passing in git-fetch.sh
Use stdin reflist passing in parse-remote
Allow fetch--tool to read from stdin
git-fetch: rewrite expand_ref_wildcard in C
git-fetch: rewrite another shell loop in C
git-fetch: move more code into C.
git-fetch--tool: start rewriting parts of git-fetch in C.
git-fetch: split fetch_main into fetch_dumb and fetch_native
If you use scanf or sscanf to parse integers, your code probably
accepts bogus inputs. For example, builtin-grep (aka git-grep) uses
sscanf(scan, "%u", &num) to parse the integer argument to -A, -B, -C.
Currently, "-C 1,000" and "-C 4294967297" are both treated just like
"-C 1":
$ git-grep -h -C 4294967297 juggle
out and you may find it easier to switch back and forth if you
juggle multiple lines of development simultaneously. Of
course, you will pay the price of more disk usage to hold
The obvious fix is to use strtoul instead. But using a bare strtoul is
too messy, at least when done properly, so I've added a wrapper function.
The new function in the patch below belongs elsewhere if it would be
useful in replacing any of the four remaining uses of sscanf.
One final note: With this change, I get a slightly different
diagnostic depending on the context size:
$ ./git-grep -h -C 4294967296 juggle
fatal: 4294967296: invalid context length argument
[Exit 128]
$ ./git-grep -h -C 4294967295 juggle
grep: 4294967295: invalid context length argument
[Exit 1]
A common convention that makes it easy to identify the source
of a diagnostic is to include the program name before the first ":".
Whether that should be "git" or "git-grep" is another question.
Using "grep" or "fatal" is misleading.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
