After 567ffeb772 and
4bc87a28be, git-send-email no
longer requires any non-standard Perl modules, so there's no
reason to special-case it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
NetBSD >=2.0 has iconv() in libc. A libiconv is not required and
does not exist.
See: http://netbsd.gw.com/cgi-bin/man-cgi?iconv+3+NetBSD-2.0
[jc: with a bit of simplification later discussed on the list.]
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/apply:
apply --numstat: show new name, not old name.
Ensure author & committer before asking for commit message.
Install git-send-email by default
send-email: address expansion for common mailers
diffstat rename squashing fix.
After 567ffeb772 and
4bc87a28be, git-send-email no
longer requires any non-standard Perl modules, so there's no
reason to special-case it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/delta:
improve diff-delta with sparse and/or repetitive data
tiny optimization to diff-delta
replace adler32 with Rabin's polynomial in diff-delta
use delta index data when finding best delta matches
split the diff-delta interface
* jc/bindiff:
binary diff: further updates.
binary patch.
pack-object: squelch eye-candy on non-tty
core.prefersymlinkrefs: use symlinks for .git/HEAD
repo-config: trim white-space before comment
Fix for config file section parsing.
Clarify git-cherry documentation.
Update git-unpack-objects documentation.
Fix up docs where "--" isn't displayed correctly.
Several trivial documentation touch ups.
git-svn 1.0.0
git-svn: documentation updates
delta: stricter constness
Makefile: do not link rev-list any specially.
builtin-push: --all and --tags _are_ explicit refspecs
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9f0bb90d16 commit)
We used to depend on bignum from openssl for rev-list to compute
merge-order, but there is no reason to use different build
recipe from other programs anymore. Just build it with git-%$X
rule like everybody else.
Noticed by Alexey Dobriyan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/fetchconfig:
Add a conversion tool to migrate remote information into the config
fetch, pull: ask config for remote information
Add a few more words to the glossary.
Added definitions for a few words:
Alphabetize the glossary.
sha1_to_hex() usage cleanup
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove the shell-script version, make the hardlink from the git
binary, and update the documentation to describe a new option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
Also it learned to do -v (verbose) to report:
- 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/??/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For now let's retire this and reintroduce it as part of the updated
pack-objects series from Geert when it is ready.
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
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was useful in diagnosing the corrupt index.aux format
problem. But do not bother building or installing it by
default.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The cache_tree data structure is to cache tree object names that
would result from the current index file.
The idea is to have an optional file to record each tree object
name that corresponds to a directory path in the cache when we
run write_cache(), and read it back when we run read_cache().
During various index manupulations, we selectively invalidate
the parts so that the next write-tree can bypass regenerating
tree objects for unchanged parts of the directory hierarchy.
We could perhaps make the cache-tree data an optional part of
the index file, but that would involve the index format updates,
so unless we need it for performance reasons, the current plan
is to use a separate file, $GIT_DIR/index.aux to store this
information and link it with the index file with the checksum
that is already used for index file integrity check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is the first installment to libify diff brothers.
The updated diff-files uses revision.c::setup_revisions()
infrastructure to parse its command line arguments, which means
the pathname arguments are checked more strictly than before.
The tests are adjusted to separate possibly missing paths from
the rest of arguments with double-dashes, to show the kosher
way.
As Linus pointed out, renaming diff.c to diff-lib.c was simply
stupid, so I am renaming it back. The new diff-lib.c is to
contain pieces extracted from diff brothers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Right now it split it into "builtin-log.c" for log-related commands
("log", "show" and "whatchanged"), and "builtin-help.c" for the
informational commands (usage printing and "help" and "version").
This just makes things easier to read, I find.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Retire git-unresolve and make it into "git-update-index --unresolve".
It processes all paths that follow.
During a merge, you would mark a path that is dealt with with:
$ git update-index hello
and you would "undo" it with:
$ git update-index --unresolve hello
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/unresolve:
Add git-unresolve <paths>...
get_tree_entry(): make it available from tree-walk
sha1_name.c: no need to include diff.h; tree-walk.h will do.
sha1_name.c: prepare to make get_tree_entry() reusable from others.
pre-commit hook: complain about conflict markers.
git-merge: a bit more readable user guidance.
diff: move diff.c to diff-lib.c to make room.
git log: don't do merge diffs by default
Allow "git repack" users to specify repacking window/depth
This is an attempt to address the issue raised on #git channel
recently by Carl Worth.
After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch. During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going. However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.
With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files. This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".
One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.
We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/boundary:
rev-list --boundary: show boundary commits even when limited otherwise.
Makefile fixups.
gitk: Fix bug caused by missing commitlisted elements
This splits Geert's similarity fingerprint code into main
program and fingerprinting function. The next step would be to
try using this in pack-objects.c::try_delta() -- which would be
a good evaluation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This target lists undocumented commands, and/or whose document
is not referenced from the main git documentation.
For now, there are some exceptions I added primarily because I
lack the energy to document them myself:
- merge backends (we should really document them)
- ssh-push/ssh-pull (does anybody still use them?)
- annotate and blame (maybe after one of them eats the other ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Nobody except diff-stages used it -- the callers instead filtered
the input to diffcore themselves. Make diff-stages do that as
well and retire diffcore-pathspec.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This separates out the part that deals with one-commit diff-tree
(and --stdin form) into a separate log-tree module.
There are two goals with this. The more important one is to be
able to make this part available to "git log --diff", so that we
can have a native "git whatchanged" command. Another is to
simplify the commit log generation part simpler.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With an old curl version, git-http-push is not compiled. But git-http-fetch
still needs to be linked with expat if NO_EXPAT is not defined.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
[jc: with trivial documentation fix, noticed by Jakub Narebski]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This refactors the line-by-line callback mechanism used in
combine-diff so that other programs can reuse it more easily.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Useful for diagnostics/troubleshooting to know which client versions are
hitting your server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The dependency was not properly updated when we added this
library, breaking parallel build with $(MAKE) -j.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce tree-walk.[ch] and move "struct tree_desc" and
associated functions from various places.
Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and
move it to cache.h. This macro returns the canonicalized
st_mode value in the host byte order for files, symlinks and
directories -- to be compared with a tree_desc entry.
create_ce_mode(mode) in cache.h is similar but is intended to be
used for index entries (so it does not work for directories) and
returns the value in the network byte order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For some reason, I need ALL_LDFLAGS in the git target only on
AIX. Once it builds, only one test "fails" on AIX 5.1 with
1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
odd tool problem in the tester + my setup and not a real bug.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By changing the dependency "$(LIB_H)" to "$(LIBS)", at least one version
of make thought that a file named "-lz" would be needed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses a simplified libxdiff setup to generate unified diffs _without_
doing fork/execve of GNU "diff".
This has several huge advantages, for example:
Before:
[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null
real 0m24.818s
user 0m13.332s
sys 0m8.664s
After:
[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null
real 0m4.563s
user 0m2.944s
sys 0m1.580s
and the fact that this should be a lot more portable (ie we can ignore all
the issues with doing fork/execve under Windows).
Perhaps even more importantly, this allows us to do diffs without actually
ever writing out the git file contents to a temporary file (and without
any of the shell quoting issues on filenames etc etc).
NOTE! THIS PATCH DOES NOT DO THAT OPTIMIZATION YET! I was lazy, and the
current "diff-core" code actually will always write the temp-files,
because it used to be something that you simply had to do. So this current
one actually writes a temp-file like before, and then reads it into memory
again just to do the diff. Stupid.
But if this basic infrastructure is accepted, we can start switching over
diff-core to not write temp-files, which should speed things up even
further, especially when doing big tree-to-tree diffs.
Now, in the interest of full disclosure, I should also point out a few
downsides:
- the libxdiff algorithm is different, and I bet GNU diff has gotten a
lot more testing. And the thing is, generating a diff is not an exact
science - you can get two different diffs (and you will), and they can
both be perfectly valid. So it's not possible to "validate" the
libxdiff output by just comparing it against GNU diff.
- GNU diff does some nice eye-candy, like trying to figure out what the
last function was, and adding that information to the "@@ .." line.
libxdiff doesn't do that.
- The libxdiff thing has some known deficiencies. In particular, it gets
the "\No newline at end of file" case wrong. So this is currently for
the experimental branch only. I hope Davide will help fix it.
That said, I think the huge performance advantage, and the fact that it
integrates better is definitely worth it. But it should go into a
development branch at least due to the missing newline issue.
Technical note: this is based on libxdiff-0.17, but I did some surgery to
get rid of the extraneous fat - stuff that git doesn't need, and seriously
cutting down on mmfile_t, which had much more capabilities than the diff
algorithm either needed or used. In this version, "mmfile_t" is just a
trivial <pointer,length> tuple.
That said, I tried to keep the differences to simple removals, so that you
can do a diff between this and the libxdiff origin, and you'll basically
see just things getting deleted. Even the mmfile_t simplifications are
left in a state where the diffs should be readable.
Apologies to Davide, whom I'd love to get feedback on this all from (I
wrote my own "fill_mmfile()" for the new simpler mmfile_t format: the old
complex format had a helper function for that, but I did my surgery with
the goal in mind that eventually we _should_ just do
mmfile_t mf;
buf = read_sha1_file(sha1, type, &size);
mf->ptr = buf;
mf->size = size;
.. use "mf" directly ..
which was really a nightmare with the old "helpful" mmfile_t, and really
is that easy with the new cut-down interfaces).
[ Btw, as any hawk-eye can see from the diff, this was actually generated
with itself, so it is "self-hosting". That's about all the testing it
has gotten, along with the above kernel diff, which eye-balls correctly,
but shows the newline issue when you double-check it with "git-apply" ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fk/blame:
blame: Rename detection (take 2)
rev-lib: Make it easy to do rename tracking (take 2)
Make it possible to not clobber object.util in sort_in_topological_order (take 2)
Add git-imap-send, derived from isync 1.0.1.
repack: prune loose objects when -d is given
try_to_simplify_commit(): do not skip inspecting tree change at boundary.
Fix t1200 test for breakage caused by removal of full-stop at the end of fast-forward message.
Describe how to add extra mail header lines in mail generated by git-format-patch.
Document the --attach flag.
allow double click on current HEAD id after git-pull
git-imap-send drops a patch series generated by git-format-patch into an
IMAP folder. This allows patch submitters to send patches through their
own mail program.
git-imap-send uses the following values from the GIT repository
configuration:
The target IMAP folder:
[imap]
Folder = "INBOX.Drafts"
A command to open an ssh tunnel to the imap mail server.
[imap]
Tunnel = "ssh -q user@imap.server.com /usr/bin/imapd ./Maildir
2> /dev/null"
[imap]
Host = imap.server.com
User = bob
Password = pwd
Port = 143
* jc/fsck:
fsck-objects: Remove --standalone
refs.c::do_for_each_ref(): Finish error message lines with "\n"
Nicer output from 'git'
Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
Remove trailing dot after short description
Fix some inconsistencies in the docs
contrib/git-svn: fix a harmless warning on rebuild (with old repos)
contrib/git-svn: remove the --no-stop-on-copy flag
contrib/git-svn: fix svn compat and fetch args
Don't recurse into parents marked uninteresting.
diff-delta: bound hash list length to avoid O(m*n) behavior
test-delta needs zlib to compile
git-fmt-merge-msg cleanup
This brings http-push functionality more in line with the ssh/git version,
by borrowing bits from send-pack and rev-list to process refspecs and
revision history in more standard ways. Also, the status of remote objects
is determined using PROPFIND requests for the object directory rather than
HEAD requests for each object - while it may be less efficient for small
numbers of objects, this approach is able to get the status of all remote
loose objects in a maximum of 256 requests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The default output mode is slightly different from git-annotate's.
However, git-annotate's output mode can be obtained by using the
'-c' flag.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a companion patch to e29e1147e4
which made diffcore similarity estimator independent from the packfile
deltifier. There is no reason for us to be counting the xdelta anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lt/rev-list:
setup_revisions(): handle -n<n> and -<n> internally.
git-log (internal): more options.
git-log (internal): add approxidate.
Rip out merge-order and make "git log <paths>..." work again.
Tie it all together: "git log"
Introduce trivial new pager.c helper infrastructure
git-rev-list libification: rev-list walking
Splitting rev-list into revisions lib, end of beginning.
rev-list split: minimum fixup.
First cut at libifying revlist generation
Now blame will depend on the new revision walker infrastructure,
we need to make it depend on earlier parts of Linus' rev-list
topic branch, hence this merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
