is not a release with new features (upcoming 1.7.9 is expected to be
released late January next year to include the pulling of signed tags and
other goodies).
Please upgrade to get the accumulated bugfixes since 1.7.8 release from:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
198e23e6e50245331590a6159ccdbdbe1792422c git-1.7.8.1.tar.gz
8f674dba39d9ae78928abfe9d924b0855e283e98 git-htmldocs-1.7.8.1.tar.gz
b49ce0b4da4f85671693c9b2c6f6a8b8ee65c809 git-manpages-1.7.8.1.tar.gz
- In some codepaths (notably, checkout and merge), the ignore patterns recorded in $GIT_DIR/info/exclude were not honored. They now are.
- "git apply --check" did not error out when given an empty input without any patch.
- "git archive" mistakenly allowed remote clients to ask for commits that are not at the tip of any ref.
- "git checkout" and "git merge" treated in-tree .gitignore and exclude file in $GIT_DIR/info/ directory inconsistently when deciding which untracked files are ignored and expendable.
- LF-to-CRLF streaming filter used when checking out a large-ish blob fell into an infinite loop with a rare input.
- The function header pattern for files with "diff=cpp" attribute did not consider "type *funcname(type param1,..." as the beginning of a function.
- The error message from "git diff" and "git status" when they fail to inspect changes in submodules did not report which submodule they had trouble with.
- After fetching from a remote that has very long refname, the reporting output could have corrupted by overrunning a static buffer.
- "git pack-objects" avoids creating cyclic dependencies among deltas when seeing a broken packfile that records the same object in both the deflated form and as a delta.
"LF-to-CRLF streaming filter used when checking out a large-ish blob fell into an infinite loop with a rare input."
ReplyDeleteThe input required isn't that rare; a file gets one lottery ticket for each full 16K of size, and the odds for "winning" depend on the average line length.
A quick look at the current git repository for git gives ~100 files that are large enough, for a total of ~200 tickets and an average line-length of ~26 characters, which in turn gives that probably ~200/27 ≃ 7 files are affected.
Heh, thanks for doing the math for me. I was being lazy ;-)
ReplyDelete:-)
ReplyDeleteI admit that my original input was more rare; 7 large files with a total of ~52 tickets, and the same average line-length of ~26 characters gives an expected hit-rate of almost 2, so it wasn't so strange that I got bitten.
I believe the main reason why I was the first to trigger the bug (or at least the first to report it), is that use of gitattributes is still rare, and use of eol=crlf is rarer still. Not to mention that the bug is relatively recent.