* Re: SHA1 hash safety
From: Horst von Brand @ 2005-04-17 6:35 UTC (permalink / raw)
To: ross; +Cc: C. Scott Ananian, omb, David Lang, Ingo Molnar, git
In-Reply-To: <20050416154951.GB13373@jose.lug.udel.edu>
ross@jose.lug.udel.edu said:
[...]
> Linus has already weighed in that he doesn't give a crap. All the
> crypto-babble about collision whitepapers is uninteresting without a
> repo that has real collisions. git is far too cool as is - prove I
> should be concerned.
Just copy over a file (might be the first step in splitting it, or a
header file that is duplicated for convenience, ...)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Linus Torvalds @ 2005-04-18 1:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Brad Roberts, git
In-Reply-To: <20050418002326.GC1461@pasky.ji.cz>
On Mon, 18 Apr 2005, Petr Baudis wrote:
>
> Am I just slow or does the first dst-- make it miss the last trailing
> /[,;.]/?
Hopefully not. It _should_ make it miss the last '\0', but hey, it got my
usual amount of testing (ie none). I'm sure Brad can tell us whether it
makes any difference..
Linus
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Petr Baudis @ 2005-04-18 0:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <1113785521.11910.45.camel@localhost.localdomain>
Dear diary, on Mon, Apr 18, 2005 at 02:51:59AM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-04-18 at 02:50 +0200, Petr Baudis wrote:
> > I think I will make git-pasky's default behaviour (when we get
> > http-pull, that is) to keep the complete commit history but only trees
> > you need/want; togglable to both sides.
>
> I think the default behaviour should probably be to fetch everything.
I think fetching gigs of data just won't work for many people,
especially if they could do with a fraction of that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-18 0:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linus Torvalds, mingo, simon, david.lang, git
In-Reply-To: <20050418004906.GA3132@gondor.apana.org.au>
Dear diary, on Mon, Apr 18, 2005 at 02:49:06AM CEST, I got a letter
where Herbert Xu <herbert@gondor.apana.org.au> 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 the collision check *is* proportional
> to the size of the change.
Yes, of course, sorry for the confusion. We only consider files you
either specify manually or which have their stat metadata changed
relative to the directory cache. (That is from the git-pasky
perspective; from the plumbing perspective, the user just does
update-cache on whatever he picks.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Woodhouse @ 2005-04-18 0:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <20050418005032.GE1461@pasky.ji.cz>
On Mon, 2005-04-18 at 02:50 +0200, Petr Baudis wrote:
> I think I will make git-pasky's default behaviour (when we get
> http-pull, that is) to keep the complete commit history but only trees
> you need/want; togglable to both sides.
I think the default behaviour should probably be to fetch everything.
--
dwmw2
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Petr Baudis @ 2005-04-18 0:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <1113785123.11910.43.camel@localhost.localdomain>
Dear diary, on Mon, Apr 18, 2005 at 02:45:22AM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > > For the special case of removing history before 2.6.12-rc2 from the
> > > trees, I certainly think we can do it by leaving out all the commits,
> > > not just the trees. We can do that easily, but there's no way we can
> > > _add_ that history retrospectively if we omit it in the first place.
> >
> > I'm confused by this paragraph, but that might be my English skills
> > failing somehow.
>
> "For the general case of people pruning their own trees, _maybe_ you're
> right that it would be good to keep the commits even if we delete the
> actual trees. But for history older than 2.6.12-rc2, that's a special
> case -- I think we can happily delete the commits too.
Ah _so_. Thanks for explanation.
I think I will make git-pasky's default behaviour (when we get
http-pull, that is) to keep the complete commit history but only trees
you need/want; togglable to both sides.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Herbert Xu @ 2005-04-18 0:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, mingo, simon, david.lang, git
In-Reply-To: <20050417233441.GU1461@pasky.ji.cz>
On Mon, Apr 18, 2005 at 01:34:41AM +0200, Petr Baudis wrote:
>
> No. The collision check is done in the opposite cache - when you want to
> write a blob and there is already a file of the same hash in the tree.
> So either the blob is already in the database, or you have a collision.
> Therefore, the cost is proportional to the size of what stays unchanged.
This is only true if we're calling update-cache on all unchanged files.
If that's what git is doing then we're in trouble anyway.
Remember that prior to the collision check we've already spent the
effort in
1) Compressing the file.
2) Computing a SHA1 hash on the result.
These two steps together (especially the first one) is much more
expensive than a file content comparison of the blob versus what's
already in the tree.
Somehow I have a hard time seeing how this can be at all efficient if
we're compressing all checked out files including those which are
unchanged.
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 the collision check *is* proportional
to the size of the change.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Woodhouse @ 2005-04-18 0:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <20050418003526.GD1461@pasky.ji.cz>
On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > For the special case of removing history before 2.6.12-rc2 from the
> > trees, I certainly think we can do it by leaving out all the commits,
> > not just the trees. We can do that easily, but there's no way we can
> > _add_ that history retrospectively if we omit it in the first place.
>
> I'm confused by this paragraph, but that might be my English skills
> failing somehow.
"For the general case of people pruning their own trees, _maybe_ you're
right that it would be good to keep the commits even if we delete the
actual trees. But for history older than 2.6.12-rc2, that's a special
case -- I think we can happily delete the commits too.
"We can delete old trees/commits easily, but we can't _add_ them to the
existing linux-2.6.git tree, because the oldest commit in that tree
(b4ceb6e27e4cc3f37d26e04c4535c79b98a9f889) doesn't have a parent."
--
dwmw2
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Petr Baudis @ 2005-04-18 0:35 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <1113782805.11910.36.camel@localhost.localdomain>
Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > Of course an entirely different thing are _trees_ associated with those
> > commits. As long as you stay with a simple three-way merge, you
> > basically never want to look at trees which aren't heads and which you
> > don't specifically request to look at. And the trees and what they carry
> > inside is the main bulk of data.
>
> If the trees are absent and you're trying to merge, what do you gain
> from having the commit objects?
merge-base
> For the special case of removing history before 2.6.12-rc2 from the
> trees, I certainly think we can do it by leaving out all the commits,
> not just the trees. We can do that easily, but there's no way we can
> _add_ that history retrospectively if we omit it in the first place.
I'm confused by this paragraph, but that might be my English skills
failing somehow.
> For history older than 2.6.12-rc2 I'd suggest that it would be available
> in a different place, and absent from the 'main' working tree that
> everyone uses by default. The only difference we'd see in the working
> tree is that the 2.6.12-rc2 commit -- the oldest commit in that tree --
> would actually have an absentee parent instead of appearing to be an
> import. And all the sha1 hashes of all subsequent commits would be
> different, of course.
Yes, that's what I suggested too.
> To allow pruning of older objects in the general case would be a little
> bit harder than that, because as things stand you'd be re-fetching them
> every time you rsync from elsewhere -- but that wouldn't really be hard
> to fix if we care.
I think http-pull is very promising. :-)
It could be actually much faster than rsync, since you don't need to
build directory listings etc, which actually takes non-trivial amount of
time already with the kernel git repository.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [RFC] General object parsing
From: Daniel Barkalow @ 2005-04-18 0:25 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: git
After the fiasco with confusing struct revision for a struct commit, I've
worked out something that makes more sense. I've actually ported
fsck-cache, rev-tree, and my merge-base to it, so it should at least be
comprehensive.
The design is as follows:
There is a struct object for each object in the database, although they
are only created on demand. It contains the type and sha1 of the
object, as well as a flag for whether the object contents have been read,
more flags for general use, a list of objects which it references, and a
flag for whether any objects reference it.
Each struct object is embedded in a type-specific struct, which contains
further information. For example, struct commit has the date, the parents,
and the tree.
Parsing objects is progressive; objects are created in an unread state
(with no disk access), and functions can be called to parse each object as
it is determined to be interesting. This should generally allow for only
the necessary portions of a large set of object references to be read.
Any comment on the design, or should I send my implementation?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Petr Baudis @ 2005-04-18 0:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brad Roberts, git
In-Reply-To: <Pine.LNX.4.58.0504171636590.7211@ppc970.osdl.org>
Dear diary, on Mon, Apr 18, 2005 at 01:39:10AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sun, 17 Apr 2005, Brad Roberts wrote:
> >
> > braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
> >
> > All gecos entries on all my debian boxes are of the form:
> >
> > fullname, office number, office extension, and home number
>
> Ahh, ok.
>
> I'll make the "cleanup" thing just remove strange characters from the end,
> that should fix this kind of thing for now.
>
> I'd just remove everything after the first strange number, but I can also
> see people using the "lastname, firstname" format, and I'd hate to just
> ignore firstname in that case.
> + /*
> + * Go back, and remove crud from the end: some people
> + * have commas etc in their gecos field
> + */
> + dst--;
> + while (--dst >= p) {
> + unsigned char c = *dst;
> + switch (c) {
> + case ',': case ';': case '.':
> + *dst = 0;
> + continue;
> + }
> + break;
> + }
Am I just slow or does the first dst-- make it miss the last trailing
/[,;.]/?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Woodhouse @ 2005-04-18 0:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <20050417233936.GV1461@pasky.ji.cz>
On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> I think this is bad, bad, bad. If you don't keep around all the
> _commits_, you get into all sorts of troubles - when merging, when doing
> git log, etc. And the commits themselves are probably actually pretty
> small portion of the thing. I didn't do any actual measurement but I
> would be pretty surprised if it would be much more than few megabytes of
> data for the kernel history.
I'm not sure it's that bad -- and everyone already seems perfectly happy
not to have history going back before 2.6.12-rc2. We're not talking
about doing this by _default_ -- we're talking about allowing people to
keep trees pruned if they _want_ to. So I might want to drop history
before 2.6.0 on my laptop, for example.
> Of course an entirely different thing are _trees_ associated with those
> commits. As long as you stay with a simple three-way merge, you
> basically never want to look at trees which aren't heads and which you
> don't specifically request to look at. And the trees and what they carry
> inside is the main bulk of data.
If the trees are absent and you're trying to merge, what do you gain
from having the commit objects? And for the case of 'git log', I
certainly think it's acceptable that you lose out on those parts of
prehistory which you've explicitly removed from your local tree --
that's a feature, not a bug.
For the special case of removing history before 2.6.12-rc2 from the
trees, I certainly think we can do it by leaving out all the commits,
not just the trees. We can do that easily, but there's no way we can
_add_ that history retrospectively if we omit it in the first place.
For history older than 2.6.12-rc2 I'd suggest that it would be available
in a different place, and absent from the 'main' working tree that
everyone uses by default. The only difference we'd see in the working
tree is that the 2.6.12-rc2 commit -- the oldest commit in that tree --
would actually have an absentee parent instead of appearing to be an
import. And all the sha1 hashes of all subsequent commits would be
different, of course.
To allow pruning of older objects in the general case would be a little
bit harder than that, because as things stand you'd be re-fetching them
every time you rsync from elsewhere -- but that wouldn't really be hard
to fix if we care.
Either way, I think it can probably be done by omitting the commit
objects as well as the trees -- but the important point is that we
_should_ include a 'parent' pointer in the oldest commit of the tree
we're working with, pointing back to the imported history.
--
dwmw2
^ permalink raw reply
* Re: [patch] git: fix 1-byte overflow in show-files.c
From: Petr Baudis @ 2005-04-17 23:59 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, Linus Torvalds
In-Reply-To: <20050414125354.GB15420@elte.hu>
Dear diary, on Thu, Apr 14, 2005 at 02:53:54PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
>
> this patch fixes a 1-byte overflow in show-files.c (looks narrow is is
> probably not exploitable). A specially crafted db object (tree) might
> trigger this overflow.
>
> 'fullname' is an array of 4096+1 bytes, and we do readdir(), which
> produces entries that have strings with a length of 0-255 bytes. With a
> long enough 'base', it's possible to construct a tree with a name in it
> that has directory whose name ends precisely at offset 4095. At that
> point this code:
>
> case DT_DIR:
> memcpy(fullname + baselen + len, "/", 2);
>
> will attempt to append a "/" string to the directory name - resulting in
> a 1-byte overflow (a zero byte is written to offset 4097, which is
> outside the array).
The name ends precisely at offset 4095 with its NUL character:
{PATH_MAX}
Maximum number of bytes in a pathname, including the terminating
null character.
[ http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ]
So, if I'm not mistaken, '/' will be written at offset 4095 instead of
the NUL and the NUL will be written at 4096. Everything's fine, right?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Kenneth Johansson @ 2005-04-17 23:53 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, mingo, simon, david.lang, git
In-Reply-To: <20050417233441.GU1461@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
> where Herbert Xu <herbert@gondor.apana.org.au> 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 size (the number of new blobs).
>
>
> No. The collision check is done in the opposite cache - when you want to
> write a blob and there is already a file of the same hash in the tree.
> So either the blob is already in the database, or you have a collision.
>
> Therefore, the cost is proportional to the size of what stays unchanged.
>
?? now I'm confused. Surly the only cost involved is to never write over
a file that already exist in the cache and that is already done NOW as
far as I read the code. So there is NO extra cost in detecting an collision.
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-17 23:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: mingo, pasky, simon, david.lang, git
In-Reply-To: <20050417232905.GA2721@gondor.apana.org.au>
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 (bad) hashes where you can literally edit the content of
the file, and make sure that the end result has the same hash.
In that case, when the hash algorithm has actually been broken, the length
of the hash ends up being not very relevant.
For example, you might "hash" your file by blocking it up in 16-byte
blocks, and xoring all blocks together - the result is a 16-byte hash.
It's a terrible hash, and obviously trivially breakable, and once broken
it does _not_ help to make it use its 32-byte cousin. Not at all. You can
just modify the breaking thing to equally cheaply make modifications to a
file and get the 32-byte hash "right" again.
Is that kind of breakage likely for sha1? Hell no. Is it possible? In your
"in theory" world where practice doesn't matter, yes.
Linus
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Petr Baudis @ 2005-04-17 23:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <1113780698.11910.8.camel@localhost.localdomain>
Dear diary, on Mon, Apr 18, 2005 at 01:31:36AM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> Note that any given copy of a tree doesn't _need_ to keep all the
> history back the beginning of time. It's OK if the oldest commit object
> in your tree actually refers back to a parent which doesn't exist
> locally. I can well imagine that some people will want to keep their
> trees pruned to keep only a few weeks of history, while other copies of
> the tree will keep everything.
I think this is bad, bad, bad. If you don't keep around all the
_commits_, you get into all sorts of troubles - when merging, when doing
git log, etc. And the commits themselves are probably actually pretty
small portion of the thing. I didn't do any actual measurement but I
would be pretty surprised if it would be much more than few megabytes of
data for the kernel history.
Of course an entirely different thing are _trees_ associated with those
commits. As long as you stay with a simple three-way merge, you
basically never want to look at trees which aren't heads and which you
don't specifically request to look at. And the trees and what they carry
inside is the main bulk of data.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Building git on Fedora
From: David Woodhouse @ 2005-04-17 23:39 UTC (permalink / raw)
To: jeff millar; +Cc: git
In-Reply-To: <4262F07D.4050007@adelphia.net>
On Sun, 2005-04-17 at 19:25 -0400, jeff millar wrote:
> ln -sf /lib/modules/`uname -r`/build/include/linux /usr/local/include/linux
>
> This fix creates a symlink, on each boot up, in the local include
> directory that points to the kernel header files. If there's a better
> way to do this, I'm all ears.
What's wrong with the contents of the glibc-kernheaders package? Can you
file specific bugs if you're having problems?
In the long run, the answer is to convince Linus that we _really_ need
the kernel to have a set of header files defining the ABI which are fit
for public consumption, rather than having a horrid mix of private and
exportable bits throughout the contents of the include/ directory.
In the meantime, some poor mug has to clean the crap up and try to make
something suitable to live in /usr/include/linux -- and unfortunately at
the moment for Fedora that someone is me :)
Unless git is doing something with kernel-private headers that it
shouldn't, this probably wants to be discussed elsewhere -- most likely
in Bugzilla.
--
dwmw2
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Linus Torvalds @ 2005-04-17 23:39 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504171614150.2625-100000@bellevue.puremagic.com>
On Sun, 17 Apr 2005, Brad Roberts wrote:
>
> braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
>
> All gecos entries on all my debian boxes are of the form:
>
> fullname, office number, office extension, and home number
Ahh, ok.
I'll make the "cleanup" thing just remove strange characters from the end,
that should fix this kind of thing for now.
I'd just remove everything after the first strange number, but I can also
see people using the "lastname, firstname" format, and I'd hate to just
ignore firstname in that case.
Linus
^ permalink raw reply
* Re: Building git on Fedora
From: Chris Wedgwood @ 2005-04-17 23:35 UTC (permalink / raw)
To: jeff millar; +Cc: git
In-Reply-To: <4262F07D.4050007@adelphia.net>
On Sun, Apr 17, 2005 at 07:25:49PM -0400, jeff millar wrote:
> Here's a tidbit to enable git to compile on Fedora. Add the
> following line to /etc/rc.d/rc.local...
>
> ln -sf /lib/modules/`uname -r`/build/include/linux /usr/local/include/linux
I can't see why this should be needed. What breaks without this?
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-17 23:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linus Torvalds, mingo, simon, david.lang, git
In-Reply-To: <20050417232905.GA2721@gondor.apana.org.au>
Dear diary, on Mon, Apr 18, 2005 at 01:29:05AM CEST, I got a letter
where Herbert Xu <herbert@gondor.apana.org.au> 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 size (the number of new blobs).
No. The collision check is done in the opposite cache - when you want to
write a blob and there is already a file of the same hash in the tree.
So either the blob is already in the database, or you have a collision.
Therefore, the cost is proportional to the size of what stays unchanged.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Woodhouse @ 2005-04-17 23:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, git
In-Reply-To: <Pine.LNX.4.58.0504160953310.7211@ppc970.osdl.org>
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
> So I'd _almost_ suggest just starting from a clean slate after all.
> Keeping the old history around, of course, but not necessarily putting it
> into git now. It would just force everybody who is getting used to git in
> the first place to work with a 3GB archive from day one, rather than
> getting into it a bit more gradually.
>
> What do people think? I'm not so much worried about the data itself: the
> git architecture is _so_ damn simple that now that the size estimate has
> been confirmed, that I don't think it would be a problem per se to put
> 3.2GB into the archive. But it will bog down "rsync" horribly, so it will
> actually hurt synchronization untill somebody writes the rev-tree-like
> stuff to communicate changes more efficiently..
Note that any given copy of a tree doesn't _need_ to keep all the
history back the beginning of time. It's OK if the oldest commit object
in your tree actually refers back to a parent which doesn't exist
locally. I can well imagine that some people will want to keep their
trees pruned to keep only a few weeks of history, while other copies of
the tree will keep everything.
However, if we _don't_ base our current work on an existing import of
the kernel, then we don't retain that option. We can't just change the
'parent' field of your 2.6.12-rc2 import, without changing the sha1 hash
of _everything_ that happens thereafter.
So I'd say we should take Thomas' import, and base new work on that --
but then possibly leave out the older objects from the 'working'
repository which everyone is rsyncing from; just make them available in
a 'linux-history.git' object database elsewhere.
--
dwmw2
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Herbert Xu @ 2005-04-17 23:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mingo, pasky, simon, david.lang, git
In-Reply-To: <Pine.LNX.4.58.0504171530150.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 03:35:17PM -0700, Linus Torvalds wrote:
>
> Quite the reverse. Again, you bring up totally theoretical arguments. In
> _practice_ it has indeed been shown that using two hashes _does_ catch
> hash colissions.
>
> The trivial example is using md5 sums with a length. The "length" is a
> rally bad "hash" of the file contents too. And the fact is, that simple
> combination of hashes has proven to be more resistant to attack than the
> hash itself. It clearly _does_ make a difference in practice.
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.
> So _please_, can we drop the obviously bogus "in theory" arguments. They
> do not matter. What matters is practice.
I agree. However, what is the actual cost in practice of detecting
collisions?
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 size (the number of new blobs).
Is this really that bad considering that the average blob isn't very
big?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Brad Roberts @ 2005-04-17 23:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504171005220.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Brad Roberts wrote:
> >
> > (ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
>
> They should't, but maybe I should add COMMITTER_xxx overrides. I just do
> _not_ want people to think that they should claim to be somebody else:
> it's not a security issue (you could compile your own "commit-tree.c"
> after all), it's more of a "social rule" thing. I prefer seeing bad email
> addresses that at least match the system setup to seeing good email
> addresses that people made up just to make them look clean.
>
> Mind showing what your /etc/passwd file looks like (just your own entry,
> and please just remove your password entry if you don't use shadow
> passwords).
>
> Maybe I should just remove _all_ strange characters when I do the name
> cleanup in "commit". Right now I just remove the ones that matter to
> parsing it unambiguosly: '\n' '<' and '>'.
>
> (The ',' character really is special: some people have
>
> Torvalds, Linus
>
> and maybe I should not just remove the commas, I should convert it to
> always be "Linus Torvalds". But your gecos entry is just _strange_. Why
> the extra commas, I wonder?)
>
> Linus
> -
I fully agree with the intent of the field separation, they're two very
different activities.
braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
All gecos entries on all my debian boxes are of the form:
fullname, office number, office extension, and home number
This is taken from the chfn man page on debian. Looking on my nearest
redhat box, the chfn man page is roughly the same. Debian's man page also
has one snippit that's not in redhat's, suggested delimiter is a ','. A
bit of searching for other platforms, aix suggests a ';' as a delimiter.
HPUX seems to want a ','.
Later,
Brad
^ permalink raw reply
* Building git on Fedora
From: jeff millar @ 2005-04-17 23:25 UTC (permalink / raw)
To: git
Here's a tidbit to enable git to compile on Fedora. Add the following
line to /etc/rc.d/rc.local...
ln -sf /lib/modules/`uname -r`/build/include/linux
/usr/local/include/linux
This fix creates a symlink, on each boot up, in the local include
directory that points to the kernel header files. If there's a better
way to do this, I'm all ears.
jeff
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Junio C Hamano @ 2005-04-17 23:23 UTC (permalink / raw)
To: Nomad Arton; +Cc: git
In-Reply-To: <4262E50C.2070006@lazy.shacknet.nu>
>>>>> "NA" == Nomad Arton <lkml@lazy.shacknet.nu> writes:
NA> Linus Torvalds schrieb:
>> In fact, one of my hopes was that other SCM's could just use the git
>> plumbing. But then I'd really suggest that you use "git" itself, not any
>> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
>> trying to link against individual routines, you'd _script_ it.
NA> please excuse; libgit and scripting to me arent a contradiction. many
NA> sripting languages are extended by C modules, while still happening to
NA> have all the scripting rapidity. its just a matter of how to
NA> communicate with the C code, isnt it?
You are arguing for scripting language binding like what Swig
creates. While that would also be a worthy addition, having
language binding is not the only way to do _script_.
What Linus is saying is that he wants you to talk with git
plumbing by invoking the executables he have, via system(3),
popen(3), etc.
The C-level first has to be libified before you can start
talking about host language bindings but that just started to
happen and is not ready yet. However, you can use and benefit
from GIT without waiting for that kind of integration, if you
use the "spawning the executables" approach. I agree with him.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox