Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
and so on. I haven't quite figured out what is going on. It looks like
we call update_pre_post_images with postlen==0, which causes it to just
write the fixed postimage into the existing buffer. But of course the
fixed
On Fri, Mar 22, 2013 at 11:08:59AM -0700, Junio C Hamano wrote:
This may be sufficient. In the olden days, we relied on that all
whitespace fixing rules made the result shorter and took advantage
of it in update-pre-post-images to rewrite the images in place. The
oddball tab-in-indent (aka
On Tue, Mar 19, 2013 at 11:42:45AM +0100, Bernhard Posselt wrote:
it seems that the memory corruption does not happen anymore when i change
[apply]
whitespace = fix
to
[apply]
#whitespace = fix
so fixing whitespaces may be the culprit
Thanks, I'm able to reproduce
Jeff King p...@peff.net writes:
and so on. I haven't quite figured out what is going on. It looks like
we call update_pre_post_images with postlen==0, which causes it to just
write the fixed postimage into the existing buffer. But of course the
fixed version is bigger, because we are
On 03/10/2013 08:05 AM, Jeff King wrote:
On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:
Also, I can almost reproduce here, as PatrickHeller/core.git is public.
However, I suspect the problem is particular to your work built on top,
which looks like it is at commit
On 03/10/2013 08:05 AM, Jeff King wrote:
On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:
Also, I can almost reproduce here, as PatrickHeller/core.git is public.
However, I suspect the problem is particular to your work built on top,
which looks like it is at commit
On Sun, Mar 10, 2013 at 12:45:43PM +0100, Bernhard Posselt wrote:
valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \
git pull --rebase https://github.com/Raydiation/core
The log file was empty and it seemed to apply everything nice when
running valgrind. When i tried to
On 03/09/2013 05:48 AM, Jeff King wrote:
On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:
The problem is likely happening in a sub-command of git-pull, so
valgrind isn't reporting it. Can you try re-running with
valgrind --trace-children=yes, or alternatively narrow down the
On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:
Also, I can almost reproduce here, as PatrickHeller/core.git is public.
However, I suspect the problem is particular to your work built on top,
which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.
Is it
Hi im running arch linux and core/glibc 2.17-3
When i try to rebase with:
git clonehttps://github.com/owncloud/core.git
cd core/
git pull --rebasehttps://github.com/PatrickHeller/core.git master
I'm getting:
$ git pull --rebasehttps://github.com/PatrickHeller/core.git master
remote:
On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:
Using valgrind gives me:
$ valgrind /usr/bin/git pull
--rebasehttps://github.com/PatrickHeller/core.git master
==5995== Memcheck, a memory error detector
==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et
On 03/08/2013 10:28 PM, Jeff King wrote:
On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:
Using valgrind gives me:
$ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git
master
==5995== Memcheck, a memory error detector
==5995== Copyright (C)
On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:
The problem is likely happening in a sub-command of git-pull, so
valgrind isn't reporting it. Can you try re-running with
valgrind --trace-children=yes, or alternatively narrow down the
problematic command by setting
13 matches
Mail list logo
