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 (a
Junio C Hamano writes:
> Jeff King 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, b
Jeff King 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 expanding the tabs
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
Ok, sorrry for not responsding for quite a while, we had the 5.0 release and
had too much to do.
I found out why it segfaults: I had a .gitconfig file (sry must have somehow
missed that no idea why actually) with the following contents:
http://dpaste.com/1027662/
it seems that the memory corr
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 tr
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 0525bbd73c9
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 0525bbd73c9
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.
> >I
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 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 G
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) 2002-201
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 Sewa
13 matches
Mail list logo
