Re: [PATCH] pull: do not segfault when HEAD refers to missing object file

On Mon, Mar 06, 2017 at 07:52:10AM +0100, Johannes Sixt wrote: > > Yeah, it is. You can do it easily with 'sed', of course, but if you want > > to avoid the extra process and do it in pure shell, it's more like: > > > > last38=${REV#??} > > first2=${REV%$last38} > > rm -f

Re: [PATCH] pull: do not segfault when HEAD refers to missing object file

On Mon, Mar 06, 2017 at 12:42:22AM +0100, André Laszlo wrote: > git pull --rebase on a corrupted HEAD used to segfault;it has been > corrected to error out with a message. A test has also been added to > verify this fix. Your commit message mostly tells us the "what" that we can see from the

Re: [PATCH] pull: do not segfault when HEAD refers to missing object file

Am 06.03.2017 um 04:51 schrieb Jeff King: On Sun, Mar 05, 2017 at 11:52:22PM +, brian m. carlson wrote: On Mon, Mar 06, 2017 at 12:42:22AM +0100, André Laszlo wrote: +test_expect_success 'git pull --rebase with corrupt HEAD does not segfault' ' + mkdir corrupted && + (cd

[PATCH v2] git svn: fix authenticaton with 'branch'

Authentication fails with svn branch while svn rebase and svn dcommit work fine without authentication failures. $ git svn branch v7_3 Copying https://xxx at r27519 to https:///v7_3... Can't create session: Unable to connect

Re: Git download

On 03/05/2017 09:26 PM, Cory Kilpatrick wrote: I have downloaded Git and cannot find the application on my Mac. Should I try to download it again? I don't think so. It could be helpful if we can get some more information: - Could you open the terminal application and type which git git

Re: [PATCH] pull: do not segfault when HEAD refers to missing object file

On Sun, Mar 05, 2017 at 11:52:22PM +, brian m. carlson wrote: > On Mon, Mar 06, 2017 at 12:42:22AM +0100, André Laszlo wrote: > > +test_expect_success 'git pull --rebase with corrupt HEAD does not > > segfault' ' > > + mkdir corrupted && > > + (cd corrupted && > > + git init && > > +

Re: Delta compression not so effective

On Sat, Mar 4, 2017 at 12:27 AM, Marius Storm-Olsen wrote: > > I reran the repack with the options above (dropping the zlib=9, as you > suggested) > > $ time git -c pack.threads=4 repack -a -d -F \ >--window=350 --depth=250 --window-memory=30g > > and ended

Re: RFC: Another proposed hash function transition plan

On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote: > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote: > > > > This document is still in flux but I thought it best to send it out > > early to start getting feedback. > > This actually looks very reasonable if

Re: [PATCH] pull: do not segfault when HEAD refers to missing object file

On Mon, Mar 06, 2017 at 12:42:22AM +0100, André Laszlo wrote: > +test_expect_success 'git pull --rebase with corrupt HEAD does not segfault' ' > + mkdir corrupted && > + (cd corrupted && > + git init && > + echo one >file && git add file && > + git commit -m one && > +

Re: Transition plan for git to move to a new hash function

On Sun, Mar 05, 2017 at 01:45:46PM +, Ian Jackson wrote: > brian m. carlson writes ("Re: Transition plan for git to move to a new hash > function"): > > Instead, I was referring to areas like the notes code. It has extensive > > use of the last byte as a type of lookup table key. It's very

[PATCH] pull: do not segfault when HEAD refers to missing object file

git pull --rebase on a corrupted HEAD used to segfault; it has been corrected to error out with a message. A test has also been added to verify this fix. Signed-off-by: André Laszlo --- Notes: When add_head_to_pending fails to add a pending object, git pull --rebase

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 05/03/17 17:38, Lars Schneider wrote: >> On 02 Mar 2017, at 16:17, Ramsay Jones wrote: >> On 02/03/17 11:24, Johannes Schindelin wrote: >>> On Thu, 2 Mar 2017, Lars Schneider wrote: >>> >> [snip] One thing that still bugs me: In the Linux32 environment prove

Git download

I have downloaded Git and cannot find the application on my Mac. Should I try to download it again?

[PATCH v3] Travis: also test on 32-bit Linux

From: Johannes Schindelin When Git v2.9.1 was released, it had a bug that showed only on Windows and on 32-bit systems: our assumption that `unsigned long` can hold 64-bit values turned out to be wrong. This could have been caught earlier if we had a Continuous

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 16:17, Ramsay Jones wrote: > > > > On 02/03/17 11:24, Johannes Schindelin wrote: >> Hi Lars, >> >> On Thu, 2 Mar 2017, Lars Schneider wrote: >> > [snip] >>> One thing that still bugs me: In the Linux32 environment prove adds the >>> CPU

difflame improvements

Hi! Since my last post the biggest improvement is the ability to detect that the user has requested a "reverse" analysis. Under "normal" circumstances a user would ask difflame to get the diff from an ancestor (call "difflame treeish1 treeish2" so that merge-base of treeish1 treeish2 equals

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

Hey Stephan On Sat, Mar 4, 2017 at 8:05 PM, Stephan Beyer wrote: > Hi Pranit, > > On 03/04/2017 12:26 AM, Junio C Hamano wrote: >> -- >> [Stalled] > [...] >> >> * pb/bisect (2017-02-18) 28 commits >> - fixup! bisect--helper:

Re: bisect-helper: we do not bisect --objects

From: "Junio C Hamano" "Philip Oakley" writes: Bikeshedding: If the given boundary is a tag, it could be tagging a blob or tree rather than a commit. Would that be a scenario that reaches this part of the code? I do not think it is relevant.

Re: Transition plan for git to move to a new hash function

brian m. carlson writes ("Re: Transition plan for git to move to a new hash function"): > Instead, I was referring to areas like the notes code. It has extensive > use of the last byte as a type of lookup table key. It's very dependent > on having exactly one hash, since it will always want to

Re: [PATCH] line-log: use COPY_ARRAY to fix mis-sized memcpy

On 05/03/2017 12:44, Jeff King wrote: On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote: range_set_init(dst, src->nr); - memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range_set)); + memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range)); I think

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote: > I grepped for 'memcpy.*sizeof' and found one other case that's not a > bug, but is questionable. And here's the fix for that case. It can be applied separately from the other patch if need be. -- >8 -- Subject: [PATCH] ewah: fix

[PATCH] line-log: use COPY_ARRAY to fix mis-sized memcpy

On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote: > > range_set_init(dst, src->nr); > > - memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range_set)); > > + memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range)); > > I think "sizeof(*dst->ranges)" is probably an

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Sat, Mar 04, 2017 at 09:08:40PM +0100, Vegard Nossum wrote: > > At a glance, looks like range_set_copy() is using > > sizeof(struct range_set) == 12, but > > range_set_init/range_set_grow/ALLOC_GROW/REALLOC_ARRAY is using > > sizeof(rs->range) == 8. > > Attached patch seems to fix it --

Re: RFC: Another proposed hash function transition plan

Translation table ~ A fast bidirectional mapping between sha1-names and sha256-names of all local objects in the repository is kept on disk. The exact format of that mapping is to be determined. All operations that make new objects (e.g., "git commit") add the new objects to the