Jonathon Mah j...@me.com writes:
Just to note, the proposals so far don't prevent a smart-ass
function from freeing the buffer when it's called underneath the
use/release scope, as in:
with_commit_buffer(commit); {
fn1_needing_buffer(commit);
walk_rev_tree_or_something();
Am 23.01.2013 21:02, schrieb Jeff King:
On Wed, Jan 23, 2013 at 03:38:16PM +0100, Armin wrote:
Hello dear git people.
I experience a reproducible segmentation fault on one of my
repositories when doing a git log --submodule -p, tested with newest
version on Arch Linux (git version 1.8.1.1)
Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen:
On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Does it fail with older versions of git? If so, can you bisect?
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try
On Thu, Jan 24, 2013 at 9:06 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen:
On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Does it fail with older versions of git? If so, can you
On Thu, Jan 24, 2013 at 09:14:47PM +0700, Nguyen Thai Ngoc Duy wrote:
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try internal cache before reading object db)
diff --git a/object.c b/object.c
index d8d09f9..6b06297 100644
--- a/object.c
+++ b/object.c
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the buffer is primed? Or
should we err on the side of keeping it in place?).
On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the
On Fri, Jan 25, 2013 at 7:55 AM, Jeff King p...@peff.net wrote:
On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier for the later user to reliably ensure the buffer is primed? Or
should
On Thu, Jan 24, 2013 at 07:59:58PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
... (e.g., how should log know that a submodule diff might later want
to see the same entry? Should we optimistically free and then make it
easier
Jeff King p...@peff.net writes:
... I know it gets the job done, but in my
experience, macros which do not behave syntactically like functions are
usually a good sign that you are doing something gross and
unmaintainable.
Yeah, it is a bit too cute for my taste, too, even though it was fun
Hi,
Junio C Hamano wrote:
I've been toying with an idea along this line.
Heh. Just for fun, here's an uglier version:
struct wcb_data {
int had_buffer;
int using_buffer;
};
#define WITH_COMMIT_BUFFER_DATA_INIT { 0, 0 }
extern
Jonathan Nieder jrnie...@gmail.com writes:
Hi,
Junio C Hamano wrote:
I've been toying with an idea along this line.
Heh. Just for fun, here's an uglier version:
Much nicer, though.
struct wcb_data {
int had_buffer;
int using_buffer;
};
Just to note, the proposals so far don't prevent a smart-ass function from
freeing the buffer when it's called underneath the use/release scope, as in:
with_commit_buffer(commit); {
fn1_needing_buffer(commit);
walk_rev_tree_or_something();
fn2_needing_buffer(commit);
}
Hello dear git people.
I experience a reproducible segmentation fault on one of my repositories when
doing a git log --submodule -p, tested with newest version on Arch Linux (git
version 1.8.1.1) and built fresh (git version 1.8.1.1.347.g9591fcc), tried on 2
seperate systems:
Program
On Wed, Jan 23, 2013 at 03:38:16PM +0100, Armin wrote:
Hello dear git people.
I experience a reproducible segmentation fault on one of my
repositories when doing a git log --submodule -p, tested with newest
version on Arch Linux (git version 1.8.1.1) and built fresh (git
version
16 matches
Mail list logo
