Re: [Bug] git branch -v has problems with carriage returns

f-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 <j...@kdbg.org> wrote: > Am 19.05.2017 um 23:55 schrieb Atousa Duprat: >> >> I have tried to repro this issue but git goes out of

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

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,

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

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

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

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

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 +=

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

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

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

Re: git fsck failure on OS X with files >= 4 GiB

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 <gits...@pobox.com> wrote: > Atousa Duprat <atous...@gmail.com> writes: > >> [PATCH] Li