Re: [Bug] git branch -v has problems with carriage returns
Here is my first attempt at fixing the issue. There are two problems in ref-filter.c: First, copy_subject() has been modified to turn '\n' into a space and every other ascii control character to be ignored. Second, find_subpos() doesn't realize that a line that only contains a '\r\n' is a blank line – at least when using crlf convention. I have changed things so that a sequence of either '\n' or "\r\n" separate the subject from the body of the commit message. I am not looking at the crlf setting because it doesn't seem like a useful distinction – when one would we ever care for \r\n not to be a blank line? But it could be done... Both fixes are minimal, but it feels like they are a issues with the specific encoding. Does git mandate ascii or utf-8 commit messages? If not, there may be a larger issue here with encodings and line-end conventions at the very least in ref-filter.c Guidance would be appreciated for how to deal with this issue... Patch attached. Atousa On Fri, May 19, 2017 at 11:48 PM, Johannes Sixt wrote: > Am 19.05.2017 um 23:55 schrieb Atousa Duprat: >> >> I have tried to repro this issue but git goes out of its way to store >> the commit messages using unix end-of-line format. >> I think that git itself cannot create a repo exhibiting this problem. > > > Here is a recipe to reproduce the error: > > git init > git commit --allow-empty -m initial > git branch crlf $(printf '%s\r\n' subject '' line3_long line4 | >git commit-tree HEAD:) > > The reason for the "bug" is obviously that a line having CR in addition to > LF is not "an empty line". Consequently, the second line is not treated as a > separator between subject and body, whereupon Git concatenates all lines > into one large subject line. This strips the LFs but leaves the CRs in tact, > which, when printed on a terminal move the cursor to the beginning of the > line, so that text after the CRs overwrites what is already in the terminal. > > This is just to give you a head start. I'm not going to look into this. > > -- Hannes > > >>> If I do `git branch -v` with such a subject line somehow the third and >>> second line get combined before the hash. Example: >>> >>> $ git branch -v >>> See merge request ! temp space 84e18d22fd Merge branch >>> 'feature-XXX' into 'develop' >>> # >> third)> >>> >>> Before git v2.13.0 `git branch -v` worked completely normal. branch-crlf.patch Description: Binary data
Re: [Bug] git branch -v has problems with carriage returns
Sorry for the noise with previous response... I have tried to repro this issue but git goes out of its way to store the commit messages using unix end-of-line format. I think that git itself cannot create a repo exhibiting this problem. Most helpful would be if you could create a mini repo using gitlab. All it would need is one file, two branches, and a merge. With that in hand, it should be pretty easy to track down the problem and fix git. You mentioned that the previous version you were using was working fine, can you tell me which version that was? It'll help to narrow down the changes that could have affected the issue. Thanks, Atousa On Tue, May 16, 2017 at 4:22 PM, Animi Vulpis wrote: > Hi, > > I upgraded to git v2.13.0 and since then git branch -v has problems > with carriage returns in subject lines. > > We are using gitlab (not the newest version). So this bug (It's about > carriage returns in auto-generated merge messages (\r\n)) is not yet > fixed in our version: > https://gitlab.com/gitlab-org/gitlab-ce/issues/31671 > That's were the carriage returns are coming from. > > In my specific case the auto-generated merge message has three lines > with empty lines in between. > So every line ends with `\r\n\r\n` > > If I do `git branch -v` with such a subject line somehow the third and > second line get combined before the hash. Example: > > $ git branch -v > See merge request ! temp space 84e18d22fd Merge branch > 'feature-XXX' into 'develop' > # third)> > > Before git v2.13.0 `git branch -v` worked completely normal. > > I was not able to create a minimal local example, because my manually > created \r\n in commit messages were transformed into \n\n > > Please let me know if I can provide any more information that would be > helpful. > > Cheers
Re: Delivery Status Notification (Failure)
Hi, I have tried to repro this issue but git goes out of its way to store the commit messages using unix end-of-line format. I think that git itself cannot create a repo exhibiting this problem. Most helpful would be if you could create a mini repo using gitlab. All it would need is one file, two branches, and a merge. With that in hand, it should be pretty easy to track down the problem and fix git. You mentioned that the previous version you were using was working fine, can you tell me which version that was? It'll help to narrow down the changes that could have affected the issue. Thanks, Atousa
Re: Suspected bug on `git -C rev-list --all` where has 0 commits
I agree with Yac that this error is unwarranted, though it's been like that since forever. If a repo is empty, git rev-list should probably just return without erroring out. The fix is trivial, if the list agrees that this is in fact legit. Atousa On Wed, Nov 11, 2015 at 10:26 AM, yac wrote: > Hello > > basics: > > % rpm -q git git-core > git-2.6.2-2.1.x86_64 > git-core-2.6.2-2.1.x86_64 > > ~ % grep PRETTY_NAME /etc/os-release > PRETTY_NAME="openSUSE Tumbleweed (20151030) (x86_64)" > > current behavior: > > ~ % git init no-commits > Initialized empty Git repository in /home/tester/no-commits/.git/ > ~ % git -C no-commits rev-list --all > usage: git rev-list [OPTION] ... [ -- paths... ] > limiting output: > --max-count= > --max-age= > --min-age= > --sparse > --no-merges > --min-parents= > --no-min-parents > --max-parents= > --no-max-parents > --remove-empty > --all > --branches > --tags > --remotes > --stdin > --quiet > ordering output: > --topo-order > --date-order > --reverse > formatting output: > --parents > --children > --objects | --objects-edge > --unpacked > --header | --pretty > --abbrev= | --no-abbrev > --abbrev-commit > --left-right > --count > special purpose: > --bisect > --bisect-vars > --bisect-all > ~ % echo $? > 129 > > expected behavior: > > ~ % git -C no-commits rev-list --all > ~ % echo $? > 0 > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] Limit the size of the data block passed to SHA1_Update()
> Adjusting to the proposed change to 1/3, this step would become the > attached patch. Note that I thought the above would not scale well > so I did it a bit differently. Thank you, I understand now the changes that you made. Let me know if this can be improved any further. Atousa -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: stash save -u removes (some) ignored files
> felipe@felipe:testgit% git stash save -u
This does the following:
$ GIT_TRACE=1 git stash save -u
[...]
21:59:10.606094 git.c:348 trace: built-in: git 'clean'
'--force' '--quiet' '-d'
git-clean -d removes untracked directories in addition to untracked files.
Should 'git stash save -u' issue a 'git clean -d' or simply a 'git clean'?
Atousa
On Tue, Nov 3, 2015 at 2:37 PM, Felipe Sateler wrote:
> I have seen the following problem:
>
> felipe@felipe:testgit% cat .gitignore
> **/notrack/*
> !**/notrack/track/
> notrackfile**
>
> felipe@felipe:testgit% find *
> newfile
> notrack
> notrack/1
> notrackfile1
>
> felipe@felipe:testgit% git status --porcelain
> ?? newfile
>
> felipe@felipe:testgit% git stash save -u
> Saved working directory and index state WIP on master: 523cb39 Initial commit
> HEAD is now at 523cb39 Initial commit
>
> felipe@felipe:testgit% find *
> notrackfile1
>
> So, after a stash save, git decided to keep the untracked file in the
> current directory, but not the ones inside the untracked directory.
> However, the files were "correctly" ignored and did not appear on the stash:
>
> felipe@felipe:testgit% git stash pop
> Already up-to-date!
> On branch master
> Untracked files:
> (use "git add ..." to include in what will be committed)
>
> newfile
>
> nothing added to commit but untracked files present (use "git add" to track)
> Dropped refs/stash@{0} (e6508f345af1dd207557ad0291e7e3bce8a89b1e)
>
> felipe@felipe:testgit% find *
> newfile
> notrackfile1
>
> I think the correct behaviour should be to left the ignored files
> untouched in both scenarios.
>
> This is with git 2.6.1 (from debian).
>
> I note that if I add a file inside the notrack/track directory, it is
> correctly kept, but the files in notrack/ are still deleted.
>
> --
>
> Saludos,
> Felipe Sateler
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Atousa Pahlevan, PhD
M.Math. University of Waterloo, Canada
Ph.D. Department of Computer Science, University of Victoria, Canada
Voice: 415-341-6206
Email: apahle...@ieee.org
Website: www.apahlevan.org
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Limit the size of the data block passed to SHA1_Update()
Thank you for the feedback. The patch is updated as suggested.
On Tue, Nov 3, 2015 at 3:51 AM, Torsten Bögershausen wrote:
> On 11/03/2015 07:58 AM, atous...@gmail.com wrote:
>>
>> From: Atousa Pahlevan Duprat
>
> Minor comments inline
>>
>> diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
>> index b864df6..d085412 100644
>> --- a/block-sha1/sha1.h
>> +++ b/block-sha1/sha1.h
>> @@ -18,5 +18,5 @@ void blk_SHA1_Final(unsigned char hashout[20],
>> blk_SHA_CTX *ctx);
>> #define git_SHA_CTX blk_SHA_CTX
>> #define git_SHA1_Init blk_SHA1_Init
>> -#define git_SHA1_Updateblk_SHA1_Update
>> +#define platform_SHA1_Update blk_SHA1_Update
>> #define git_SHA1_Finalblk_SHA1_Final
>> diff --git a/cache.h b/cache.h
>> index 79066e5..a501652 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -10,12 +10,21 @@
>> #include "trace.h"
>> #include "string-list.h"
>> +// platform's underlying implementation of SHA1
>
> Please use /* */ for comments
>
>> #include SHA1_HEADER
>> #ifndef git_SHA_CTX
>> -#define git_SHA_CTXSHA_CTX
>> -#define git_SHA1_Init SHA1_Init
>> -#define git_SHA1_UpdateSHA1_Update
>> -#define git_SHA1_Final SHA1_Final
>> +#define git_SHA_CTXSHA_CTX
>> +#define git_SHA1_Init SHA1_Init
>> +#define platform_SHA1_Update SHA1_Update
>> +#define git_SHA1_Final SHA1_Final
>> +#endif
>> +
>> +// choose whether chunked implementation or not
>> +#ifdef SHA1_MAX_BLOCK_SIZE
>> +int git_SHA1_Update_Chunked(SHA_CTX *c, const void *data, size_t len);
>> +#define git_SHA1_Update git_SHA1_Update_Chunked
>> +#else
>> +#define git_SHA1_Update platform_SHA1_Update
>> #endif
>> #include
>> diff --git a/compat/apple-common-crypto.h b/compat/apple-common-crypto.h
>> index c8b9b0e..d3fb264 100644
>> --- a/compat/apple-common-crypto.h
>> +++ b/compat/apple-common-crypto.h
>> @@ -16,6 +16,10 @@
>> #undef TYPE_BOOL
>> #endif
>> +#ifndef SHA1_MAX_BLOCK_SIZE
>> +#error Using Apple Common Crypto library requires setting
>> SHA1_MAX_BLOCK_SIZE
>> +#endif
>> +
>> #ifdef APPLE_LION_OR_NEWER
>> #define git_CC_error_check(pattern, err) \
>> do { \
>> diff --git a/compat/sha1_chunked.c b/compat/sha1_chunked.c
>> new file mode 100644
>> index 000..61f67de
>> --- /dev/null
>> +++ b/compat/sha1_chunked.c
>> @@ -0,0 +1,19 @@
>> +#include "cache.h"
>> +
>> +int git_SHA1_Update_Chunked(SHA_CTX *c, const void *data, size_t len)
>> +{
>> + size_t nr;
>> + size_t total = 0;
>> + const char *cdata = (const char*)data;
>> +
>> + while (len > 0) {
>
> size_t is unsigned, isn't it ?
> Better to use "while (len) {"
>
>> + nr = len;
>> + if (nr > SHA1_MAX_BLOCK_SIZE)
>> + nr = SHA1_MAX_BLOCK_SIZE;
>> + platform_SHA1_Update(c, cdata, nr);
>> + total += nr;
>> + cdata += nr;
>> + len -= nr;
>> + }
>> + return total;
>> +}
>
>
--
Atousa Pahlevan, PhD
M.Math. University of Waterloo, Canada
Ph.D. Department of Computer Science, University of Victoria, Canada
Voice: 415-341-6206
Email: apahle...@ieee.org
Website: www.apahlevan.org
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Limit the size of the data block passed to SHA1_Update()
In the Makefile there is the following: ifdef BLK_SHA1 SHA1_HEADER = "block-sha1/sha1.h" LIB_OBJS += block-sha1/sha1.o else ifdef PPC_SHA1 SHA1_HEADER = "ppc/sha1.h" LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o else ifdef APPLE_COMMON_CRYPTO COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL SHA1_HEADER = SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L else SHA1_HEADER = EXTLIBS += $(LIB_4_CRYPTO) endif which seems to imply that BLK_SHA1 and APPLE_COMMON_CRYPTO are mutually exclusive? On Sun, Nov 1, 2015 at 10:37 AM, Junio C Hamano wrote: > atous...@gmail.com writes: > >> diff --git a/cache.h b/cache.h >> index 79066e5..ec84b16 100644 >> --- a/cache.h >> +++ b/cache.h >> @@ -14,7 +14,12 @@ >> #ifndef git_SHA_CTX >> #define git_SHA_CTX SHA_CTX >> #define git_SHA1_InitSHA1_Init >> -#define git_SHA1_Update SHA1_Update >> +#ifdef SHA1_MAX_BLOCK_SIZE >> +extern int SHA1_Update_Chunked(SHA_CTX *, const void *, size_t); >> +#define git_SHA1_Update SHA1_Update_Chunked >> +#else >> +#define git_SHA1_Update SHA1_Update >> +#endif >> #define git_SHA1_Final SHA1_Final >> #endif > > Hmm, I admit that this mess is my creation, but unfortunately it > does not allow us to say: > > make SHA1_MAX_BLOCK_SIZE='1024L*1024L*1024L' > > when using other SHA-1 implementations (e.g. blk_SHA1_Update()). > > Ideas for cleaning it up, anybody? > -- Atousa Pahlevan, PhD M.Math. University of Waterloo, Canada Ph.D. Department of Computer Science, University of Victoria, Canada Voice: 415-341-6206 Email: apahle...@ieee.org Website: www.apahlevan.org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Limit the size of the data block passed to SHA1_Update()
>> +int git_SHA1_Update(SHA_CTX *c, const void *data, size_t len)
>> +{
>> + size_t nr;
>> + size_t total = 0;
>> + char *cdata = (char*)data;
> I am not sure about the cast
> here, though. Doesn't the function SHA1_Update() you are going to
> call in the body of the loop take "const void *" as its second
> parameter? That's how openssl/sha1.h and block-sha1/sha1.h declare
> this function.
Indeed, the declaration needs a const void *; but I need to advance by
a specific number of bytes in each iteration of the loop. Hence the
cast.
Atousa
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Limit the size of the data block passed to SHA1_Update()
> Didn't we have this same issue with NonStop port about a year ago and > decided to provision this through the configure script? I'll be happy to look at it. Can you point me to the right email thread or location in the configure.ac file? Atousa -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fsck failure on OS X with files >= 4 GiB
Thank you for the feedback. I have revised the proposed patch as
suggested, allowing the use of SHA1_MAX_BLOCK_SIZE to enable the
chunked implementation. When building for OSX with the CommonCrypto
library we error out if SHA1_MAX_BLOCK_SIZE is not defined, which will
avoid compiling a version of the tool that won't compute hashes
properly on large files. It should be easy to enable this on other
platforms if needed.
Atousa
On Thu, Oct 29, 2015 at 10:19 AM, Junio C Hamano wrote:
> Atousa Duprat writes:
>
>> [PATCH] Limit the size of the data block passed to SHA1_Update()
>>
>> This avoids issues where OS-specific implementations use
>> a 32-bit integer to specify block size. Limit currently
>> set to 1GiB.
>> ---
>> cache.h | 20 +++-
>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/cache.h b/cache.h
>> index 79066e5..c305985 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -14,10 +14,28 @@
>> #ifndef git_SHA_CTX
>> #define git_SHA_CTX SHA_CTX
>> #define git_SHA1_Init SHA1_Init
>> -#define git_SHA1_Update SHA1_Update
>> #define git_SHA1_Final SHA1_Final
>> #endif
>>
>> +#define SHA1_MAX_BLOCK_SIZE (1024*1024*1024)
>> +
>> +static inline int git_SHA1_Update(SHA_CTX *c, const void *data, size_t len)
>> +{
>> + size_t nr;
>> + size_t total = 0;
>> + char *cdata = (char*)data;
>> + while(len > 0) {
>> + nr = len;
>> + if(nr > SHA1_MAX_BLOCK_SIZE)
>> + nr = SHA1_MAX_BLOCK_SIZE;
>> + SHA1_Update(c, cdata, nr);
>> + total += nr;
>> + cdata += nr;
>> + len -= nr;
>> + }
>> + return total;
>> +}
>> +
>
> I think the idea illustrated above is a good start, but there are
> a few issues:
>
> * SHA1_Update() is used in fairly many places; it is unclear if it
>is a good idea to inline.
>
> * There is no need to punish implementations with working
>SHA1_Update by another level of wrapping.
>
> * What would you do when you find an implementation for which 1G is
>still too big?
>
> Perhaps something like this in the header
>
> #ifdef SHA1_MAX_BLOCK_SIZE
> extern int SHA1_Update_Chunked(SHA_CTX *, const void *, size_t);
> #define git_SHA1_Update SHA1_Update_Chunked
> #endif
>
> with compat/sha1_chunked.c that has
>
> #ifdef SHA1_MAX_BLOCK_SIZE
> int SHA1_Update_Chunked(SHA_CTX *c, const void *data, size_t len)
> {
> ... your looping implementation ...
> }
> #endif
>
> in it, that is only triggered via a Makefile macro, e.g.
> might be a good workaround.
>
> diff --git a/Makefile b/Makefile
> index 8466333..83348b8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -139,6 +139,10 @@ all::
> # Define PPC_SHA1 environment variable when running make to make use of
> # a bundled SHA1 routine optimized for PowerPC.
> #
> +# Define SHA1_MAX_BLOCK_SIZE if your SSH1_Update() implementation can
> +# hash only a limited amount of data in one call (e.g. APPLE_COMMON_CRYPTO
> +# may want 'SHA1_MAX_BLOCK_SIZE=1024L*1024L*1024L' defined).
> +#
> # Define NEEDS_CRYPTO_WITH_SSL if you need -lcrypto when using -lssl
> (Darwin).
> #
> # Define NEEDS_SSL_WITH_CRYPTO if you need -lssl when using -lcrypto
> (Darwin).
> @@ -1002,6 +1006,7 @@ ifeq ($(uname_S),Darwin)
> ifndef NO_APPLE_COMMON_CRYPTO
> APPLE_COMMON_CRYPTO = YesPlease
> COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
> + SHA1_MAX_BLOCK_SIZE=1024L*1024L*1024L
> endif
> NO_REGEX = YesPlease
> PTHREAD_LIBS =
> @@ -1350,6 +1355,11 @@ endif
> endif
> endif
>
> +ifdef SHA1_MAX_BLOCK_SIZE
> +LIB_OBJS += compat/sha1_chunked.o
> +BASIC_CFLAGS += SHA1_MAX_BLOCK_SIZE="$(SHA1_MAX_BLOCK_SIZE)"
> +endif
> +
> ifdef NO_PERL_MAKEMAKER
> export NO_PERL_MAKEMAKER
> endif
--
Atousa Pahlevan, PhD
M.Math. University of Waterloo, Canada
Ph.D. Department of Computer Science, University of Victoria, Canada
Voice: 415-341-6206
Email: apahle...@ieee.org
Website: www.apahlevan.org
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fsck failure on OS X with files >= 4 GiB
Here is a solution that avoids problems with OS-specific
implementations of SHA_Update() by limiting the size of each update
request to 1GiB and calling the function repeatedly in a loop.
Atousa
--
[PATCH] Limit the size of the data block passed to SHA1_Update()
This avoids issues where OS-specific implementations use
a 32-bit integer to specify block size. Limit currently
set to 1GiB.
---
cache.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 79066e5..c305985 100644
--- a/cache.h
+++ b/cache.h
@@ -14,10 +14,28 @@
#ifndef git_SHA_CTX
#define git_SHA_CTX SHA_CTX
#define git_SHA1_Init SHA1_Init
-#define git_SHA1_Update SHA1_Update
#define git_SHA1_Final SHA1_Final
#endif
+#define SHA1_MAX_BLOCK_SIZE (1024*1024*1024)
+
+static inline int git_SHA1_Update(SHA_CTX *c, const void *data, size_t len)
+{
+ size_t nr;
+ size_t total = 0;
+ char *cdata = (char*)data;
+ while(len > 0) {
+ nr = len;
+ if(nr > SHA1_MAX_BLOCK_SIZE)
+ nr = SHA1_MAX_BLOCK_SIZE;
+ SHA1_Update(c, cdata, nr);
+ total += nr;
+ cdata += nr;
+ len -= nr;
+ }
+ return total;
+}
+
#include
typedef struct git_zstream {
z_stream z;
--
2.4.9 (Apple Git-60)
On Thu, Oct 29, 2015 at 8:15 AM, Filipe Cabecinhas wrote:
> Defining BLK_SHA1 = YesPlease (when calling make) should just change
> the SHA functions, instead of completely removing OpenSSL or
> CommonCrypto.
>
> Regards,
> Filipe
>
>
> On Thu, Oct 29, 2015 at 3:46 AM, Rafael Espíndola
> wrote:
>> Awesome, building with
>>
>> NO_OPENSSL = 1
>> NO_GETTEXT = 1
>>
>> produces a working git :-)
>>
>> Cheers,
>> Rafael
>>
>>
>> On 28 October 2015 at 23:37, Filipe Cabecinhas wrote:
>>> I did some debugging, and it seems CC_SHA1_Update (used by
>>> write_sha1_file_prepare if APPLE_COMMON_CRYPTO is defined in the Makefile)
>>> takes a uint32_t as a "length" parameter, which explains why it stops
>>> working at 4GiB (UINT_MAX+1).
>>>
>>> In the OS X 10.11 SDK header CommonCrypto/CommonDigest.h, we have:
>>>
>>> typedef uint32_t CC_LONG; /* 32 bit unsigned integer */
>>> //...
>>> extern int CC_SHA1_Update(CC_SHA1_CTX *c, const void *data, CC_LONG len)
>>>
>>> A possible fix would be to either call SHA1_Update with a maximum of
>>> UINT_MAX, looping if necessary. Or have a compatibility SHA1_Update for OS X
>>> which can handle data longer than UINT_MAX.
>>>
>>> I'm not sure what the git maintainers would prefer.
>>>
>>> Regards,
>>>
>>> Filipe
>>>
>>> On Wed, Oct 28, 2015 at 4:10 PM, Rafael Espíndola
>>> wrote:
I first noticed this with "2.4.9 (Apple Git-60)", but it reproduces
with git built from 37023ba381b6d251d7140a997b39b566dbc63c42.
Create two files with just 0s:
-rw-r--r-- 1 espindola staff 4294967296 28 Oct 11:09 exactly-4gib
-rw-r--r-- 1 espindola staff 4294967295 28 Oct 11:09 one-less-than-4gib
and run
git init
git add one-less-than-4gib
git commit -m bar
git fsck
git add exactly-4gib
git commit -m bar
git fsck
The first fsck will run with no problems, but the second one fails:
error: packed cfdaf54c9ccfd8f5e4cee562f7d5f92df13d3106 from
.git/objects/pack/pack-ff08480fd7f767b6bd0aeb559f0f5dea2245b0b3.pack
is corrupt
Using the very same revision on freebsd doesn't cause any errors.
Cheers,
Rafael
>>>
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Atousa Pahlevan, PhD
M.Math. University of Waterloo, Canada
Ph.D. Department of Computer Science, University of Victoria, Canada
Voice: 415-341-6206
Email: apahle...@ieee.org
Website: www.apahlevan.org
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
