* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Daniel Barkalow @ 2005-04-17 18:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417174736.GA1461@pasky.ji.cz>
Drop this one for now; I'll revisit it once more important stuff is
settled down.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-17 18:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417181054.GB1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> > Index: Makefile
> > ===================================================================
> > --- d662b707e11391f6cfe597fd4d0bf9c41d34d01a/Makefile (mode:100644 sha1:b2ce7c5b63fffca59653b980d98379909f893d44)
> > +++ 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/Makefile (mode:100644 sha1:940ef8578cf469354002cd8feaec25d907015267)
> > @@ -35,6 +35,7 @@
> >
> > LIBS= -lssl -lz
> >
> > +http-pull: LIBS += -lcurl
> >
> > $(PROG):%: %.o $(COMMON)
> > $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
>
> Whew. Looks like an awful trick, you say this works?! :-)
>
> At times, I wouldn't want to be a GNU make parser.
Yup. GNU make is big on the features which do the obvious thing, even when
you can't believe they work. This is probably why nobody's managed to
replace it.
> > Index: http-pull.c
> > ===================================================================
> > --- /dev/null (tree:d662b707e11391f6cfe597fd4d0bf9c41d34d01a)
> > +++ 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/http-pull.c (mode:100644 sha1:106ca31239e6afe6784e7c592234406f5c149e44)
> > + url = malloc(strlen(base) + 50);
>
> Off-by-one. What about the trailing NUL?
I get length(base) + "object/"=8 + 40 SHA1 + 1 for '/' and 1 for NUL = 50.
> I think you should have at least two disjunct modes - either you are
> downloading everything related to the given commit, or you are
> downloading all commit records for commit predecessors.
>
> Even if you might not want all the intermediate trees, you definitively
> want the intermediate commits, to keep the history graph contignuous.
>
> So in git pull, I'd imagine to do
>
> http-pull -c $new_head
> http-pull -t $(tree-id $new_head)
>
> So, -c would fetch a given commit and all its predecessors until it hits
> what you already have on your side. -t would fetch a given tree with all
> files and subtrees and everything. http-pull shouldn't default on
> either, since they are mutually exclusive.
>
> What do you think?
I think I'd rather keep the current behavior and add a -c for getting the
history of commits, and maybe a -a for getting the history of commits and
their tress.
There's some trickiness for the history of commits thing for stopping at
the point where you have everything, but also behaving appropriately if
you try once, fail partway through, and then try again. It's on my queue
of things to think about.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: David A. Wheeler @ 2005-04-17 18:44 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List, Peter Anvin, Andrew Morton
In-Reply-To: <20050417192000.C13233@flint.arm.linux.org.uk>
>>On Sun, 17 Apr 2005, Russell King wrote:
>>>>One thing which definitely needs to be considered is - what character
>>>>encoding are the comments to be stored as?
...
I replied:
>>I would _heartily_ recommend moving towards UTF-8 as the
>>internal charset for all comments.
Petr said:
>Not that the plumbing should actually _care_ at all; anyone who uses it
>should take the care, so this is more of a "social" thing.
The _plumbing_ shouldn't care, but the stuff above needs to know
how to interpret the stuff that the plumbing produces.
Russell King said:
> Except, I believe, MicroEMACS, which both Linus and myself use. As
> far as I know, there aren't any patches to make it UTF-8 compliant.
Since plain ASCII is a subset of UTF-8,
as long as MicroEMACS users only create ASCII comments,
then the comments you create in MicroEMACS will still be UTF-8.
No big deal.
For reading comments, if the text is almost entirely
plain ASCII, you could just ignore the problem and have the
occasional character scramble. If you need more, you'll
need a tool that's more internationalized or a working iconv,
but if that's important you'd be motivated.
Again, I'm looking for more generalized solutions, where
non-English comments are more common than in Linux kernel code.
--- David A. Wheeler
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Petr Baudis @ 2005-04-17 18:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.58.0504171114020.7211@ppc970.osdl.org>
Dear diary, on Sun, Apr 17, 2005 at 08:18:47PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >
> > --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644 sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
> > +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644 sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
> > @@ -24,6 +24,7 @@
> > unsigned int flags;
> > unsigned char sha1[20];
> > unsigned long date;
> > + unsigned char tree[20];
> > struct parent *parent;
> > };
> >
>
> I think this is really wrong.
>
> The whole point of "revision.h" is that it's a generic framework for
> keeping track of relationships between different objects. And those
> objects are in no way just "commit" objects.
Someone started the avalanche by adding date to the structure. Of
course, date is smaller, but it leads people (including me) out of the
way.
Perhaps struct commit which will have struct revision (ugh - what about
rather struct object?) as a member?
> For example, fsck uses this "struct revision" to create a full free of
> _all_ the object dependencies, which means that a "struct revision" can be
> any object at all - it's not in any way limited to commit objects, and
> there is no "tree" object that is associated with these things at all.
That's some really bad naming then.
> Besides, why do you want the tree? There's really nothing you can do with
> the tree to a first approximation - you need to _first_ do the
> reachability analysis entirely on the commit dependencies, and then when
> you've selected a set of commits, you can just output those.
>
> Later phases will indeed look up what the tree is, but that's only after
> you've decided on the commit object. There's no point in looking up (or
> even trying to just remember) _all_ the tree objects.
The goal was to have a commit record parser which would spit out this
structure containing all the relevant info, but I can agree that wasting
memory with it makes no sense. Perhaps it could take a possibly-NULL
buffer pointer where it would drop the tree ID, Daniel?
--
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: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 18:20 UTC (permalink / raw)
To: David A. Wheeler
Cc: Linus Torvalds, Git Mailing List, Peter Anvin, Andrew Morton
In-Reply-To: <4262A767.4040300@dwheeler.com>
On Sun, Apr 17, 2005 at 02:13:59PM -0400, David A. Wheeler wrote:
> On Sun, 17 Apr 2005, Russell King wrote:
> >>BTW, there appears to be "errors" in the history committed thus far.
> >>I'm not sure where this came from though. Some of them could be
> >>UTF8 vs ASCII issues, ....>
> ...
> >>One thing which definitely needs to be considered is - what character
> >>encoding are the comments to be stored as?
>
> Linus Torvalds replied:
> > To git, it's just a byte stream, and you can have binary comments if you
> > want to. I personally would prefer to move towards UTF eventually, but I
> > really don't think it matters a whole lot as long as 99.9% of everything
> > we'd see there is still 7-bit ascii.
>
> I would _heartily_ recommend moving towards UTF-8 as the
> internal charset for all comments. Alternatives are possible
> (e.g., recording the charset in the header), but they're
> incredibly messy. Even if you don't normally work in UTF-8,
> it's pretty easy to set most editors up to read & write UTF-8.
> Having the data stored as a constant charset eliminates
> a raft of error-prone code.
Except, I believe, MicroEMACS, which both Linus and myself use. As
far as I know, there aren't any patches to make it UTF-8 compliant.
The alternative is, I suppose, iconv. However, iconv in _my_ glibc
seems buggy (segfaults) and my efforts for building glibc 2.3.2 for
ARM have failed. Effectively that means iconv is inaccessible to
me.
--
Russell King
^ permalink raw reply
* Re: Yet another base64 patch
From: Petr Baudis @ 2005-04-17 18:19 UTC (permalink / raw)
To: David A. Wheeler; +Cc: Paul Jackson, git
In-Reply-To: <42620452.4080809@dwheeler.com>
Dear diary, on Sun, Apr 17, 2005 at 08:38:10AM CEST, I got a letter
where "David A. Wheeler" <dwheeler@dwheeler.com> told me that...
> I'd look at some of the more constraining, yet still
> common cases, and make sure it worked reasonably
> well without requiring magic. My list would be:
> ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
> case-insensitive/case-preserving). Samba shouldn't be
> more constraining than NTFS, and I would expect ReiserFS
> wouldn't be a constraining case. Bonus points if the
> names lengths are inside POSIX guarantees, but I bet the
> POSIX limits are so tiny as to be laughable. Bonus points for
> CD-ROM format with the Rock Ridge extensions (I _think_ DVDs
> and later use that format too, yes?), though if that
> didn't work tar files are an easy workaround. Imagine a full
> Linux kernel source repository, for 30+ (pick a number) years..
> can the filesystems handle the number of objects in those cases?
> If it works, your infrastructure should be sufficiently
> portable to "just work" on others too.
I personally don't mind getting it work on more places, if it doesn't
make git work (measurably) worse on modern Linux systems, the code will
not go to hell, you tell me what needs to be done and preferably give me
the patches. ;-)
--
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: [1/5] Parsing code in revision.h
From: Linus Torvalds @ 2005-04-17 18:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504171120400.30848-100000@iabervon.org>
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>
> --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644 sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
> +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644 sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
> @@ -24,6 +24,7 @@
> unsigned int flags;
> unsigned char sha1[20];
> unsigned long date;
> + unsigned char tree[20];
> struct parent *parent;
> };
>
I think this is really wrong.
The whole point of "revision.h" is that it's a generic framework for
keeping track of relationships between different objects. And those
objects are in no way just "commit" objects.
For example, fsck uses this "struct revision" to create a full free of
_all_ the object dependencies, which means that a "struct revision" can be
any object at all - it's not in any way limited to commit objects, and
there is no "tree" object that is associated with these things at all.
Besides, why do you want the tree? There's really nothing you can do with
the tree to a first approximation - you need to _first_ do the
reachability analysis entirely on the commit dependencies, and then when
you've selected a set of commits, you can just output those.
Later phases will indeed look up what the tree is, but that's only after
you've decided on the commit object. There's no point in looking up (or
even trying to just remember) _all_ the tree objects.
Hmm?
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-17 18:14 UTC (permalink / raw)
To: David A. Wheeler
Cc: Linus Torvalds, Russell King, Git Mailing List, Peter Anvin,
Andrew Morton
In-Reply-To: <4262A767.4040300@dwheeler.com>
Dear diary, on Sun, Apr 17, 2005 at 08:13:59PM CEST, I got a letter
where "David A. Wheeler" <dwheeler@dwheeler.com> told me that...
> On Sun, 17 Apr 2005, Russell King wrote:
> >>BTW, there appears to be "errors" in the history committed thus far.
> >>I'm not sure where this came from though. Some of them could be
> >>UTF8 vs ASCII issues, ....>
> ...
> >>One thing which definitely needs to be considered is - what character
> >>encoding are the comments to be stored as?
>
> Linus Torvalds replied:
> >To git, it's just a byte stream, and you can have binary comments if you
> >want to. I personally would prefer to move towards UTF eventually, but I
> >really don't think it matters a whole lot as long as 99.9% of everything
> >we'd see there is still 7-bit ascii.
>
> I would _heartily_ recommend moving towards UTF-8 as the
> internal charset for all comments. Alternatives are possible
> (e.g., recording the charset in the header), but they're
> incredibly messy. Even if you don't normally work in UTF-8,
> it's pretty easy to set most editors up to read & write UTF-8.
> Having the data stored as a constant charset eliminates
> a raft of error-prone code.
I tend to agree here. My toilet stuff is what can handle various
locale-based conversions at the commit-tree / cat-file tree sides etc,
but UTF-8 should be certainly the way to go internally.
Not that the plumbing should actually _care_ at all; anyone who uses it
should take the care, so this is more of a "social" thing.
--
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: Re-done kernel archive - real one?
From: David A. Wheeler @ 2005-04-17 18:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Russell King, Git Mailing List, Peter Anvin, Andrew Morton
In-Reply-To: <Pine.LNX.4.58.0504170937020.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Russell King wrote:
>>BTW, there appears to be "errors" in the history committed thus far.
>>I'm not sure where this came from though. Some of them could be
>>UTF8 vs ASCII issues, ....>
...
>>One thing which definitely needs to be considered is - what character
>>encoding are the comments to be stored as?
Linus Torvalds replied:
> To git, it's just a byte stream, and you can have binary comments if you
> want to. I personally would prefer to move towards UTF eventually, but I
> really don't think it matters a whole lot as long as 99.9% of everything
> we'd see there is still 7-bit ascii.
I would _heartily_ recommend moving towards UTF-8 as the
internal charset for all comments. Alternatives are possible
(e.g., recording the charset in the header), but they're
incredibly messy. Even if you don't normally work in UTF-8,
it's pretty easy to set most editors up to read & write UTF-8.
Having the data stored as a constant charset eliminates
a raft of error-prone code.
--- David A. Wheeler
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Petr Baudis @ 2005-04-17 18:10 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171127160.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 05:31:16PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> http-pull is a program that downloads from a (normal) HTTP server a commit
> and all of the tree and blob objects it refers to (but not other commits,
> etc.). Options could be used to make it download a larger or different
> selection of objects. It depends on libcurl, which I forgot to mention in
> the README again.
>
> Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
So, while you will be resending the patch, please update the README.
> Index: Makefile
> ===================================================================
> --- d662b707e11391f6cfe597fd4d0bf9c41d34d01a/Makefile (mode:100644 sha1:b2ce7c5b63fffca59653b980d98379909f893d44)
> +++ 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/Makefile (mode:100644 sha1:940ef8578cf469354002cd8feaec25d907015267)
> @@ -35,6 +35,7 @@
>
> LIBS= -lssl -lz
>
> +http-pull: LIBS += -lcurl
>
> $(PROG):%: %.o $(COMMON)
> $(CC) $(CFLAGS) -o $@ $^ $(LIBS)
Whew. Looks like an awful trick, you say this works?! :-)
At times, I wouldn't want to be a GNU make parser.
> Index: http-pull.c
> ===================================================================
> --- /dev/null (tree:d662b707e11391f6cfe597fd4d0bf9c41d34d01a)
> +++ 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/http-pull.c (mode:100644 sha1:106ca31239e6afe6784e7c592234406f5c149e44)
> @@ -0,0 +1,126 @@
> + if (!stat(filename, &st)) {
> + return 0;
> + }
access()
> + url = malloc(strlen(base) + 50);
Off-by-one. What about the trailing NUL?
> + strcpy(url, base);
> + posn = url + strlen(base);
> + strcpy(posn, "objects/");
> + posn += 8;
> + memcpy(posn, hex, 2);
> + posn += 2;
> + *(posn++) = '/';
> + strcpy(posn, hex + 2);
> +static int process_tree(unsigned char *sha1)
> +{
> + void *buffer;
> + unsigned long size;
> + char type[20];
> +
> + buffer = read_sha1_file(sha1, type, &size);
Something with your whitespaces is wrong here. ;-)
> + fetch(rev->tree);
> + process_tree(rev->tree);
> + fetch(sha1);
> + process_commit(sha1);
You are ignoring return codes of own routines everywhere.
You should use error() instead of plain -1, BTW.
I think you should have at least two disjunct modes - either you are
downloading everything related to the given commit, or you are
downloading all commit records for commit predecessors.
Even if you might not want all the intermediate trees, you definitively
want the intermediate commits, to keep the history graph contignuous.
So in git pull, I'd imagine to do
http-pull -c $new_head
http-pull -t $(tree-id $new_head)
So, -c would fetch a given commit and all its predecessors until it hits
what you already have on your side. -t would fetch a given tree with all
files and subtrees and everything. http-pull shouldn't default on
either, since they are mutually exclusive.
What do you think?
--
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: [PATCH] use gcrypt instead of libssl for hash
From: Linus Torvalds @ 2005-04-17 17:52 UTC (permalink / raw)
To: Junichi Uekawa; +Cc: git
In-Reply-To: <87hdi5oet6.dancerj@netfort.gr.jp>
On Sun, 17 Apr 2005, Junichi Uekawa wrote:
>
> This is the first time for me to send you a patch; be gentle.
> the following patch allows for use of gcrypt.
Well, libgcrypt seems to be pretty rare out there - I certainly don't have
it installed on my machine.
> libssl seems to have a restrictive licensing wrt GPL applications.
It does? I really don't read it that way.
The openssl license is BSD+mention, but it only kicks in if you
_redistribute_ it (and you're not allowed to market things as being
openssl based without giving them credit, but that's another thing).
So yes, the openssl license is incompatible with the GPL in the sense that
you cannot actually _mix_ the openssl source-code with the GPL
source-code. But that's true of a lot of libraries, the normal system C
library being just one common example.
The GPL makes explicit mention of the system libraries (which openssl
definitely is by now), so it's ok by the GPL . And I don't see how you'd
claim that the openssl license doesn't allow it. So it all looks ok by me.
That said, if somebody wants to abstract this out, and have a simple "sign
with sha1" interface that can be used with both openssl and libgcrypt (or
any other crypt license), then hey, go wild. Or merge the SHA1 code from
the kernel, even, and make the project entirely self-sufficient.
But requiring libgcrypt seems silly. Especially as the libgcrypt
interfaces are horribly ugly, much more so than the openssl ones - so even
if you use libgcrypt, you don't actually want to use it directly, you want
to have much nicer wrappers around it.
Linus
^ permalink raw reply
* Re: Yet another base64 patch
From: David A. Wheeler @ 2005-04-17 17:51 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050417011615.3e7dfb29.pj@sgi.com>
Paul Jackson wrote:
> David wrote:
>
>>My list would be:
>>ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
>>case-insensitive/case-preserving).
>
>
> I'm no mind reader, but I'd bet a pretty penny that what you have in
> mind and what Linus has in mind have no overlaps in their solution sets.
Sadly, I lack the mind reading ability as well.
Our goals are, I suspect, somewhat different.
Linus wants to build a tool that meets his specific needs
(managing kernel development), and he has particular requirements
(such as fast simple merging when working at large scales).
In contrast, I'm hoping for a more
general OSS/FS SCM tool that many others can use as well.
But I think there's heavy overlap in the solution space.
The Linux kernel project is, to my knowledge, the largest
project using a truly distributed SCM process.
Anyone else who is considering a distributed SCM process
would at _least_ want to think about how the Linux kernel
project works, and if they're doing so, they
might also want to reuse the development tools.
I'm just taking a peek, and
looking for situations where a design decision is irrelevant
for his purposes, but a particular direction would be of
particular help to other projects. I'm more worried about the
storage format; if the code doesn't support some particular
feature but it could be added later without great pain, no big deal.
If something would imply a complete rewrite, that's undesirable.
--- David A. Wheeler
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Petr Baudis @ 2005-04-17 17:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171131230.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 05:35:19PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> Index: checkout-cache.c
> ===================================================================
> --- 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/checkout-cache.c (mode:100644 sha1:5d3028df0a45329e45fff2006719c9267adeb946)
> +++ 08f7700831e056ad710af69f91e3a8a705b6b2b1/checkout-cache.c (mode:100644 sha1:338588259e17dd235fdc7db759d770004a760e15)
> @@ -67,6 +71,80 @@
> return fd;
> }
>
> +#ifdef HARDLINK_CACHE
> +
> +/*
> + * NOTE! This returns a statically allocated buffer, so you have to be
> + * careful about using it. Do a "strdup()" if you need to save the
> + * filename.
> + */
> +char *sha1_blob_cache_file_name(const unsigned char *sha1)
> +{
..code basically identical with sha1_file_name()..
> +}
You can guess what would I like you to do. ;-)
> +
> +static int write_entry(struct cache_entry *ce)
> +{
> + int fd;
> + void *new;
> + unsigned long size;
> + long wrote;
> + char type[20];
> + char *cache_name;
> + struct stat st;
> +
> + cache_name = sha1_blob_cache_file_name(ce->sha1);
> +
> + if (stat(cache_name, &st)) {
..basically cut'n'paste of non-hardlinking write_entry()..
BTW, I'd just use access(F_OK) instead of stat() it I don't care about
the file's stat at all anyway.
> + }
> + if (link(cache_name, ce->name)) {
> + if (errno == ENOENT) {
> + create_directories(ce->name);
> + link(cache_name, ce->name);
> + }
> + }
> + return 0;
> +}
I think it would be better to have this as hardlink_entry() and
write_entry() to take the file name to write the entry to. Then you
should explicitly multiplex in checkout_cache() between what you do.
--
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: Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-17 17:34 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Petr Baudis, Simon Fowler, David Lang, git
In-Reply-To: <20050417152841.GA6157@elte.hu>
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 object.
I really hate theoretical discussions.
The fact is, a lot of _crap_ engineering gets done because of the question
"what if?". It results in over-engineering, often to the point where the
end result is quite a lot measurably worse than the sane results.
You are _literally_ arguing for the equivalent of "what if a meteorite hit
my plane while it was in flight - maybe I should add three inches of
high-tension armored steel around the plane, so that my passengers would
be protected".
That's not engineering. That's five-year-olds discussing building their
imaginary forts ("I want gun-turrets and a mechanical horse one mile high,
and my command center is 5 miles under-ground and totally encased in 5
meters of lead").
I absolutely _hate_ doing engineering on the principle of "this might be
possible in theory", and I'm violently opposed to it. So far, I have not
heard a single argument that I consider even _remotely_ likely.
The thing is, even if you can force a hash collission by sending somebody
a patch, it's really pretty much almost guaranteed that the patch is not
just "a few strange characters", unless sha1 is really broken to the point
where it's not cryptographically secure _at_all_.
In other words, unless somebody finds a way to make sha1 appear as nothing
more than a complicated set of parity bits, all brute-force "get the same
sha1" is likely to be about generating a really strange blob based on the
thing you want to replace - and by "really strange" I mean total binary
crap. And likely _much_ bigger too. And by "much bigger" I mean "possibly
gigabytes of data".
And the thing is, _if_ somebody finds a way to make sha1 act as just a
complex parity bit, and comes up with generating a clashing object that
actually makes sense, then going to sha256 is likely pointless too - I
think the algorithm is basically the same, just with more bits. If you've
broken sha1 to the point where it's _that_ breakable, then you've likely
broken sha256 too. Nobody has ever proven that you couldn't break sha256
with some really clever algorithm...
So if you start playing "what if?" games, dammit, I can play mine.
If we want to have any kind of confidence that the hash is reall
yunbreakable, we should make it not just longer than 160 bits, we should
make sure that it's two or more hashes, and that they are based on totally
different principles.
And we should all digitally sign every single object too, and we should
use 4096-bit PGP keys and unguessable passphrases that are at least 20
words in length. And we should then build a bunker 5 miles underground,
encased in lead, so that somebody cannot flip a few bits with a ray-gun,
and make us believe that the sha1's match when they don't. Oh, and we need
to all wear aluminum propeller beanies to make sure that they don't use
that ray-gun to make us do the modification _outselves_.
And the thing is, that's just crazy talk. The difference between a crazy
person and an intelligent one is that the crazy one doesn't realize what
makes sense in the world. The goal of good engineering is not to ask "what
if?", but to ask "how do I make this work as well as possible".
So please stop with the theoretical sha1 attacks. It is simply NOT TRUE
that you can generate an object that looks halfway sane and still gets you
the sha1 you want. Even the "breakage" doesn't actually do that. And if
it ever _does_ become true, it will quite possibly be thanks to some
technology that breaks other hashes too.
So until proven otherwise, I worry about accidental hashes, and in 160
bits of good hashing, that just isn't an issue either. Anybody who
compares a 128-bit md5-sum to a 160-bit sha1 doesn't understand the math.
It didn't get "slightly less likely" to happen. It got so _unbelievably_
less likely to happen that it's not even funny.
Linus
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Daniel Barkalow @ 2005-04-17 17:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brad Roberts, 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.
It seems to me like there should be a set of variables for the user in
general, and the various git scripts should arrange them appropriately
(e.g., git apply could look for a first Signed-Off-By, and make the
AUTHOR_ variables match that (for the next commit), while making the
COMMITTER match the user, etc). It seems to me like the current situation
is likely to lead to people claiming to be other people when applying
their patches, just due to having set up their correct info for handling
their own patches.
Actually, if the scripts are reorganizing them, they might as well send
them on the command line.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Linus Torvalds @ 2005-04-17 17:13 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504170451030.2625-100000@bellevue.puremagic.com>
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
^ permalink raw reply
* [2.1/5] Add merge-base
From: Daniel Barkalow @ 2005-04-17 16:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171124340.30848-100000@iabervon.org>
merge-base finds one of the best common ancestors of a pair of commits. In
particular, it finds one of the ones which is fewest commits away from the
further of the heads.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: Makefile
===================================================================
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/Makefile (mode:100644 sha1:346e3850de026485802e41e16a1180be2df85e4a)
+++ 7d806c2d3be8f87d3d4d87e5254500d7fc24476b/Makefile (mode:100644 sha1:0e84e3cd12f836602b420c197e08fabefe975493)
@@ -14,7 +17,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
- check-files ls-tree
+ check-files ls-tree merge-base
SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
Index: merge-base.c
===================================================================
--- /dev/null (tree:45f926575d2c44072bfcf2317dbf3f0fbb513a4e)
+++ 7d806c2d3be8f87d3d4d87e5254500d7fc24476b/merge-base.c (mode:100644 sha1:ee979c7532cbdf823e9930993b0dd8f97aadb21f)
@@ -0,0 +1,95 @@
+#include <stdlib.h>
+#include "cache.h"
+#include "revision.h"
+
+static struct revision *process_list(struct parent **list_p, int this_mark,
+ int other_mark)
+{
+ struct parent *parent, *temp;
+ struct parent *posn = *list_p;
+ *list_p = NULL;
+ while (posn) {
+ parse_commit_object(posn->parent);
+ if (posn->parent->flags & this_mark) {
+ /*
+ printf("%d already seen %s %x\n",
+ this_mark
+ sha1_to_hex(posn->parent->sha1),
+ posn->parent->flags);
+ */
+ /* do nothing; this indicates that this side
+ * split and reformed, and we only need to
+ * mark it once.
+ */
+ } else if (posn->parent->flags & other_mark) {
+ return posn->parent;
+ } else {
+ /*
+ printf("%d based on %s\n",
+ this_mark,
+ sha1_to_hex(posn->parent->sha1));
+ */
+ posn->parent->flags |= this_mark;
+
+ parent = posn->parent->parent;
+ while (parent) {
+ temp = malloc(sizeof(struct parent));
+ temp->next = *list_p;
+ temp->parent = parent->parent;
+ *list_p = temp;
+ parent = parent->next;
+ }
+ }
+ posn = posn->next;
+ }
+ return NULL;
+}
+
+struct revision *common_ancestor(struct revision *rev1, struct revision *rev2)
+{
+ struct parent *rev1list = malloc(sizeof(struct parent));
+ struct parent *rev2list = malloc(sizeof(struct parent));
+
+ rev1list->parent = rev1;
+ rev1list->next = NULL;
+
+ rev2list->parent = rev2;
+ rev2list->next = NULL;
+
+ while (rev1list || rev2list) {
+ struct revision *ret;
+ ret = process_list(&rev1list, 0x1, 0x2);
+ if (ret) {
+ /* XXXX free lists */
+ return ret;
+ }
+ ret = process_list(&rev2list, 0x2, 0x1);
+ if (ret) {
+ /* XXXX free lists */
+ return ret;
+ }
+ }
+ return NULL;
+}
+
+int main(int argc, char **argv)
+{
+ struct revision *rev1, *rev2, *ret;
+ unsigned char rev1key[20], rev2key[20];
+
+ if (argc != 3 ||
+ get_sha1_hex(argv[1], rev1key) ||
+ get_sha1_hex(argv[2], rev2key)) {
+ usage("merge-base <commit-id> <commit-id>");
+ }
+ rev1 = lookup_rev(rev1key);
+ rev2 = lookup_rev(rev2key);
+ ret = common_ancestor(rev1, rev2);
+ if (ret) {
+ printf("%s\n", sha1_to_hex(ret->sha1));
+ return 0;
+ } else {
+ return 1;
+ }
+
+}
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Mike Taht @ 2005-04-17 16:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Roundy, git, darcs-devel
In-Reply-To: <Pine.LNX.4.58.0504170916080.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 17 Apr 2005, David Roundy wrote:
>
>>That's all right. Darcs would only access the cached data through a
>>git-caching layer, and we've already got an abstraction layer over the
>>pristine cache. As long as the git layer can quickly retrieve the contents
>>of a given file, we should be fine.
>
>
> Yes.
>
> 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.
If you don't want it, I won't do it. Still makes sense to separate the
plumbing from the porcelain, though.
--
Mike Taht
"You can tell how far we have to go, when FORTRAN is the language of
supercomputers.
-- Steven Feiner"
^ permalink raw reply
* Re: Parseable commit header
From: David A. Wheeler @ 2005-04-17 16:49 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: git
In-Reply-To: <20050417062236.GA3261@scotty.home>
Stefan-W. Hahn wrote:
> Hi,
>
> after playing a while with git-pasky it is a crap to interpret the date of
> commit logs. Though it was a good idea to put the date in a parseable format
> (seconds since), but the format of the commit itself is not good parseable.
> Should be:
...
> Committer-Dater: 1113684324 +0200
I'm probably coming in late to the game, but exactly
why is seconds-since-epoch format used instead of a format
more easily understood by humans? Yes, I know tools
can easily convert that, but you're already using an ASCII format;
why not just record it in a format that's easily eyeballed like ISO's
yyyymmddThhmmss [timezone]? E.G.:
20050417T171520 +0200
or some such? I'm SURE that people will mention things
like "the patch I posted on April 17, 2005", and having the
patch format record times that way, directly, would be convenient
to the poor slobs^H^H^H^H^H developers who come later.
Yes, a tool can handle the conversion, but choosing formats
so a tool is unneeded for simple stuff is often better....!
--- David A. Wheeler
^ permalink raw reply
* Re: Parsing code in revision.h
From: Daniel Barkalow @ 2005-04-17 16:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417160929.GJ1487@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 05:24:20PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > This adds support to revision.h for parsing commit records (but not going
> > any further than parsing a single record). Something like this is needed
> > by anything that uses revision.h, but older programs open-code it.
> >
> > Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
>
> Could you please convert the current users (rev-tree.c and fsck-cache.c)
> to use this in the same patch?
They do things somewhat differently, so it would be more intrusive. Could
I send an extra patch to convert them instead of doing them here?
> > Index: revision.h
> > ===================================================================
> > --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644 sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
> > +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644 sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
> > @@ -24,6 +24,7 @@
> > unsigned int flags;
> > unsigned char sha1[20];
> > unsigned long date;
> > + unsigned char tree[20];
> > struct parent *parent;
> > };
> >
> > @@ -111,4 +112,29 @@
> > }
> > }
> >
> > +static int parse_commit_object(struct revision *rev)
> > +{
> > + if (!(rev->flags & SEEN)) {
> > + void *buffer, *bufptr;
> > + unsigned long size;
> > + char type[20];
> > + unsigned char parent[20];
> > +
> > + rev->flags |= SEEN;
> > + buffer = bufptr = read_sha1_file(rev->sha1, type, &size);
> > + if (!buffer || strcmp(type, "commit"))
> > + return -1;
> > + get_sha1_hex(bufptr + 5, rev->tree);
> > + bufptr += 46; /* "tree " + "hex sha1" + "\n" */
> > + while (!memcmp(bufptr, "parent ", 7) &&
> > + !get_sha1_hex(bufptr+7, parent)) {
> > + add_relationship(rev, parent);
> > + bufptr += 48; /* "parent " + "hex sha1" + "\n" */
> > + }
> > + //rev->date = parse_commit_date(bufptr);
>
> I don't like this.
Yeah, that's left over from the not-quite the same parsing code in the
other programs.
> > + free(buffer);
> > + }
> > + return 0;
> > +}
> > +
> > #endif /* REVISION_H */
>
> BTW, I think that in longer term having this stuffed in revision.h is a
> bad idea, we should have revision.c. I will accept patches putting the
> stuff to revision.h for now, though (unless it gets outrageous).
I'd actually like to make them commit.{c,h}, since the system calls the
things they actually deal in commits, not revisions. But this is getting
into stuff that's likely to cause painful divergance from Linus's repo,
which is why I'm a bit leary of actually doing it now.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 16:44 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List, Peter Anvin, Andrew Morton
In-Reply-To: <20050417170539.B13233@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> BTW, there appears to be "errors" in the history committed thus far.
> I'm not sure where this came from though. Some of them could be
> UTF8 vs ASCII issues, but there's a number which seem to have extra
> random crap in them ("^M)" and lots of blank lines).
Ah, yes. That is actually from the original emails from Andrew. I do not
know why, but I see them there. It's his script that does something
strange.
(Andrew: in case you care, the first one is
[patch 003/198] arm: fix SIGBUS handling
which has the email looking like
...
From: akpm@osdl.org
Date: Tue, 12 Apr 2005 03:30:35 -0700
Status:
X-Status:
X-Keywords:
^M)
From: Russell King <rmk+lkml@arm.linux.org.uk>
ARM wasn't raising a SIGBUS with a siginfo structure. Fix
__do_user_fault() to allow us to use it for SIGBUS conditions, and arrange
for the sigbus path to use this.
...
> One thing which definitely needs to be considered is - what character
> encoding are the comments to be stored as?
To git, it's just a byte stream, and you can have binary comments if you
want to. I personally would prefer to move towards UTF eventually, but I
really don't think it matters a whole lot as long as 99.9% of everything
we'd see there is still 7-bit ascii.
> ID: 75f86bac962b7609b0f3c21d25e10647ff8ed280
> [PATCH] intel8x0: AC'97 audio patch for Intel ESB2
>
> This patch adds the Intel ESB2 DID's to the intel8x0.c file for AC'97 audio
> support.
>
> Signed-off-by: <A0>Jason Gaston <Jason.d.gaston@intel.com>
That <A0> is also there in Andrew's original email. It's "space with the
high bit set", and I have no idea why.
Linus
^ permalink raw reply
* Re: Add merge-base
From: Daniel Barkalow @ 2005-04-17 16:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417160106.GI1487@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 05:27:13PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > merge-base finds one of the best common ancestors of a pair of commits. In
> > particular, it finds one of the ones which is fewest commits away from the
> > further of the heads.
>
> What does it return when I have
>
> A -- C
> \/ \
> /\ /
> B -- D
>
> ? >:)
>
> I assume just either A or B, randomly?
Essentially, yes.
> I think it would be best if it could list all the "first-class" matches
> (both A and B in this case), each on a separate line; this way the
> overlay tools could choose an algorithm to evaluate those further as
> they see fit - e.g. sort them by time (you might aid that by listing the
> commit time in front of them), then take the first n and try to diff
> them all and take the one with least changes (as suggested by Linus).
It's actually kind of tricky to get all of the "best" ancestors without
getting any useless ancestors; the "best" criterion is maintained in the
current version by stopping as soon as possible.
I think that the real solution would be to have a merge program that
interacts back and forth with the revision history processor, since I
think that merges for which the choice of ancestor matters (for whether it
gives a conflict) would benefit most directly and clearly from figuring
out the histories of the conflicting changes, not choosing different
ancestors.
If someone comes up with an algorithm that wants an alternative ancestor
rather than more interactive stuff, I can work on getting a complete list.
> > Index: merge-base.c
> > ===================================================================
> > --- /dev/null (tree:37a0b01b85c2999243674d48bfc71cdba0e5518e)
> > +++ d662b707e11391f6cfe597fd4d0bf9c41d34d01a/merge-base.c (mode:100644 sha1:0f85e7d9e9a896d1142a54170ddf1159f11f9cdd)
> > @@ -0,0 +1,108 @@
> > +#include <stdlib.h>
> > +#include "cache.h"
> > +#include "revision.h"
> > +
> > +struct revision *common_ancestor(struct revision *rev1, struct revision *rev2)
> > +{
> > + struct parent *parent;
> > +
> > + struct parent *rev1list = malloc(sizeof(struct parent));
> > + struct parent *rev2list = malloc(sizeof(struct parent));
>
> Did I overlook anything or you could have just a single revlist?
I tried with just one, but I couldn't keep it straight in my
head. rev1list holds the unmarked ancestors of rev1; rev2list holds the
unmarked ancestors of rev2.
> > + struct parent *posn, *temp;
> > +
> > + rev1list->parent = rev1;
> > + rev1list->next = NULL;
> > +
> > + rev2list->parent = rev2;
> > + rev2list->next = NULL;
> > +
> > + while (rev1list || rev2list) {
> > + posn = rev1list;
> > + rev1list = NULL;
> > + while (posn) {
> > + parse_commit_object(posn->parent);
> > + if (posn->parent->flags & 0x0001) {
> > + /*
> > + printf("1 already seen %s %x\n",
> > + sha1_to_hex(posn->parent->sha1),
> > + posn->parent->flags);
> > + */
> > + // do nothing
>
> Mostly for consistency, I'd prefer you to use /* */ comments in general.
Sure.
> I think a terrified squeak at stderr in this situation (possibly
> suggesting fsck-cache) might be appropriate.
No, this is normal; it indicates that tree 1 has a recent little merge:
orig --------------- tree 2
\
--- X -- Y -- Z -- tree 1
\ /
-- A --
When we see X for A, we've already seen it for Y, but that's fine. I get
this case when I merge with you after you merge twice with Linus since I
last merged.
> > + } else if (posn->parent->flags & 0x0002) {
> > + // XXXX free lists
>
> Hmm, so, why not free the lists?
Ah, details; mainly, I want to wait until revision.h is cleaner before
fixing this sort of thing.
> Symmetrical notes apply to this half. Actually, they are too similar.
> What about factoring them to a common function?
Sure.
Fixed version to follow.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 16:36 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <20050417162448.A13233@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
> > So I re-created the dang thing (hey, it takes just a few minutes), and
> > pushed it out, and there's now an archive on kernel.org in my public
> > "personal" directory called "linux-2.6.git". I'll continue the tradition
> > of naming git-archive directories as "*.git", since that really ends up
> > being the ".git" directory for the checked-out thing.
>
> We need to work out how we're going to manage to get our git changes to
> you. At the moment, I've very little idea how to do that. Ideas?
To me, merging is my highest priority. I suspect that once I have a tree
from you (or anybody else) that I actually _test_ merging with, I'll be
motivated as hell to make sure that my plumbing actually works.
After all, it's not just you who want to have to avoid the pain of
merging: it's definitely in my own best interests to make merging as
easy as possible. You're _the_ most obvious initial candidate, because
your merges almost never have any conflicts at all, even on a file level
(much less within a file).
> However, I've made a start to generate the necessary emails. How about
> this format?
>
> I'm not keen on the tree, parent, author and committer objects appearing
> in this - they appear to clutter it up. What're your thoughts?
Indeed. I'd almost drop the whole header except for the "author" line.
Oh, and you need a separator between commits, right now your
"Signed-off-by:" line ends up butting up with the header of the next
commit ;)
> I'd rather not have the FQDN of the machine where the commit happened
> appearing in the logs.
That's fine. Out short-logs have always tried to have just the real name
in them, and I do want an email-like thing for tracking the developer, but
yes, if you remove the email, that's fine. It should be easy enough to do
with a simple
sed 's/<.*>//'
or similar.
And if you replace "author" with "From:" and do the date conversion, it
might look more natural.
Linus
^ permalink raw reply
* Re: Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-17 16:28 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List, Peter Anvin
In-Reply-To: <20050417162448.A13233@flint.arm.linux.org.uk>
Dear diary, on Sun, Apr 17, 2005 at 05:24:48PM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> However, I've made a start to generate the necessary emails. How about
> this format?
>
> I'm not keen on the tree, parent, author and committer objects appearing
> in this - they appear to clutter it up. What're your thoughts?
I think it would look nicer if you used git log format. Actually...
> #!/bin/sh
> prev=$(cat .git/heads/origin)
> to=$(cat .git/HEAD)
It is preferred to use the commit-id command instead; when git decides
to totally dig over its metametadata storage, you won't need to care.
> this=$to
> while [ "$this" != "$prev" ]; do
> cat-file commit $this | sed 's,.*,\t&,'
> this=$(cat-file commit $this | grep ^parent | cut -d ' ' -f 2)
> done
What about adding support to git log for not caring about side branches
(if there are multiple parents, go only over the first one; you might
add that as a switch to rev-tree, which would turn it to rev-line ;-)?
Then, you could also easily implement support for passing additional
commit ID to git log, and it would then print out the range between
these two.
That would do exactly what you want, and would be probably quite usable
for other uses too.
--
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: Yet another base64 patch
From: David A. Wheeler @ 2005-04-17 16:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Paul Jackson, git
In-Reply-To: <Pine.LNX.4.21.0504171018410.30848-100000@iabervon.org>
I wrote:
>>>It's a trade-off, I know.
Paul Jackson replied:
>>So where do you recommend we make that trade-off?
Daniel Barkalow wrote:
> So why do we have to be consistant? It seems like we need a standard
> format for these reasons:
>
> - We use rsync to interact with remote repositories, and rsync won't
> understand if they aren't organized the same way. But I'm working on
> having everything go through git-specific code, which could understand
> different layouts.
>
> - Everything that shares a local repository needs to understand the
> format of that repository. But the filesystem constraints on the local
> repository will be the same regardless of who is looking, so they'd all
> expect the same format anyway.
>
> So my idea is, once we're using git-smart transfer code (which can verify
> objects, etc.), add support for different implementations of
> sha1_file_name suitable for different filesystems, and vary based either
> on a compile-time option or on a setting stored in the objects
> directory.
I think that's the perfect answer: make it a setting stored
in the objects directory (presumably set during
initialization of the directory), and handled automagically
by the tools. I recommend handling them NOT be a compile-time option,
so that the same set of tools works everywhere automatically
(who wants to recompile tools just to work on a different file layout?).
> The only thing that matters is that repositories on
> non-special web servers have a standard format, because they'll be serving
> objects by URL, not by sha1.
If the "layout info" is stored in a standard location for a
given repository, then the rest doesn't matter. The library would just
download that, then know how to find the rest.
--- David A. Wheeler
^ 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