this patch cleans up add_file_to_cache() to free up all memory it
allocates. This has no significance right now as the only user of
add_file_to_cache() die()s immediately in the 'leak' paths - but if the
function is ever used without dying then this uncleanliness could lead
to a memory leak.
* Ingo Molnar [EMAIL PROTECTED] wrote:
this patch fixes a memory leak in read-cache.c: when there's cache
entry collision we should free the previous one.
+ free(active_cache[pos]);
active_cache[pos] = ce;
i'm having second thoughs about this one: active_cache
* Linus Torvalds [EMAIL PROTECTED] wrote:
In other words, if the common case is that we update a couple of
entries in the active cache, we actually saved 1.6MB (+ malloc
overhead for the 17 _thousand_ allocations) by my approach.
And the leak? There's none. We never actually update an
I forgot to include util.c. On my to-do list is something to make this
more obvious.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: util.c
===
--- /dev/null (tree:e8194c62bfc68725972a6847fa2c6d529ca64137)
+++
Linus Torvalds wrote:
So why is base64 worse than the stock one?
As mentioned, the flat version may be faster, but it really isn't an
option. 32000 objects is peanuts. Any respectable source tree may hit that
in a short time, and will break in horrible ways on many Linux
filesystems.
If it does,
On Wed, 13 Apr 2005, Linus Torvalds wrote:
I agree. But I did the silly common revision tracking part slightly
differently and in particular I already made fsck and rev-tree use the
same exact code.
I think I only saw a cut-and-paste version, and I didn't want to follow
that pattern.
Also,
On Thu, 2005-04-14 at 02:12 -0700, Linus Torvalds wrote:
I take that back. I'd be much happier with you doing and testing it,
because now I'm crashing.
OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
what you're going to want to feed it. We store seconds since UTC epoch,
On Thu, 14 Apr 2005, David Woodhouse wrote:
I've been looking at tracking file revisions. One proposed solution was
to have a separate revision history for individual files, with a new
kind of 'filecommit' object which parallels the existing 'commit',
referencing a blob instead of a tree.
* David Woodhouse [EMAIL PROTECTED] wrote:
I've been looking at tracking file revisions. One proposed solution
was to have a separate revision history for individual files, with a
new kind of 'filecommit' object which parallels the existing 'commit',
referencing a blob instead of a tree.
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB Bah, you outran me. ;-)
Just being in a different timezone, I guess.
PB I'll change it to use the cool git-pasky stuff (commit-id etc) and its
PB style of committing - that is, it will merely record the update-caches
PB to be done upon commit, and
Linus Torvalds wrote:
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
Although Linus is correct in that an SCM doesn't *have* to handle this,
it really feels like shooting for mediocracy to me. We might as well
design it right from the beginning.
No. git is not an SCM. it's a filesystem designed to
On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:
The thing i tried to avoid was to list long filenames in the commit
(because of the tree hierarchy we'd need to do tree-absolute pathnames
or something like that, and escape things, and do lookups - duplicating
a VFS which is quite bad)
Linus Torvalds wrote:
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
Although Linus is correct in that an SCM doesn't *have* to handle
this, it really feels like shooting for mediocracy to me. We might
as well design it right from the beginning.
No. git is not an SCM. it's a filesystem
On Thu, 2005-04-14 at 12:19 -0700, [EMAIL PROTECTED] wrote:
With a UTC date, why would anyone care in which timezone the commit was
made? Any pretty printing would most likely be prettiest if it is done
relative to the timezone of the person looking at the commit record, not
the person who
I'd prefer not to lose the information. If someone has committed a
change at 2am, I like to know that it was 2am for _them_. It helps me
decide where to look first for the cause of problems. :)
I'd think the 8:00am-before-the-first-coffee checkins would be the
most worrying :-)
It also helps
Dear diary, on Thu, Apr 14, 2005 at 10:23:26PM CEST, I got a letter
where Erik van Konijnenburg [EMAIL PROTECTED] told me that...
On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
Hmm. I actually don't like this naming. I think it's not too consistent,
is irregular, therefore
Dear diary, on Thu, Apr 14, 2005 at 10:58:52PM CEST, I got a letter
where H. Peter Anvin [EMAIL PROTECTED] told me that...
Petr Baudis wrote:
Cogito. Git inside can be the first slogan.
What about tig?
I like Cogito; it's a real name, plus it'd be a good use for the
On Thu, 14 Apr 2005, David Woodhouse wrote:
Opinions? Dissent? We'd probably need to escape the filenames in some
way -- handwave over that for now.
I personally think renames are a minor thing that doesn't happen
much. What actually happens, in my opinion, is that some chunk of a file
is
subscribe git
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
gitcancel.sh do not handle mode changes:
$ chmod -x Makefile
$ git cancel
patch: Only garbage was found in the patch input.
Rather use checkout-cache to sync our tree, as should do the right thing
instead of diffing (cancel imply just blow away everything).
Signed-off-by:
On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
(PS, can you check the fact that your mail client keeps on adding a 'Re:
' ...)
Hmm. I guess my ancient
Dear diary, on Fri, Apr 15, 2005 at 12:57:25AM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
Hi,
gitcancel.sh do not handle mode changes:
$ chmod -x Makefile
$ git cancel
patch: Only garbage was found in the patch input.
Rather use
Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told
Dear diary, on Thu, Apr 14, 2005 at 12:00:25AM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
This splits read-cache.c into util.c, cache.c, and objects.c, based on
what the code is used for; similarly, cache.h becomes util.h, cache.h, and
objects.h. For
Steven Cole wrote:
On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
Zach Welch pontificated:
I imagine quite a few folks expect something not entirely unlike an SCM
to emerge from these current efforts. Moreover, Petr's 'git' scripts
wrap your filesystem plumbing to that very
Is that some thing you want to see? Maybe clean up the error printing.
Chris
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ merge.py2005-04-14 16:34:39.0 -0400
@@ -0,0 +1,76 @@
+#!/usr/bin/env python
+
+import re
+import sys
+import os
+from pprint import pprint
+
+def
26 matches
Mail list logo
