assume unchanged git: diff-index fix.
When the executable bit is untrustworthy and when we are
comparing the tree with the working tree, we tried to reuse the
mode bits recorded in the index incorrectly (the computation was
bogus on little endian architectures). Just use mode from index
when it is a regular file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the executable bit is untrustworthy and when we are
comparing the tree with the working tree, we tried to reuse the
mode bits recorded in the index incorrectly (the computation was
bogus on little endian architectures). Just use mode from index
when it is a regular file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
revision.c "..B" syntax: constness fix
The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B)
has constness gotcha GCC complains. Fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B)
has constness gotcha GCC complains. Fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
revision arguments: ..B means HEAD..B, just like A.. means A..HEAD
For consistency reasons, we should probably allow that to be written as
just "..branch", the same way we can write "branch.." to mean "everything
in HEAD but not in "branch".
Signed-off-by: Junio C Hamano <junkio@cox.net>
For consistency reasons, we should probably allow that to be written as
just "..branch", the same way we can write "branch.." to mean "everything
in HEAD but not in "branch".
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list --boundary
With the new --boundary flag, the output from rev-list includes
the UNINTERESING commits at the boundary, which are usually not
shown. Their object names are prefixed with '-'.
For example, with this graph:
C side
/
A---B---D master
You would get something like this:
$ git rev-list --boundary --header --parents side..master
D B
tree D^{tree}
parent B
... log message for commit D here ...
\0-B A
tree B^{tree}
parent A
... log message for commit B here ...
\0
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the new --boundary flag, the output from rev-list includes
the UNINTERESING commits at the boundary, which are usually not
shown. Their object names are prefixed with '-'.
For example, with this graph:
C side
/
A---B---D master
You would get something like this:
$ git rev-list --boundary --header --parents side..master
D B
tree D^{tree}
parent B
... log message for commit D here ...
\0-B A
tree B^{tree}
parent A
... log message for commit B here ...
\0
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list: memory usage reduction.
We do not need to track object refs, neither we need to save commit
unless we are doing verbose header. A lot of traversal happens
inside prepare_revision_walk() these days so setting things up before
calling that function is necessary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Linus Torvalds <torvalds@osdl.org>
We do not need to track object refs, neither we need to save commit
unless we are doing verbose header. A lot of traversal happens
inside prepare_revision_walk() these days so setting things up before
calling that function is necessary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Linus Torvalds <torvalds@osdl.org>
rev-list --no-merges: argument parsing fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
xdiff: Show function names in hunk headers.
The speed of the built-in diff generator is nice; but the function names
shown by `diff -p' are /really/ nice. And I hate having to choose. So,
we hack xdiff to find the function names and print them.
xdiff has grown a flag to say whether to dig up the function names. The
builtin_diff function passes this flag unconditionally. I suppose it
could parse GIT_DIFF_OPTS, but it doesn't at the moment. I've also
reintroduced the `function name' into the test suite, from which it was
removed in commit 3ce8f089.
The function names are parsed by a particularly stupid algorithm at the
moment: it just tries to find a line in the `old' file, from before the
start of the hunk, whose first character looks plausible. Still, it's
most definitely a start.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The speed of the built-in diff generator is nice; but the function names
shown by `diff -p' are /really/ nice. And I hate having to choose. So,
we hack xdiff to find the function names and print them.
xdiff has grown a flag to say whether to dig up the function names. The
builtin_diff function passes this flag unconditionally. I suppose it
could parse GIT_DIFF_OPTS, but it doesn't at the moment. I've also
reintroduced the `function name' into the test suite, from which it was
removed in commit 3ce8f089.
The function names are parsed by a particularly stupid algorithm at the
moment: it just tries to find a line in the `old' file, from before the
start of the hunk, whose first character looks plausible. Still, it's
most definitely a start.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add ALL_LDFLAGS to the git target.
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>
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>
GIT 1.3.0 rc1
All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).
So I am clearing the deck to prepare for a 1.3.0. Remaining
wrinkles, if any, will be ironed in the "master" branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).
So I am clearing the deck to prepare for a 1.3.0. Remaining
wrinkles, if any, will be ironed in the "master" branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch ak/svn
Merge branch 'lt/diffgen' into next
* lt/diffgen:
add clean and ignore rules for xdiff/
Remove dependency on a file named "-lz"
* lt/diffgen:
add clean and ignore rules for xdiff/
Remove dependency on a file named "-lz"
Merge branch 'master' into next
* master:
Optionally do not list empty directories in git-ls-files --others
Document git-rebase behavior on conflicts.
Fix error handling for nonexistent names
* master:
Optionally do not list empty directories in git-ls-files --others
Document git-rebase behavior on conflicts.
Fix error handling for nonexistent names
add clean and ignore rules for xdiff/
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Optionally do not list empty directories in git-ls-files --others
Without the --directory flag, git-ls-files wouldn't ever list directories,
producing no output for empty directories, which is good since they cannot
be added and they bear no content, even untracked one (if Git ever starts
tracking directories on their own, this should obviously change since the
content notion will change).
With the --directory flag however, git-ls-files would list even empty
directories. This may be good in some situations but sometimes you want to
prevent that. This patch adds a --no-empty-directory option which makes
git-ls-files omit empty directories.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Without the --directory flag, git-ls-files wouldn't ever list directories,
producing no output for empty directories, which is good since they cannot
be added and they bear no content, even untracked one (if Git ever starts
tracking directories on their own, this should obviously change since the
content notion will change).
With the --directory flag however, git-ls-files would list even empty
directories. This may be good in some situations but sometimes you want to
prevent that. This patch adds a --no-empty-directory option which makes
git-ls-files omit empty directories.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Document git-rebase behavior on conflicts.
Remove dependency on a file named "-lz"
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>
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>
Fix error handling for nonexistent names
When passing in a pathname pattern without the "--" separator on the
command line, we verify that the pathnames in question exist. However,
there were two bugs in that verification:
- git-rev-parse would only check the first pathname, and silently allow
any invalid subsequent pathname, whether it existed or not (which
defeats the purpose of the check, and is also inconsistent with what
git-rev-list actually does)
- git-rev-list (and "git log" etc) would check each filename, but if the
check failed, it would print the error using the first one, i.e.:
[torvalds@g5 git]$ git log Makefile bad-file
fatal: 'Makefile': No such file or directory
instead of saying that it's 'bad-file' that doesn't exist.
This fixes both bugs.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When passing in a pathname pattern without the "--" separator on the
command line, we verify that the pathnames in question exist. However,
there were two bugs in that verification:
- git-rev-parse would only check the first pathname, and silently allow
any invalid subsequent pathname, whether it existed or not (which
defeats the purpose of the check, and is also inconsistent with what
git-rev-list actually does)
- git-rev-list (and "git log" etc) would check each filename, but if the
check failed, it would print the error using the first one, i.e.:
[torvalds@g5 git]$ git log Makefile bad-file
fatal: 'Makefile': No such file or directory
instead of saying that it's 'bad-file' that doesn't exist.
This fixes both bugs.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/thin' into next
* jc/thin:
git-push: make --thin pack transfer the default.
gitk: Fix two bugs reported by users
gitk: Improve appearance of first child links
gitk: Make downward-pointing arrows end in vertical line segment
gitk: Don't change cursor at end of layout if find in progress
gitk: Make commitdata an array rather than a list
gitk: Fix display of diff lines beginning with --- or +++
[PATCH] gitk: Make error_popup react to Return
gitk: Fix a bug in drawing the selected line as a thick line
gitk: Further speedups
gitk: Various speed improvements
gitk: Fix Update menu item
gitk: Fix clicks on arrows on line ends
gitk: New improved gitk
contrib/git-svn: stabilize memory usage for big fetches
* jc/thin:
git-push: make --thin pack transfer the default.
gitk: Fix two bugs reported by users
gitk: Improve appearance of first child links
gitk: Make downward-pointing arrows end in vertical line segment
gitk: Don't change cursor at end of layout if find in progress
gitk: Make commitdata an array rather than a list
gitk: Fix display of diff lines beginning with --- or +++
[PATCH] gitk: Make error_popup react to Return
gitk: Fix a bug in drawing the selected line as a thick line
gitk: Further speedups
gitk: Various speed improvements
gitk: Fix Update menu item
gitk: Fix clicks on arrows on line ends
gitk: New improved gitk
contrib/git-svn: stabilize memory usage for big fetches
git-push: make --thin pack transfer the default.
Just in case it has problems, you can say "git push --no-thin".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just in case it has problems, you can say "git push --no-thin".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branches 'jc/clone' and 'jc/name'
* jc/clone:
git-clone: typofix.
clone: record the remote primary branch with remotes/$origin/HEAD
revamp git-clone (take #2).
revamp git-clone.
fetch,parse-remote,fmt-merge-msg: refs/remotes/* support
* jc/name:
sha1_name: make core.warnambiguousrefs the default.
sha1_name: warning ambiguous refs.
get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
* jc/clone:
git-clone: typofix.
clone: record the remote primary branch with remotes/$origin/HEAD
revamp git-clone (take #2).
revamp git-clone.
fetch,parse-remote,fmt-merge-msg: refs/remotes/* support
* jc/name:
sha1_name: make core.warnambiguousrefs the default.
sha1_name: warning ambiguous refs.
get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
Merge branch 'jc/merge'
* jc/merge:
git-merge knows some strategies want to skip trivial merges
* jc/merge:
git-merge knows some strategies want to skip trivial merges
Merge branch 'lt/diffgen' into next
* lt/diffgen:
true built-in diff: run everything in-core.
* lt/diffgen:
true built-in diff: run everything in-core.
git-svnimport: if a limit is specified, respect it
git-svnimport will import the same revision over and over again if a
limit (-l <rev>) has been specified. Instead if that revision has already
been processed, exit with an up-to-date message.
Signed-off-by: Anand Kumria <wildfire@progsoc.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svnimport will import the same revision over and over again if a
limit (-l <rev>) has been specified. Instead if that revision has already
been processed, exit with an up-to-date message.
Signed-off-by: Anand Kumria <wildfire@progsoc.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge git://git.kernel.org/pub/scm/gitk/gitk
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix two bugs reported by users
gitk: Improve appearance of first child links
gitk: Make downward-pointing arrows end in vertical line segment
gitk: Don't change cursor at end of layout if find in progress
gitk: Make commitdata an array rather than a list
gitk: Fix display of diff lines beginning with --- or +++
[PATCH] gitk: Make error_popup react to Return
gitk: Fix a bug in drawing the selected line as a thick line
gitk: Further speedups
gitk: Various speed improvements
gitk: Fix Update menu item
gitk: Fix clicks on arrows on line ends
gitk: New improved gitk
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix two bugs reported by users
gitk: Improve appearance of first child links
gitk: Make downward-pointing arrows end in vertical line segment
gitk: Don't change cursor at end of layout if find in progress
gitk: Make commitdata an array rather than a list
gitk: Fix display of diff lines beginning with --- or +++
[PATCH] gitk: Make error_popup react to Return
gitk: Fix a bug in drawing the selected line as a thick line
gitk: Further speedups
gitk: Various speed improvements
gitk: Fix Update menu item
gitk: Fix clicks on arrows on line ends
gitk: New improved gitk
true built-in diff: run everything in-core.
This stops using temporary files when we are using the built-in
diff (including the complete rewrite).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This stops using temporary files when we are using the built-in
diff (including the complete rewrite).
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: stabilize memory usage for big fetches
We should be safely able to import histories with thousands
of revisions without hogging up lots of memory.
With this, we lose the ability to autocorrect mistakes when
people specify revisions in reverse, but it's probably no longer
a problem since we only have one method of log parsing nowadays.
I've added an extra check to ensure that revision numbers do
increment.
Also, increment the version number to 0.11.0. I really should
just call it 1.0 soon...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We should be safely able to import histories with thousands
of revisions without hogging up lots of memory.
With this, we lose the ability to autocorrect mistakes when
people specify revisions in reverse, but it's probably no longer
a problem since we only have one method of log parsing nowadays.
I've added an extra check to ensure that revision numbers do
increment.
Also, increment the version number to 0.11.0. I really should
just call it 1.0 soon...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'ew/email' into next
* ew/email:
send-email: lazy-load Email::Valid and make it optional
send-email: try to order messages in email clients more correctly
send-email: Change from Mail::Sendmail to Net::SMTP
send-email: use built-in time() instead of /bin/date '+%s'
* ew/email:
send-email: lazy-load Email::Valid and make it optional
send-email: try to order messages in email clients more correctly
send-email: Change from Mail::Sendmail to Net::SMTP
send-email: use built-in time() instead of /bin/date '+%s'
Merge branch 'lt/diffgen' into next
* lt/diffgen:
built-in diff: minimum tweaks
builtin-diff: \No newline at end of file.
Use a *real* built-in diff generator
* lt/diffgen:
built-in diff: minimum tweaks
builtin-diff: \No newline at end of file.
Use a *real* built-in diff generator
Merge branch 'rs/tar-tree' into next
* rs/tar-tree:
tar-tree: Use the prefix field of a tar header
tar-tree: Remove obsolete code
tar-tree: Use write_entry() to write the archive contents
tar-tree: Introduce write_entry()
tar-tree: Use SHA1 of root tree for the basedir
git-apply: safety fixes
Removed bogus "<snap>" identifier.
Clarify and expand some hook documentation.
commit-tree: check return value from write_sha1_file()
send-email: Identify author at the top when sending e-mail
Format tweaks for asciidoc.
* rs/tar-tree:
tar-tree: Use the prefix field of a tar header
tar-tree: Remove obsolete code
tar-tree: Use write_entry() to write the archive contents
tar-tree: Introduce write_entry()
tar-tree: Use SHA1 of root tree for the basedir
git-apply: safety fixes
Removed bogus "<snap>" identifier.
Clarify and expand some hook documentation.
commit-tree: check return value from write_sha1_file()
send-email: Identify author at the top when sending e-mail
Format tweaks for asciidoc.
send-email: lazy-load Email::Valid and make it optional
It's not installed on enough machines, and is overkill most of
the time. We'll fallback to a very basic regexp just in case,
but nothing like the monster regexp Email::Valid has to offer :)
Small cleanup from Merlyn.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's not installed on enough machines, and is overkill most of
the time. We'll fallback to a very basic regexp just in case,
but nothing like the monster regexp Email::Valid has to offer :)
Small cleanup from Merlyn.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
send-email: try to order messages in email clients more correctly
If --no-chain-reply-to is set, patches may not always be ordered
correctly in email clients. This patch makes sure each email
sent from a different second.
I chose to start with a time (slightly) in the past because
those are probably more likely in real-world usage and spam
filters might be more tolerant of them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If --no-chain-reply-to is set, patches may not always be ordered
correctly in email clients. This patch makes sure each email
sent from a different second.
I chose to start with a time (slightly) in the past because
those are probably more likely in real-world usage and spam
filters might be more tolerant of them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
send-email: Change from Mail::Sendmail to Net::SMTP
Net::SMTP is in the base Perl distribution, so users are more
likely to have it. Net::SMTP also allows reusing the SMTP
connection, so sending multiple emails is faster.
[jc: tweaked X-Mailer further while we are at it.]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Net::SMTP is in the base Perl distribution, so users are more
likely to have it. Net::SMTP also allows reusing the SMTP
connection, so sending multiple emails is faster.
[jc: tweaked X-Mailer further while we are at it.]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
send-email: use built-in time() instead of /bin/date '+%s'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
built-in diff: minimum tweaks
This fixes up a couple of minor issues with the real built-in
diff to be more usable:
- Omit ---/+++ header unless we emit diff output;
- Detect and punt binary diff like GNU does;
- Honor GIT_DIFF_OPTS minimally (only -u<number> and
--unified=<number> are currently supported);
- Omit line count of 1 from "@@ -l,k +m,n @@" hunk header
(i.e. when k == 1 or n == 1)
- Adjust testsuite for the lack of -p support.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes up a couple of minor issues with the real built-in
diff to be more usable:
- Omit ---/+++ header unless we emit diff output;
- Detect and punt binary diff like GNU does;
- Honor GIT_DIFF_OPTS minimally (only -u<number> and
--unified=<number> are currently supported);
- Omit line count of 1 from "@@ -l,k +m,n @@" hunk header
(i.e. when k == 1 or n == 1)
- Adjust testsuite for the lack of -p support.
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-diff: \No newline at end of file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use a *real* built-in diff generator
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>
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>
tar-tree: Use the prefix field of a tar header
... to store parts of the path, if possible. This allows us to avoid
writing extended headers in certain cases (long pathes can only be
split at '/' chars).
Also adds a file to the test repo with a 100 chars long directory name.
Even old versions of tar that don't understand POSIX extended headers
should be able to handle this testcase.
Btw.: The longest path in the kernel tree currently has 70 chars.
Together with a 30 chars long prefix this would already cross the
field limit of 100 chars.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... to store parts of the path, if possible. This allows us to avoid
writing extended headers in certain cases (long pathes can only be
split at '/' chars).
Also adds a file to the test repo with a 100 chars long directory name.
Even old versions of tar that don't understand POSIX extended headers
should be able to handle this testcase.
Btw.: The longest path in the kernel tree currently has 70 chars.
Together with a 30 chars long prefix this would already cross the
field limit of 100 chars.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
tar-tree: Remove obsolete code
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
tar-tree: Use write_entry() to write the archive contents
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
tar-tree: Introduce write_entry()
... and use it initially to write global extended header records.
Improvements compared to the old write_header():
- Uses a struct ustar_header instead of hardcoded offsets.
- Takes one struct strbuf as path argument instead of a (basedir,
prefix, name) tuple.
- Not only writes the tar header, but also the contents of the
file, if any.
- Does not write directly into the ring buffer. This allows the
code to be layed out more naturally, because there is no more
ordering constraint. Before we had to first finish writing the
extended header, now we can construct the extended and normal
headers in parallel.
- The typeflag parameter has been replaced by (reasonable) magic
values. path == NULL indicates an extended header, additionally
sha1 == NULL means it is a global extended header.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... and use it initially to write global extended header records.
Improvements compared to the old write_header():
- Uses a struct ustar_header instead of hardcoded offsets.
- Takes one struct strbuf as path argument instead of a (basedir,
prefix, name) tuple.
- Not only writes the tar header, but also the contents of the
file, if any.
- Does not write directly into the ring buffer. This allows the
code to be layed out more naturally, because there is no more
ordering constraint. Before we had to first finish writing the
extended header, now we can construct the extended and normal
headers in parallel.
- The typeflag parameter has been replaced by (reasonable) magic
values. path == NULL indicates an extended header, additionally
sha1 == NULL means it is a global extended header.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
tar-tree: Use SHA1 of root tree for the basedir
... instead of the made-up "0".
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... instead of the made-up "0".
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply: safety fixes
This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.
Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.
So make git-apply refuse to look at a patch fragment that ends early.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.
Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.
So make git-apply refuse to look at a patch fragment that ends early.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Removed bogus "<snap>" identifier.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify and expand some hook documentation.
Clarify update and post-update hooks.
Made a few references to the hooks documentation.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify update and post-update hooks.
Made a few references to the hooks documentation.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit-tree: check return value from write_sha1_file()
... found by Matthias Kestenholz.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... found by Matthias Kestenholz.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/name' into next
* jc/name:
sha1_name: make core.warnambiguousrefs the default.
sha1_name: warning ambiguous refs.
* jc/name:
sha1_name: make core.warnambiguousrefs the default.
sha1_name: warning ambiguous refs.
Merge branch 'jc/cvsimport'
* jc/cvsimport:
cvsimport: fix reading from rev-parse
cvsimport: honor -i and non -i upon subsequent imports
* jc/cvsimport:
cvsimport: fix reading from rev-parse
cvsimport: honor -i and non -i upon subsequent imports
Merge branch 'jc/pull'
* jc/pull:
git-pull: reword "impossible to fast-forward" message.
git-pull: further safety while on tracking branch.
* jc/pull:
git-pull: reword "impossible to fast-forward" message.
git-pull: further safety while on tracking branch.
Merge branch 'jc/fetch'
* jc/fetch:
fetch: exit non-zero when fast-forward check fails.
* jc/fetch:
fetch: exit non-zero when fast-forward check fails.
send-email: Identify author at the top when sending e-mail
git-send-email did not check if the sender is the same as the
patch author. Follow the "From: at the beginning" convention to
propagate the patch author correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-send-email did not check if the sender is the same as the
patch author. Follow the "From: at the beginning" convention to
propagate the patch author correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
sha1_name: make core.warnambiguousrefs the default.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
sha1_name: warning ambiguous refs.
This makes sure that many commands that take refs on the command
line to honor core.warnambiguousrefs configuration. Earlier,
the commands affected by this patch did not read the
configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes sure that many commands that take refs on the command
line to honor core.warnambiguousrefs configuration. Earlier,
the commands affected by this patch did not read the
configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Format tweaks for asciidoc.
Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/pull' into next
* jc/pull:
git-pull: reword "impossible to fast-forward" message.
git-pull: further safety while on tracking branch.
* jc/pull:
git-pull: reword "impossible to fast-forward" message.
git-pull: further safety while on tracking branch.
git-pull: reword "impossible to fast-forward" message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-pull: further safety while on tracking branch.
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/revlist' into next
* jc/revlist:
rev-list --timestamp
git-apply: do not barf when updating an originally empty file.
http-push.c: squelch C90 warnings.
fix field width/precision warnings in blame.c
* jc/revlist:
rev-list --timestamp
git-apply: do not barf when updating an originally empty file.
http-push.c: squelch C90 warnings.
fix field width/precision warnings in blame.c
Merge branch 'jc/clone' into next
* jc/clone:
git-clone: typofix.
* jc/clone:
git-clone: typofix.
git-clone: typofix.
The traditional one created refs/origin by mistake, not
refs/heads/origin. Also it mistakenly failed to prevent
$origin from being listed twice in remotes/origin file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The traditional one created refs/origin by mistake, not
refs/heads/origin. Also it mistakenly failed to prevent
$origin from being listed twice in remotes/origin file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev-list --timestamp
This prefixes the raw commit timestamp to the output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This prefixes the raw commit timestamp to the output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply: do not barf when updating an originally empty file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
http-push.c: squelch C90 warnings.
If you write code after declarations in a block, gcc scolds you
with "warning: ISO C90 forbids mixed declarations and code".
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you write code after declarations in a block, gcc scolds you
with "warning: ISO C90 forbids mixed declarations and code".
Signed-off-by: Junio C Hamano <junkio@cox.net>
fix field width/precision warnings in blame.c
Using "size_t" values for printf field width/precision upsets gcc, it
wants to see an "int".
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using "size_t" values for printf field width/precision upsets gcc, it
wants to see an "int".
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitk: Fix two bugs reported by users
The first was a simple typo where I put $yc instead of [yc $row].
The second was that I broke the logic for keeping up with fast
movement through the commits, e.g. when you select a commit and then
press down-arrow and let it autorepeat. That got broken when I
changed the merge diff display to use git-diff-tree --cc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The first was a simple typo where I put $yc instead of [yc $row].
The second was that I broke the logic for keeping up with fast
movement through the commits, e.g. when you select a commit and then
press down-arrow and let it autorepeat. That got broken when I
changed the merge diff display to use git-diff-tree --cc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'jc/clone' into next
* jc/clone:
clone: record the remote primary branch with remotes/$origin/HEAD
* jc/clone:
clone: record the remote primary branch with remotes/$origin/HEAD
Merge branch 'jc/name' into next
* jc/name:
get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
* jc/name:
get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
clone: record the remote primary branch with remotes/$origin/HEAD
This matches c51d13692d4e451c755dd7da3521c5db395df192 commit to
record the primary branch of the remote with a symbolic ref
remotes/$origin/HEAD. The user can later change it to point at
different branch to change the meaning of "$origin" shorthand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This matches c51d13692d4e451c755dd7da3521c5db395df192 commit to
record the primary branch of the remote with a symbolic ref
remotes/$origin/HEAD. The user can later change it to point at
different branch to change the meaning of "$origin" shorthand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote. clone needs to be
told about this convention as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote. clone needs to be
told about this convention as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/name' into next
* jc/name:
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
contrib/git-svn: allow rebuild to work on non-linear remote heads
http-push: don't assume char is signed
http-push: add support for deleting remote branches
Be verbose when !initial commit
Fix multi-paragraph list items in OPTIONS section
http-fetch: nicer warning for a server with unreliable 404 status
* jc/name:
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
contrib/git-svn: allow rebuild to work on non-linear remote heads
http-push: don't assume char is signed
http-push: add support for deleting remote branches
Be verbose when !initial commit
Fix multi-paragraph list items in OPTIONS section
http-fetch: nicer warning for a server with unreliable 404 status
Merge branch 'jc/clone' into next
* jc/clone:
revamp git-clone (take #2).
* jc/clone:
revamp git-clone (take #2).
revamp git-clone (take #2).
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: allow rebuild to work on non-linear remote heads
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
http-push: don't assume char is signed
Declare remote_dir_exists[] as signed char to be sure that values of -1
are valid.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Declare remote_dir_exists[] as signed char to be sure that values of -1
are valid.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
http-push: add support for deleting remote branches
Processes new command-line arguments -d and -D to remove a remote branch
if the following conditions are met:
- one branch name is present on the command line
- the specified branch name matches exactly one remote branch name
- the remote HEAD is a symref
- the specified branch is not the remote HEAD
- the remote HEAD resolves to an object that exists locally (-d only)
- the specified branch resolves to an object that exists locally (-d only)
- the specified branch is an ancestor of the remote HEAD (-d only)
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Processes new command-line arguments -d and -D to remove a remote branch
if the following conditions are met:
- one branch name is present on the command line
- the specified branch name matches exactly one remote branch name
- the remote HEAD is a symref
- the specified branch is not the remote HEAD
- the remote HEAD resolves to an object that exists locally (-d only)
- the specified branch resolves to an object that exists locally (-d only)
- the specified branch is an ancestor of the remote HEAD (-d only)
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Be verbose when !initial commit
verbose option in git-commit.sh lead us to run git-diff-index, which
needs a commit-ish we are making diff against. When we are commiting
the fist set, we obviously don't have any commit-ish in the repo. So
we just skip the git-diff-index run.
It might be possible to produce diff against empty but do we need
that?
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
verbose option in git-commit.sh lead us to run git-diff-index, which
needs a commit-ish we are making diff against. When we are commiting
the fist set, we obviously don't have any commit-ish in the repo. So
we just skip the git-diff-index run.
It might be possible to produce diff against empty but do we need
that?
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix multi-paragraph list items in OPTIONS section
This patch makes the html docs right, makes the asciidoc docs a bit odd
but consistent with what is there already, and makes the manpages look
OK using docbook-xsl 1.68, but miss a paragraph separator when using 1.69.
For the manpages, current is like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT
With this patch, docbook-xsl v1.68 looks like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
while docbook-xsl v1.69 becomes
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
The extra indentation is to keep the v1.69 manpage looking sane.
This patch makes the html docs right, makes the asciidoc docs a bit odd
but consistent with what is there already, and makes the manpages look
OK using docbook-xsl 1.68, but miss a paragraph separator when using 1.69.
For the manpages, current is like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT
With this patch, docbook-xsl v1.68 looks like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
while docbook-xsl v1.69 becomes
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
The extra indentation is to keep the v1.69 manpage looking sane.
http-fetch: nicer warning for a server with unreliable 404 status
When a repository otherwise properly prepared is served by a
dumb HTTP server that sends "No such page" output with 200
status for human consumption to a request for a page that does
not exist, the users will get an alarming "File X corrupt" error
message. Hint that they might be dealing with such a server at
the end and suggest running fsck-objects to check if the result
is OK (the pack-fallback code does the right thing in this case
so unless a loose object file was actually corrupt the result
should check OK).
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a repository otherwise properly prepared is served by a
dumb HTTP server that sends "No such page" output with 200
status for human consumption to a request for a page that does
not exist, the users will get an alarming "File X corrupt" error
message. Hint that they might be dealing with such a server at
the end and suggest running fsck-objects to check if the result
is OK (the pack-fallback code does the right thing in this case
so unless a loose object file was actually corrupt the result
should check OK).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/merge' into next
* jc/merge:
git-merge knows some strategies want to skip trivial merges
generate-cmdlist: style cleanups.
Add missing semicolon to sed command.
unpack_delta_entry(): reduce memory footprint.
git.el: Added a function to diff against the other heads in a merge.
git.el: Get the default user name and email from the repository config.
git.el: More robust handling of subprocess errors when returning strings.
* jc/merge:
git-merge knows some strategies want to skip trivial merges
generate-cmdlist: style cleanups.
Add missing semicolon to sed command.
unpack_delta_entry(): reduce memory footprint.
git.el: Added a function to diff against the other heads in a merge.
git.el: Get the default user name and email from the repository config.
git.el: More robust handling of subprocess errors when returning strings.
Merge branch 'jc/clone' into next
* jc/clone:
revamp git-clone.
* jc/clone:
revamp git-clone.
git-merge knows some strategies want to skip trivial merges
Most notably "ours". Also this makes sure we do not record
duplicated parents on the parent list of the resulting commit.
This is based on Mark Wooding's work, but does not change the UI
nor introduce new flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most notably "ours". Also this makes sure we do not record
duplicated parents on the parent list of the resulting commit.
This is based on Mark Wooding's work, but does not change the UI
nor introduce new flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
revamp git-clone.
This does two things.
* A new flag --reference can be used to name a local repository
that is to be used as an alternate. This is in response to
an inquiry by James Cloos in the message on the list
<m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>.
* A new flag --use-separate-remote stops contaminating local
branch namespace by upstream branch names. The upstream
branch heads are copied in .git/refs/remotes/ instead of
.git/refs/heads/ and .git/remotes/origin file is set up to
reflect this as well. It requires to have fetch/pull update
to understand .git/refs/remotes by Eric Wong to further
update the repository cloned this way.
For the former change, git-fetch-pack is taught a new flag --all
to fetch from all the remote heads. Nobody uses the git-clone-pack
with this change, so we could deprecate the command, but removal
of the command will be left to a separate round.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does two things.
* A new flag --reference can be used to name a local repository
that is to be used as an alternate. This is in response to
an inquiry by James Cloos in the message on the list
<m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>.
* A new flag --use-separate-remote stops contaminating local
branch namespace by upstream branch names. The upstream
branch heads are copied in .git/refs/remotes/ instead of
.git/refs/heads/ and .git/remotes/origin file is set up to
reflect this as well. It requires to have fetch/pull update
to understand .git/refs/remotes by Eric Wong to further
update the repository cloned this way.
For the former change, git-fetch-pack is taught a new flag --all
to fetch from all the remote heads. Nobody uses the git-clone-pack
with this change, so we could deprecate the command, but removal
of the command will be left to a separate round.
Signed-off-by: Junio C Hamano <junkio@cox.net>
generate-cmdlist: style cleanups.
Instead of giving multiple commands concatenated with semicolon
to sed, write them on separate lines.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of giving multiple commands concatenated with semicolon
to sed, write them on separate lines.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add missing semicolon to sed command.
generate-cmdlist.sh is giving errors messages from sed on Mac OS
10.4 due to a missing semicolon.
Signed-off-by: Junio C Hamano <junkio@cox.net>
generate-cmdlist.sh is giving errors messages from sed on Mac OS
10.4 due to a missing semicolon.
Signed-off-by: Junio C Hamano <junkio@cox.net>
unpack_delta_entry(): reduce memory footprint.
Currently we unpack the delta data from the pack and then unpack
the base object to apply that delta data to it. When getting an
object that is deeply deltified, we can reduce memory footprint
by unpacking the base object first and then unpacking the delta
data, because we will need to keep at most one delta data in
memory that way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently we unpack the delta data from the pack and then unpack
the base object to apply that delta data to it. When getting an
object that is deeply deltified, we can reduce memory footprint
by unpacking the base object first and then unpacking the delta
data, because we will need to keep at most one delta data in
memory that way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git.el: Added a function to diff against the other heads in a merge.
git-diff-file-merge-head generates a diff against the first merge
head, or with a prefix argument against the nth head. Bound to `d h'
by default.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff-file-merge-head generates a diff against the first merge
head, or with a prefix argument against the nth head. Bound to `d h'
by default.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git.el: Get the default user name and email from the repository config.
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git.el: More robust handling of subprocess errors when returning strings.
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'master' into next
* master:
Makefile: Add TAGS and tags targets
ls-files: Don't require exclude files to end with a newline.
* master:
Makefile: Add TAGS and tags targets
ls-files: Don't require exclude files to end with a newline.
Makefile: Add TAGS and tags targets
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
ls-files: Don't require exclude files to end with a newline.
Without this patch, the last line of an exclude file is silently
ignored if it doesn't end with a newline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this patch, the last line of an exclude file is silently
ignored if it doesn't end with a newline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitk: Improve appearance of first child links
The point where the line for a parent joins to the first child
shown is visually different from the lines to the other children,
because the line doesn't branch, but terminates at the child.
Because of this, we now treat the first child a little differently
in the optimizer, and we draw its link in drawlineseg rather
than drawparentlinks. This improves the appearance of the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The point where the line for a parent joins to the first child
shown is visually different from the lines to the other children,
because the line doesn't branch, but terminates at the child.
Because of this, we now treat the first child a little differently
in the optimizer, and we draw its link in drawlineseg rather
than drawparentlinks. This improves the appearance of the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'master' into next
* master:
git-pull: run repo-config with dash form.
* master:
git-pull: run repo-config with dash form.
git-pull: run repo-config with dash form.
... as discussed on the list for consistency.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... as discussed on the list for consistency.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/cvsimport' into next
* jc/cvsimport:
cvsimport: fix reading from rev-parse
* jc/cvsimport:
cvsimport: fix reading from rev-parse
cvsimport: fix reading from rev-parse
The updated code reads the tip of the current branch before and
after the import runs, but forgot to chomp what we read from the
command. The read-tree command did not them with the trailing
LF.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The updated code reads the tip of the current branch before and
after the import runs, but forgot to chomp what we read from the
command. The read-tree command did not them with the trailing
LF.
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitk: Make downward-pointing arrows end in vertical line segment
It seems Tk 8.4 can't draw arrows on diagonal line segments. This
adds code to the optimizer to make the last bit of a line go vertically
before being terminated with an arrow pointing downwards, so that
it will be drawn correctly by Tk 8.4.
Signed-off-by: Paul Mackerras <paulus@samba.org>
It seems Tk 8.4 can't draw arrows on diagonal line segments. This
adds code to the optimizer to make the last bit of a line go vertically
before being terminated with an arrow pointing downwards, so that
it will be drawn correctly by Tk 8.4.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'jc/empty'
* jc/empty:
revision traversal: --remove-empty fix (take #2).
revision traversal: --remove-empty fix.
Conflicts:
revision.c (adjust for the updates by Fredrik)
* jc/empty:
revision traversal: --remove-empty fix (take #2).
revision traversal: --remove-empty fix.
Conflicts:
revision.c (adjust for the updates by Fredrik)
gitk: Don't change cursor at end of layout if find in progress
If the user is doing a find in files or patches, which changed the
cursor to a watch, don't change it back to a pointer when we reach
the end of laying out the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If the user is doing a find in files or patches, which changed the
cursor to a watch, don't change it back to a pointer when we reach
the end of laying out the graph.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'master' into next
* master:
3% tighter packs for free
Rewrite synopsis to clarify the two primary uses of git-checkout.
Fix minor typo.
Reference git-commit-tree for env vars.
Clarify git-rebase example commands.
Document the default source of template files.
Call out the two different uses of git-branch and fix a typo.
Add git-show reference
* master:
3% tighter packs for free
Rewrite synopsis to clarify the two primary uses of git-checkout.
Fix minor typo.
Reference git-commit-tree for env vars.
Clarify git-rebase example commands.
Document the default source of template files.
Call out the two different uses of git-branch and fix a typo.
Add git-show reference