Grep may want to grok multiple revisions, but it does not make
much sense to walk revisions while doing so. This stops calling
the code to parse parameters for the revision walker. The
parameter parsing for the optional "-e" option becomes a lot
simpler with it as well.
Still Work-in-progress git fmt-patch (should it be known as
format-patch-ng?) is matched with the fix made by Huw Davies
in 262a6ef76a1dde97ab50d79fa5cd6d3f9f125765 commit to use
RFC2822 date format.
This attempts to set up built-in "git grep" to further reduce
our dependence on the shell, while at the same time optionally
allowing to run grep against object database. You could do
funky things like these:
git grep --cached -e pattern ;# grep from index
git grep -e pattern master ;# or in a rev
git grep -e pattern master next ;# or in multiple revs
git grep -e pattern pu^@ ;# even like this with an
;# extension from another topic ;-)
git grep -e pattern master..next ;# or even from rev ranges
git grep -e pattern master~20:Documentation
;# or an arbitrary tree
git grep -e pattern next:git-commit.sh
;# or an arbitrary blob
Right now, it does not understand and/or obey many options grep
should accept, and the pattern must be given with -e option due
to the way the parameter parser is structured, both of which
obviously need to be fixed for usability.
But this is going in the right direction. The shell script
version is one of the worst Portability offender in the git
barebone Porcelainish; it uses xargs -0 to pass paths around and
shell arrays to sift flags and parameters.
get_sha1(): :path and :[0-3]:path to extract from index.
Earlier patch to say <ent>:<path> by Linus was very useful, and
this extends the same idea to the current index. An sha1
expression :<path> extracts the object name for the named path
from the current index.
Extended SHA1 -- "rev^@" syntax to mean "all parents"
A short-hand "rev^@" is understood to be "all parents of the
named commit" with this patch. So you can do
git show v1.0.0^@
to view the parents of a merge commit,
gitk ^v1.0.0^@ v1.0.4
to view the log between two revs (including the bottom one), and
git diff --cc v1.1.0 v1.0.0^@
to inspect what got changed from the merge parents of v1.0.0 to v1.1.0.
This might be just my shiny new toy that is not very useful in
practice. I needed it to do the multi-tree diff on Len's
infamous 12-way Octopus; typing "diff --cc funmerge funmerge^1
funmerge^2 funmerge^3 ..." was too painful.
[jc: taking suggestions from Linus and Johannes to match expectations
from shell users who are used to see $@ or $* either of which makes
sense. I tend to write "$@" more often so...]
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
"git diff(n)" without --base, --ours, etc. defaults to --cc,
which usually is the same as -p unless you are in the middle of
a conflicted merge, just like the shell script version.
"git diff(n) blobA blobB path" complains and dies.
"git diff(n) tree0 tree1 tree2...treeN" does combined diff that
shows a merge of tree1..treeN to result in tree0.
Giving "-c" option to any command that defaults to "--cc" turns
off dense-combined flag.
replace adler32 with Rabin's polynomial in diff-delta
This brings another small repacking speedup for sensibly the same pack
size. On the Linux kernel repo, git-repack -a -f is 3.7% faster for a
0.4% larger pack.
Credits to Geert Bosch who brought the Rabin's polynomial idea to my
attention.
This also eliminate the issue of adler32() reading past the data buffer,
as noticed by Johannes Schindelin.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Fix trivial typo in git-log man page.
Properly render asciidoc "callouts" in git man pages.
Fix up remaining man pages that use asciidoc "callouts".
Update the git-branch man page to include the "-r" option,
annotate: display usage information if no filename was given
annotate: fix warning about uninitialized scalar
git-am --resolved: more usable error message.
* fix:
Fix trivial typo in git-log man page.
Properly render asciidoc "callouts" in git man pages.
Fix up remaining man pages that use asciidoc "callouts".
Update the git-branch man page to include the "-r" option,
annotate: display usage information if no filename was given
annotate: fix warning about uninitialized scalar
git-am --resolved: more usable error message.
Properly render asciidoc "callouts" in git man pages.
Adds an xsl fragment to render docbook callouts when
converting to man page format. Update the Makefile
to have "xmlto" use it when generating man pages.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Fix up remaining man pages that use asciidoc "callouts".
Unfortunately docbook does not allow a callout to be
referenced from inside a callout list description.
Rewrite one paragraph in git-reset man page to work
around this limitation.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
After doing the hard work of hand resolving the conflicts in the
working tree, if the user forgets to run update-index to mark
the paths that have been resolved, the command gave an
unfriendly "fatal: git-write-tree: not able to write tree" error
message. Catch the situation early and give more meaningful
message and suggestion.
- number of loose objects
- disk occupied by loose objects
- number of objects in local packs
- number of loose objects that are also in pack
- unrecognised garbage in .git/objects/??/.
We used to omit delta base candidates that is much bigger than
the target, but delta size does not grow when we delete more, so
that was not a very good heuristics.
When I split out the builtin commands into their own files, I left the
include of <sys/ioctl.h> in git.c rather than moving it to the file that
needed it (builtin-help.c).
Nobody seems to have noticed, because everything still worked, but because
the TIOCGWINSZ macro was now no longer defined when compiling the
"term_columns()" function, it would no longer automatically notice the
terminal size unless your system used the ancient "COLUMNS" environment
variable approach.
Trivially fixed by just moving the header include to the file that
actually needs it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/cache-tree:
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.
read-tree: teach 1-way merege and plain read to prime cache-tree.
This teaches read-tree to fully populate valid cache-tree when
reading a tree from scratch, or reading a single tree into an
existing index, reusing only the cached stat information (i.e.
one-way merge). We have already taught update-index about cache-tree,
so "git checkout" followed by updates to a few path followed by
a "git commit" would become very efficient.
read-tree: teach 1 and 2 way merges about cache-tree.
This teaches one-way and two-way "read-tree -m" (and its special
form, "read-tree --reset" as well) not to discard cache-tree but
invalidate only the changed parts of the tree. When switching
between related branches, this helps the eventual commit
(i.e. write-tree) by keeping cache-tree valid as much as
possible.
This does not prime cache-tree yet, but we ought to be able to
do that for no-merge (i.e. reading from a tree object) case and,
and also perhaps 1 way merge case.
With this patch applied, switching between the tip of Linux 2.6
kernel tree and a branch that touches one path (fs/ext3/Makefile)
from it invalidates only 3 paths out of 1201 cache-tree entries
in the index, and subsequent write-tree takes about a half as
much time as before.
* master:
t0000-basic: more commit-tree tests.
commit-tree.c: check_valid() microoptimization.
Fix filename verification when in a subdirectory
rebase: typofix.
socksetup: don't return on set_reuse_addr() error
* nh/fetch-http:
git-fetch: resolve remote symrefs for HTTP transport
commit-tree.c: check_valid() microoptimization.
Fix filename verification when in a subdirectory
rebase: typofix.
socksetup: don't return on set_reuse_addr() error
git-fetch: resolve remote symrefs for HTTP transport
git-fetch validates that a remote ref resolves to a SHA1 prior to calling
git-http-fetch. This adds support for resolving a few levels of symrefs
to get to the SHA1.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
git rebase [--onto <newbase>] <upstream> [<branch>]
git rebase --continue
git rebase --abort
Add "--continue" to restart the rebase process after
manually resolving conflicts. The user is warned if
there are still differences between the index and the
working files.
Add "--abort" to restore the original branch, and
remove the .dotest working files.
Some minor additions to the git-rebase documentation.
[jc: fix that applies to the maintenance track has been dealt
with separately.]
* fix:
commit-tree.c: check_valid() microoptimization.
Fix filename verification when in a subdirectory
rebase: typofix.
socksetup: don't return on set_reuse_addr() error
There is no point reading the whole object just to make sure it exists and
it is of the expected type. We added sha1_object_info() for such need
after this code was written, so use it.
When we are in a subdirectory of a git archive, we need to take the prefix
of that subdirectory into accoung when we verify filename arguments.
Noted by Matthias Lederhofer
This also uses the improved error reporting for all the other git commands
that use the revision parsing interfaces, not just git-rev-parse. Also, it
makes the error reporting for mixed filenames and argument flags clearer
(you cannot put flags after the start of the pathname list).
[jc: with fix to a trivial typo noticed by Timo Hirvonen]
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/cache-tree:
commit-tree: allow generic object name for the tree as well.
Makefile: remove and create xdiff library from scratch.
t0000-basic: Add ls-tree recursive test back.
* master:
commit-tree: allow generic object name for the tree as well.
Makefile: remove and create xdiff library from scratch.
t0000-basic: Add ls-tree recursive test back.
Libified diff-index: backward compatibility fix.
Libify diff-index.
Libify diff-files.
Makefile: remove and create libgit.a from scratch.
Document the configuration file
Document git-var -l listing also configuration variables
rev-parse: better error message for ambiguous arguments
make update-index --chmod work with multiple files and --stdin
socksetup: don't return on set_reuse_addr() error
Fix "git show --stat"
git-update-index --unresolve
Add git-unresolve <paths>...
Add colordiff for git to contrib/colordiff.
gitk: Let git-rev-list do the argument list parsing
commit-tree: allow generic object name for the tree as well.
We use get_sha1() for -p (parent) objects, but still used
get_sha1_hex() for the tree. Just to be consistent, allow
extended SHA1 expression for the tree object name.
Note that this is not to encourage funky things like this:
When we updated ls-tree recursive output to omit the tree nodes, 246cc52f388cae8ca99e5a12b8458c9bfa467765 adjusted the old test
so that we do not expect to see trees in its output. Later,
with 0f8f45cb4a7e664b396f73c25891da46b953b8b8, we added back the
ability to show both with -t option, but we forgot to update the
test as well.
The patch format shows complete rewrite as deletion of all old lines
followed by addition of all new lines. Count lines consistenly with
that when doing diffstat.
Makefile: remove and create libgit.a from scratch.
Foolishly I renamed diff.o around which caused an old diff.o
taken out of libgit.a and got linked into resulting binary and
exhibited mysterious breakage for many people. This borrows
from the kernel Makefile (scripts/Makefile.build) to first remove
the target and then recreate.