* Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 17 Apr 2005, Ingo Molnar wrote:
in fact, this attack cannot even be proven to be malicious, purely via
the email from Malice: it could be incredible bad luck that caused that
good-looking patch to be mistakenly matching a dangerous
On Sat, 2005-04-16 at 17:33 +0200, Johannes Schindelin wrote:
But if it can be done cheaply enough at a later date even though we end
up repeating ourselves, and if it can be done _well_ enough that we
shouldn't have just asked the user in the first place, then yes, OK I
agree.
The
* Ingo Molnar [EMAIL PROTECTED] wrote:
The compromise relies on you having reviewed something harmless, while
in reality what happened within the DB was far less harmless. And the
DB remains self-consistent: neither fsck, nor others importing your
tree will be able to detect the
Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
I get the feeling that it isn't that bad. For example, if we did it
at the points where the blobs actually entered the tree, then the cost
is always proportional to the change
On Mon, 18 Apr 2005, Herbert Xu wrote:
I wasn't disputing that of course. However, the same effect can be
achieved in using a single hash with a bigger length, e.g., sha256
or sha512.
No it cannot.
If somebody actually literally totally breaks that hash, length won't
matter. There are
Petr Baudis wrote:
Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
I get the feeling that it isn't that bad. For example, if we did it
at the points where the blobs actually entered the tree, then the cost
is always
Dear diary, on Mon, Apr 18, 2005 at 02:49:06AM CEST, I got a letter
where Herbert Xu [EMAIL PROTECTED] told me that...
Therefore the only conclusion I can draw is that we're only calling
update-cache on the set of changed files, or at most a small superset
of them. In that case, the cost of
On Fri, Apr 15, 2005 at 08:32:46AM -0700, Linus Torvalds wrote:
In other words, I'm right. I'm always right, but sometimes I'm more
right
than other times. And dammit, when I say files don't matter, I'm
really
really Right(tm).
You're right, of course (All Hail Linus!), if you can make it work
Hi,
On Fri, 15 Apr 2005, David Woodhouse wrote:
But if it can be done cheaply enough at a later date even though we end
up repeating ourselves, and if it can be done _well_ enough that we
shouldn't have just asked the user in the first place, then yes, OK I
agree.
The repetition could be
On Sat, Apr 16, 2005 at 06:03:33PM +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
where Simon Fowler [EMAIL PROTECTED] told me that...
On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
Simon
given that you have multiple
CL == Christopher Li [EMAIL PROTECTED] writes:
- Result is this object $SHA1 with mode $mode at $path (takes
one of the trees); you can do update-cache --cacheinfo (if
you want to muck with dircache) or cat-file blob (if you want
to get the file) or both.
CL Is that SHA1 for tree or the
On Fri, Apr 15, 2005 at 12:43:47AM -0700, Junio C Hamano wrote:
CL == Christopher Li [EMAIL PROTECTED] writes:
CL Is that SHA1 for tree or the file object?
I am talking about a single file here.
Then do you emit the entry for it's parents directory?
e.g. /foo/bar get created. foo doesn't
On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote:
do such cases occur frequently? In the kernel at least it's not too
typical.
Isn't it? I thought it was a fairly accurate representation of the
process I make a whole bunch of changes to files I maintain, pulling
from Linus while
On Fri, Apr 15, 2005 at 02:03:08PM +0200, Johannes Schindelin wrote:
I disagree. In order to be trusted, this thing has to catch the following
scenario:
Skywalker and Solo start from the same base. They commit quite a lot to
their trees. In between, Skywalker commits a tree, where the
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB I can't see the conflicts between what I want and what Linus wants.
PB After all, Linus says that I can use the directory cache in any way I
PB please (well, the user can, but I'm speaking for him ;-). So I'm doing
PB so, and with your tool I would
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
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
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
18 matches
Mail list logo
