block-sha1: avoid pointer conversion that violates alignment constraints
With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
access 32-bit chunks of memory one byte at a time on arches that
prefer that:
The code previously accessed these values by just using htonl(*p).
Unfortunately, Michael noticed on an Alpha machine that git was using
plain 32-bit reads anyway. As soon as we convert a pointer to int *,
the compiler can assume that the object pointed to is correctly
aligned as an int (C99 section 6.3.2.3 "pointer conversions"
paragraph 7), and gcc takes full advantage by using a single 32-bit
load, resulting in a whole bunch of unaligned access traps.
So we need to obey the alignment constraints even when only dealing
with pointers instead of actual values. Do so by changing the type
of 'data' to void *. This patch renames 'data' to 'block' at the same
time to make sure all references are updated to reflect the new type.
Reported-tested-and-explained-by: Michael Cree <mcree@orcon.net.nz> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We rely on ntohl() and htonl() to perform byte swapping in many places.
However, some platforms have libraries providing really poor
implementations of those which might cause significant performance
issues, especially with the block-sha1 code.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1/sha1.c: silence compiler complaints by casting void * to char *
Some compilers produce errors when arithmetic is attempted on pointers to
void. We want computations done on byte addresses, so cast them to char *
to work them around.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1: support for architectures with memory alignment restrictions
This is needed on architectures with poor or non-existent unaligned memory
support and/or no fast byte swap instruction (such as ARM) by using byte
accesses to memory and shifting the result together.
This also makes the code portable, therefore the byte access methods are
the defaults. Any architecture that properly supports unaligned word
accesses in hardware simply has to enable the alternative methods.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1: split the different "hacks" to be individually selected
This is to make it easier for them to be selected individually depending
on the architecture instead of the other way around i.e. having each
architecture select a list of hacks up front. That makes for clearer
documentation as well.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1: improve code on large-register-set machines
For x86 performance (especially in 32-bit mode) I added that hack to write
the SHA1 internal temporary hash using a volatile pointer, in order to get
gcc to not try to cache the array contents. Because gcc will do all the
wrong things, and then spill things in insane random ways.
But on architectures like PPC, where you have 32 registers, it's actually
perfectly reasonable to put the whole temporary array[] into the register
set, and gcc can do so.
So make the 'volatile unsigned int *' cast be dependent on a
SMALL_REGISTER_SET preprocessor symbol, and enable it (currently) on just
x86 and x86-64. With that, the routine is fairly reasonable even when
compared to the hand-scheduled PPC version. Ben Herrenschmidt reports on
a G5:
* Paulus asm version: about 3.67s
* Yours with no change: about 5.74s
* Yours without "volatile": about 3.78s
so with this the C version is within about 3% of the asm one.
And add a lot of commentary on what the heck is going on.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
notice? I outperform all the hand-tuned asm on 32-bit too. By quite a
margin, in fact.
Now, I didn't try a P4, and it's possible that it won't do that there, but
the 32-bit code generation sure looks impressive on my Nehalem box. The
magic? I force the stores to the 512-bit hash bucket to be done in order.
That seems to help a lot.
The diff is trivial (on top of the "rename registers with cpp" patch), as
appended. And it does seem to fix the P4 issues too, although I can
obviously (once again) only test Prescott, and only in 64-bit mode:
We now count the size in bytes, which means that 'lenW' was always just
the low 6 bits of the total size, so we don't carry it around separately
any more. And we do the 'size in bits' shift at the end.
Suggested by Nicolas Pitre and linux@horizon.com.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1: Use '(B&C)+(D&(B^C))' instead of '(B&C)|(D&(B|C))' in round 3
It's an equivalent expression, but the '+' gives us some freedom in
instruction selection (for example, we can use 'lea' rather than 'add'),
and associates with the other additions around it to give some minor
scheduling freedom.
Suggested-by: linux@horizon.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
block-sha1: re-use the temporary array as we calculate the SHA1
The mozilla-SHA1 code did this 80-word array for the 80 iterations. But
the SHA1 state is really just 512 bits, and you can actually keep it in
a kind of "circular queue" of just 16 words instead.
This requires us to do the xor updates as we go along (rather than as a
pre-phase), but that's really what we want to do anyway.
This gets me really close to the OpenSSL performance on my Nehalem.
Look ma, all C code (ok, there's the rol/ror hack, but that one doesn't
strictly even matter on my Nehalem, it's just a local optimization).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bert Wesarg noticed non-x86 version of SHA_ROT() had a typo.
Also spell in-line assembly as __asm__(), otherwise I seem to get
error: implicit declaration of function 'asm' from my compiler.
Use the one with the smaller constant. It _can_ generate slightly
smaller code (a constant of 1 is special), but perhaps more importantly
it's possibly faster on any uarch that does a rotate with a loop.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Undo the change I picked up from the mailing list discussion suggested
by Nico, not because it is wrong, but it will be done at the end of the
follow-up series.
* sb/parse-options:
prune-packed: migrate to parse-options
verify-pack: migrate to parse-options
verify-tag: migrate to parse-options
write-tree: migrate to parse-options
git-merge-base/git-show-branch --merge-base: Documentation and test
Currently, the documentation suggests that 'git merge-base -a' and 'git
show-branch --merge-base' are equivalent (in fact it claims that the
former cannot handle more than two revs).
Alas, the handling of more than two revs is very different. Document
this by tests and correct the documentation to reflect this.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Importing the popen2 module in Python-2.6 results in the
"DeprecationWarning: The popen2 module is deprecated. Use the
subprocess module." message. The module itself isn't used in fact, so
just removing it solves the problem.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: fix 'Use of uninitialized value' error in href()
Equality between file_parent and file_name was being checked without a
preliminary check for existence of the parameters.
Fix by wrapping the equality check in appropriate if (defined ...),
rearranging the lines to prevent excessive length.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: git-send-email: correct statement about standard ports
The current documentation states that servers typically listen on port
465 and calls this "ssmtp". While it's true that many mail servers use
port 465 for SSL smtp, this is non-standard, and hails from the days
before smtp and submission TLS support, that arrived in RFC2487 and
RFC3207. Port 465 is actually assigned by IANA for unrelated purposes,
and is mostly still used by mail servers today only to support Outlook
Express.
In any case, this patch helps the documentation better reflect both
standards and reality, while still helpfully mentioning ports numbers
that a user may wish to specify.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.
Reported-by: John te Bokkel <tanj.tanj@gmail.com> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git fast-export and git fast-import to rewrite the history
of a repository with large binary files, almost all of the time is
spent dealing with blobs. This is extremely inefficient if all we want
to do is rewrite the commits and tree structure. --no-data skips the
output of blobs and writes SHA-1s instead of marks, which provides a
massive speedup.
Signed-off-by: Geoffrey Irving <irving@naml.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is usually better to have positive options, to avoid confusing double
negations. However, sometimes it is desirable to show the negative option
in the help.
Introduce the flag PARSE_OPT_NEGHELP to do that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* hv/cvsps-tests:
t/t9600: remove exit after test_done
cvsimport: extend testcase about patchset order to contain branches
cvsimport: add test illustrating a bug in cvsps
Add a test of "git cvsimport"'s handling of tags and branches
Add some tests of git-cvsimport's handling of vendor branches
Test contents of entire cvsimported "master" tree contents
Use CVS's -f option if available (ignore user's ~/.cvsrc file)
Start a library for cvsimport-related tests
Add a reminder test case for a merge with F/D transition
The problem is that if a file was replaced with a directory containing
another file with the same content and mode, an attempt to merge it
with a branch descended from a commit before this F->D transition will
cause merge-recursive to break. It breaks even if there were no
conflicting changes on that other branch.
Originally reported by Anders Melchiorsen.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The next major release will be 1.6.5, hopefully with a shorter cycle
than the 1.6.4 cycle. After that in 1.7.0 we can make potentially
backward incompatible changes if necessary.
request-pull: allow ls-remote to notice remote.$nickname.uploadpack
The location to pull from should be converted from the configured nickname
to URL in the message, but ls-remote should be fed the nickname so that
the command uses remote.$nickname.* variables, most notably "uploadpack".
Signed-off-by: Tom Grennan <tgrennan@redback.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rerere.txt: Clarify ambiguity of the config variable
Use the less ambiguous
"set variable foo in order to enable bar"
rather than
"set variable foo to enable bar" which may trick users into
assuming that "enable" is a good value for "foo".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git svn gc" will not compress unhandled.log files if
Compress::Zlib is missing. However, leftover index files should
always be removed, so add a test for this behavior as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* en/fast-export:
fast-export: Document the fact that git-rev-list arguments are accepted
Add new fast-export testcases
fast-export: Add a --tag-of-filtered-object option for newly dangling tags
fast-export: Do parent rewriting to avoid dropping relevant commits
fast-export: Make sure we show actual ref names instead of "(null)"
fast-export: Omit tags that tag trees
fast-export: Set revs.topo_order before calling setup_revisions
* git://git.bogomips.org/git-svn:
git svn: make minimize URL more reliable over http(s)
git svn: avoid escaping '/' when renaming/copying files
t9142: stop httpd after the test
git svn: the branch command no longer needs the full path
git svn: revert default behavior for --minimize-url
git svn: add gc command
git svn: make minimize URL more reliable over http(s)
In addition to path-based restrictions, Subversion servers over
http(s) may have access controls implemented via the LimitExcept
directive in Apache. In some cases, LimitExcept may be
(arguably) misconfigured to not allow REPORT requests while
allowing OPTIONS and PROPFIND.
This caused problems with our existing minimize_url logic that
only issued OPTIONS and PROPFIND requests when connecting and
using SVN::Ra::get_latest_revnum. We now call SVN::Ra::get_log
if get_latest_revnum succeeds, resulting in a REPORT request
being sent. This will increase our chances of tripping access
controls before we start attempting to fetch history.
Disable asciidoc 8.4.1+ semantics for `{plus}` and friends
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn: avoid escaping '/' when renaming/copying files
Timothy Schaeffer reported the following:
> Git-svn has been giving me the following error for some time
> when calling "git svn dcommit":
>
> RA layer request failed: PROPFIND request failed on
> '/svn/stf/branches/dev/sw%2Fdpemu%2Finclude%2FNetCnxn.h': PROPFIND of
> '/svn/stf/branches/dev/sw%2Fdpemu%2Finclude%2FNetCnxn.h': 302 Found
> (https://oursvnrepo.net) at /usr/local/libexec/git-core/git-svn line 508
>
> This only occurred when git detected a rename or copy.
>
> Following the lead into git-svn.perl,
> and noticing that some of the '/'s in the path were hex-encoded
> and some were not,
> I changed the regex used to find chars
> to hex-encode in the relative part of the path
> to exclude '/'.
> It works, so far.
> I have included a patch.
While this has previous not been a problem in my experience,
newer versions of SVN may be stricter and this does not
introduce regressions in t9115.
git svn: the branch command no longer needs the full path
This was introduced in 0b2af457a49e3b00d47d556d5301934d27909db8
("Fix branch detection when repository root is inaccessible")
but reintroduced in the previous commit.
git svn: revert default behavior for --minimize-url
This reverts the --minimize-url behavior change that
appeared recently in commit 0b2af457a49e3b00d47d556d5301934d27909db8
("Fix branch detection when repository root is inaccessible").
However, we now allow the option to be turned off by allowing
"--no-minimize-url" so people with limited-access setups can
still take advantage of the fix in 0b2af457a49e3b00d47d556d5301934d27909db8.
Also document the behavior and default settings of minimize-url
in the manpage for the first time.
This introduces a temporary UI regression to allow t9141 to pass
that will be reverted (fixed) in the next commit.
The second and third tests of this script expected that Russian strings
are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain"
format output correctly.
Sure, many platforms may convert between such a combination, but that is
only because one of the base character set of Shift_JIS, JIS X 0208,
defines codepoints for Russian characters (among others); I do not think
anybody uses Shift_JIS when seriously writing Russian, and it is perfectly
understandable if iconv() libraries on some platforms fail converting
between this combination, as it does not matter in reality.
This patch changes the test to verify Japanese strings are converted
correctly between EUC-JP and Shift_JIS in the same procedure. The point
of the test is not about verifying the platform's iconv() library, but to
see if "git blame" makes correct iconv() library calls when it should.
We could instead use ISO-8859-5 and KOI8-R as the combination, because
they are both meant to represent Russian, in order to make this test
meaningful on more platforms, but we already use Shift_JIS vs EUC-JP
combinations to test other programs in our test suite, so this combination
is safer from the point of view of the portability. Besides, I do not
read nor write Russian; sorry ;-)
This change allows tests to pass on my (friend's) Solaris 5.11 box.
* av/maint-config-reader:
After renaming a section, print any trailing variable definitions
Make section_name_match start on '[', and return the length on success
Show the presence of untracked files in the bash prompt.
Added the envvar GIT_PS1_SHOWUNTRACKEDFILES to 'git-completion.bash'.
When set to a nonempty value, then the char '%' will be shown next
to the branch name in the bash prompt.
Signed-off-by: Daniel Trstenjak <daniel.trstenjak@science-computing.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
SunOS grep does not understand -C<n> nor -e
Fix export_marks() error handling.
git branch: clean up detached branch handling
git branch: avoid unnecessary object lookups
git branch: fix performance problem
do_one_ref(): null_sha1 check is not about broken ref
The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc,
and that is not because our way to spawn external grep is broken, but
because the native grep does not understand -C<n>.
It turns out that Peff was also using this option himself because our
Makefile doesn't do that automatically. Brandon Casey uses SUNWspro
compiler without having to set this, and it turns out that the compiler
does not define preprocessor macro __unix__ which made him always use the
built-in grep, never an external one.
Let's be more explicit and say that we do not use external grep on Suns.
When you have grafts that pretend that a given commit has different
parents than the ones recorded in the commit object, it is dangerous
to let 'git repack' remove those hidden parents, as you can easily
remove the graft and end up with a broken repository.
So let's play it safe and keep those parent objects and everything
that is reachable by them, in addition to the grafted parents.
As this behavior can only be triggered by git pack-objects, and as that
command handles duplicate parents gracefully, we do not bother to cull
duplicated parents that may result by using both true and grafted
parents.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test showing that 'git repack' throws away grafted-away parents
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the 'show detached branch info' a routine of its own. And in the
process, avoid the object lookup that is unnecessary if the current
branch isn't detached.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git branch' looks at _all_ the refs, and verifies them. Which means that
during cold-cache situations with a slow disk (and lots of tags, for
example) it can take several very annoying seconds (7.5s according to a
report by Carlos R. Mafra).
This avoids most of it by simply doing the filtering before looking up
the commits, by using the "raw" version of for_each_ref.
Reported-by: Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn: fix shallow clone when upstream revision is too new
Thanks to Ka-Hing Cheung for the initial bug report and patch:
> git-svn uses $ra->get_latest_revnum to find out the latest
> revision, but that can be problematic, because get_latest_revnum
> returns the latest revnum in the entire repository, not
> restricted by whatever URL you used to construct $ra. So if you
> do git svn clone -r HEAD svn://blah/blah/trunk, it won't work if
> the latest checkin is in one of the branches (it will try to
> fetch a rev that doesn't exist in trunk, making the clone
> useless).
Relying on SVN::Core::INVALID_REVNUM (-1) as the "start"
argument to SVN::Ra::get_log() proved unreliable with http(s)
URLs so the result of SVN::Ra::get_latest_revnum() is used as
the "start" argument instead.
do_one_ref(): null_sha1 check is not about broken ref
f8948e2 (remote prune: warn dangling symrefs, 2009-02-08) introduced a
more dangerous variant of for_each_ref() family that skips the check for
dangling refs, but it also made another unrelated check optional by
mistake.
The check to see if a ref points at 0{40} is not about brokenness, but is
about a possible future plan to represent a deleted ref by writing 40 "0"
in a loose ref when there is a stale version of the same ref already in
.git/packed-refs, so that we can implement deletion of a ref without
having to rewrite the packed refs file excluding the ref being deleted.
This check has to live outside of the conditional.
configure.ac: properly unset NEEDS_SSL_WITH_CRYPTO when sha1 func is missing
The empty assignment NEEDS_SSL_WITH_CRYPTO= was mistakenly paired with the
assignment NEEDS_SSL_WITH_CRYPTO=YesPlease in the "action-if-found"
parameter of the AC_CHECK_LIB macro. The empty assignment was intended for
the "action-if-not-found" section, since in that case, the necessary sha1
hash function was not found and the internal sha1 implementation will be
used instead.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>