<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/git.git, branch v1.4.4.4</title>
<subtitle>Git
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/git.git/atom?h=v1.4.4.4</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/atom?h=v1.4.4.4'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/'/>
<updated>2007-01-05T06:17:59Z</updated>
<entry>
<title>pack-check.c::verify_packfile(): don't run SHA-1 update on huge data</title>
<updated>2007-01-05T06:17:59Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2007-01-04T07:09:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=8977c110b5bbd230c28c727ddb85856067d55cfb'/>
<id>urn:sha1:8977c110b5bbd230c28c727ddb85856067d55cfb</id>
<content type='text'>
Running the SHA1_Update() on the whole packfile in a single call
revealed an overflow problem we had in the SHA-1 implementation
on POWER architecture some time ago, which was fixed with commit
b47f509b (June 19, 2006).  Other SHA-1 implementations may have
a similar problem.

The sliding mmap() series already makes chunked calls to
SHA1_Update(), so this patch itself will become moot when it
graduates to "master", but in the meantime, run the hash
function in smaller chunks to prevent possible future problems.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>Fix infinite loop when deleting multiple packed refs.</title>
<updated>2007-01-03T09:22:35Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2007-01-02T19:19:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=1084b845d9d77bcb2e8255636358dd0dc35360a5'/>
<id>urn:sha1:1084b845d9d77bcb2e8255636358dd0dc35360a5</id>
<content type='text'>
It was stupid to link the same element twice to lock_file_list
and end up in a loop, so we certainly need a fix.

But it is not like we are taking a lock on multiple files in
this case.  It is just that we leave the linked element on the
list even after commit_lock_file() successfully removes the
cruft.

We cannot remove the list element in commit_lock_file(); if we
are interrupted in the middle of list manipulation, the call to
remove_lock_file_on_signal() will happen with a broken list
structure pointed by lock_file_list, which would cause the cruft
to remain, so not removing the list element is the right thing
to do.  Instead we should be reusing the element already on the
list.

There is already a code for that in lock_file() function in
lockfile.c.  The code checks lk-&gt;next and the element is linked
only when it is not already on the list -- which is incorrect
for the last element on the list (which has NULL in its next
field), but if you read the check as "is this element already on
the list?" it actually makes sense.  We do not want to link it
on the list again, nor we would want to set up signal/atexit
over and over.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>diff --check: fix off by one error</title>
<updated>2006-12-22T04:31:14Z</updated>
<author>
<name>Johannes Schindelin</name>
<email>Johannes.Schindelin@gmx.de</email>
</author>
<published>2006-12-22T02:20:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=e6d40d65df07059fc655fabe62fa5b575ead7815'/>
<id>urn:sha1:e6d40d65df07059fc655fabe62fa5b575ead7815</id>
<content type='text'>
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.

Signed-off-by: Johannes Schindelin &lt;johannes.schindelin@gmx.de&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>spurious .sp in manpages</title>
<updated>2006-12-20T21:43:03Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2006-12-13T08:58:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=ec722203ee43beed8e4feac84af4307eb68f1ba3'/>
<id>urn:sha1:ec722203ee43beed8e4feac84af4307eb68f1ba3</id>
<content type='text'>
This cherry-picks 7ef04350 that has been applied to the 'master'
to fix ".sp" in generated manpages.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>GIT 1.4.4.3</title>
<updated>2006-12-20T19:23:22Z</updated>
<author>
<name>Junio C Hamano</name>
<email>junkio@cox.net</email>
</author>
<published>2006-12-20T19:23:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=851a911024481f6759bce337b8dc50241070db81'/>
<id>urn:sha1:851a911024481f6759bce337b8dc50241070db81</id>
<content type='text'>
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>Bypass expensive content comparsion during rename detection.</title>
<updated>2006-12-14T10:40:33Z</updated>
<author>
<name>Shawn O. Pearce</name>
<email>spearce@spearce.org</email>
</author>
<published>2006-12-14T10:07:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=7da41f48c8acea834e8204917fe59da2b975903b'/>
<id>urn:sha1:7da41f48c8acea834e8204917fe59da2b975903b</id>
<content type='text'>
When comparing file contents during the second loop through a rename
detection attempt we can skip the expensive byte-by-byte comparsion
if both source and destination files have valid SHA1 values.  This
improves performance by avoiding either an expensive open/mmap to
read the working tree copy, or an expensive inflate of a blob object.

Unfortunately we still have to at least initialize the sizes of the
source and destination files even if the SHA1 values don't match.
Failing to initialize the sizes causes a number of test cases to fail
and start reporting different copy/rename behavior than was expected.

Signed-off-by: Shawn O. Pearce &lt;spearce@spearce.org&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>git-svn: correctly display fatal() error messages</title>
<updated>2006-12-13T09:51:35Z</updated>
<author>
<name>Eric Wong</name>
<email>normalperson@yhbt.net</email>
</author>
<published>2006-12-12T22:47:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=155bd0ce23144e5c7067965a22646523f1a38b51'/>
<id>urn:sha1:155bd0ce23144e5c7067965a22646523f1a38b51</id>
<content type='text'>
If I wanted to print $@, I'd pass $@ to fatal().  This looks like
a stupid typo on my part.

Signed-off-by: Eric Wong &lt;normalperson@yhbt.net&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>git-svn: exit with status 1 for test failures</title>
<updated>2006-12-13T09:48:44Z</updated>
<author>
<name>Eric Wong</name>
<email>normalperson@yhbt.net</email>
</author>
<published>2006-11-25T06:38:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=b42a044f5942c64bbc94aa2f4637d8290748e634'/>
<id>urn:sha1:b42a044f5942c64bbc94aa2f4637d8290748e634</id>
<content type='text'>
Some versions of the SVN libraries cause die() to exit with 255,
and 40cf043389ef4cdf3e56e7c4268d6f302e387fa0 tightened up
test_expect_failure to reject return values &gt;128.

Signed-off-by: Eric Wong &lt;normalperson@yhbt.net&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>Clarify fetch error for missing objects.</title>
<updated>2006-12-13T01:04:40Z</updated>
<author>
<name>Alex Riesen</name>
<email>raa.lkml@gmail.com</email>
</author>
<published>2006-12-12T17:34:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=0d7a6e4ef9e2dc458a9a56ab73638d97f4e75d87'/>
<id>urn:sha1:0d7a6e4ef9e2dc458a9a56ab73638d97f4e75d87</id>
<content type='text'>
Otherwise there're such things like:

    Cannot obtain needed none 9a6e87b60dbd2305c95cecce7d9d60f849a0658d
    while processing commit 0000000000000000000000000000000000000000.

which while looks weird. What is the none needed for?

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>Move Fink and Ports check to after config file</title>
<updated>2006-12-12T22:48:25Z</updated>
<author>
<name>Brian Gernhardt</name>
<email>benji@silverinsanity.com</email>
</author>
<published>2006-12-12T17:01:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/git.git/commit/?id=59f867400650b39568e4a7f96bd60f3a0072dbda'/>
<id>urn:sha1:59f867400650b39568e4a7f96bd60f3a0072dbda</id>
<content type='text'>
Putting NO_FINK or NO_DARWIN_PORTS in config.mak is ignored because the
checks are done before the config is included.

Signed-off-by: Brian Gernhardt &lt;benji@silverinsanity.com&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
</feed>
