* 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
[trimmed cc list, nobody wants to read this noise]
On Sat, Apr 16, 2005 at 11:35:39PM +0200, Brian O'Mahoney wrote:
(1) I _have_ seen real-life collisions with MD5, in the context of
Document management systems containing ~10^6 ms-WORD documents.
Dude! You could have been *famous*!
Hi,
The gecos is delimited by ',' or ';', so we should only use whatever
before the first ',' or ';' for the full name, and not just strip those.
Also, a '.' may be valid in the full name (Foo B. Zooman) or email
([EMAIL PROTECTED]).
Signed-off-by: Martin Schlemmer [EMAIL PROTECTED]
Hi,
I see the recent changes to gitdiff.sh requires you to pass -r (git diff
-r local:$tracking) even if you separate the branches via ':'. Is this
intended (seems like it)? If so, then gittrack.sh, gitpull.sh and
gitmerge.sh needs to be updated ...
(I did not want to add a patch as I am not
On Sun, 2005-04-17 at 16:39 -0700, Linus Torvalds wrote:
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
On Sun, 2005-04-17 at 19:20 +0100, Russell King wrote:
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
On Mon, 2005-04-18 at 22:35 +1000, David Woodhouse wrote:
On Mon, 2005-04-18 at 12:36 +0200, Martin Schlemmer wrote:
realgecos[strchr(realgecos, ',') - realgecos] = '\0';
Er, *strchr(realgecos, ',') = 0; surely? Even if the compiler is clever
enough to optimise out the gratuitous addition
David A. Wheeler wrote:
Does anyone know of any other issues in how git data is stored that
might cause problems for some situations? Windows' case-insensitive/
case-preserving model for NTFS and vfat32 seems to be enough
(since the case is preserved) so that the format should work,
If git
Hi
I'm just starting to look at git (and cogito).
Earlier this morning I got and built
http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2
I then did a git pull pasky and a make.
All went well.
A couple of hours later I did another git pull pasky and had the problem
shown below.
I moved
Dear diary, on Mon, Apr 18, 2005 at 03:22:43PM CEST, I got a letter
where David Greaves [EMAIL PROTECTED] told me that...
Hi
Hi,
I should release early and often. :-)
Tree change:
c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a
Tracked branch, applying
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
Tools absolutely matter. And it will take time for us to build up that
kind of helper infrastructure. So being newbie might be part of it, but
it's the smaller part, I say. Rough interfaces is a big issue.
Speaking of tools,
On Mon, 18 Apr 2005, Russell King wrote:
Ok, I just tried pulling your tree into the tree you pulled from, and
got this:
No, that can't work. The pesky tools are helpful, but they really don't do
merges worth cr*p right now, excuse my french.
The _real_ way to pull is to do the (horribly
On Mon, 18 Apr 2005 08:04:57 -0700 Greg KH wrote:
| On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
|
| Tools absolutely matter. And it will take time for us to build up that
| kind of helper infrastructure. So being newbie might be part of it, but
| it's the smaller part,
Pasky,
Looks like a couple of questions I asked over the weekend
got lost along the way.
1) How do you want me to fix the indentation on my patch
to optimize gitdiff-do script:
- forget my first patch and resend from scratch, or
- a second patch restoring indentation, on top
On Mon, 18 Apr 2005, Imre Simon wrote:
How will git handle a corrupted (git) file system?
For instance, what can be done if objects/xy/z{38} does not pass the
simple consistency test, i.e. if the file's sha1 hash is not xyz{38}?
This might be a serious problem because, in general, one
On Mon, 18 Apr 2005, Greg KH wrote:
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
Tools absolutely matter. And it will take time for us to build up that
kind of helper infrastructure. So being newbie might be part of it, but
it's the smaller part, I say. Rough
Linus wrote:
Nothing beats backups and distribution.
Famous quote from the past:
Only wimps use tape backup: real men just upload their important stuff on ftp,
and let the rest of the world mirror it ;) Linus Torvalds
--
I won't rest till it's the best ...
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
Petr Baudis wrote:
Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
[snippage]
This patch will provide the comment lines in the shell script associated
with the command, cleaned up a bit for presentation.
BUGS: This will also
On Mon, 18 Apr 2005, Linus Torvalds wrote:
No, that can't work. The pesky tools are helpful [...]
I'm afraid that until Pasky's tools script this properly, [... ]
If Pesky wants to take the above script, test it, [...]
Ok, one out of three isn't too bad, is it? Pesky/Pasky, so close yet so
On Mon, 18 Apr 2005, Andy Isaacson wrote:
If you had actual evidence of a collision, I'd love to see it - even if
it's just the equivalent of
% md5 foo
d3b07384d113edec49eaa6238ad5ff00 foo
% md5 bar
d3b07384d113edec49eaa6238ad5ff00 bar
% cmp foo bar
foo bar differ: byte 25, line 1
%
But in the
Dear diary, on Mon, Apr 18, 2005 at 07:05:19PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Mon, 18 Apr 2005, Linus Torvalds wrote:
No, that can't work. The pesky tools are helpful [...]
I'm afraid that until Pasky's tools script this properly, [... ]
Dear diary, on Mon, Apr 18, 2005 at 05:23:34PM CEST, I got a letter
where Paul Jackson [EMAIL PROTECTED] told me that...
Pasky,
Looks like a couple of questions I asked over the weekend
got lost along the way.
Yes, sorry about that; I had a lot of mail traffic lately and I'm not so
used to
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
This series introduces common parsers for objects, and ports the programs
that currently use revision.h to them.
1: the header files
2: the implementations
3: port rev-tree
4: port fsck-cache
5: port merge-base
Ok, having now looked at
On Mon, 2005-04-18 at 08:20 -0400, David Roundy wrote:
Putting darcs patches *into* git is more complicated, since we'll want to
get them back again without modification. Normal hunk patches would be
no problem, provided we never change our diff algorithm (which has been
discussed recently,
On Mon, 18 Apr 2005, James Bottomley wrote:
I had a problem with the SCSI tree in that there's a file removal in one
branch. Your git-merge-one-file-script wouldn't have handled this
correctly: It seems to think that the file must be removed in both
branches, which is wrong.
Yes, I
On Mon, Apr 18, 2005 at 10:23:32AM +0100, Russell King wrote:
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
On Sun, 17 Apr 2005, Russell King wrote:
I pulled it tonight into a pristine tree (which of course worked.)
Goodie.
Note the pristine. Now comes the real
On Mon, 18 Apr 2005, Russell King wrote:
Since this happened, I've been working out what state my tree is in,
and I restored it back to a state where I had one dangling commit head,
which was _my_ head.
For the future, if your tree gets messed up to the point where you say
screw it and
Dear diary, on Mon, Apr 18, 2005 at 11:19:46PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
I suspect that I should just pass in the SHA1 of the files to the
merge-one-file-script from merge-cache, rather than unpacking it.
After all, the merging script can do
On Mon, Apr 18, 2005 at 08:42:14AM -0700, Linus Torvalds wrote:
On Mon, 18 Apr 2005, Greg KH wrote:
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
Tools absolutely matter. And it will take time for us to build up that
kind of helper infrastructure. So being
On Mon, 18 Apr 2005, Petr Baudis wrote:
So, I'm confused. Why did you introduce unpack-file instead of doing
just this?
It was code that I already had (ie the old code from merge-cache just
moved over), and thanks to that, I don't have to worry about broken
mktemp crap in user space...
On Mon, Apr 18, 2005 at 03:05:41PM -0700, Greg KH wrote:
On Mon, Apr 18, 2005 at 08:42:14AM -0700, Linus Torvalds wrote:
On Mon, 18 Apr 2005, Greg KH wrote:
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
Tools absolutely matter. And it will take time for us
Ok, since the last one was soo successful, and I'm up for more
punishment, here's another attempt. The diffstat is rather
interesting in this one, claiming no changes. It should look
like this:
arch/arm/lib/bitops.h | 33 +
1 files changed, 33 insertions(+)
Junio C Hamano wrote:
DG It allows:
DG find src -type f | git add -
I am slow today, but have you considered using xargs?
yep thanks :)
I know you _could_ do it with xargs - but you _could_ use the raw git
commands too. This is a be nice to the user layer and I was
'surprised' that neither
DG == David Greaves [EMAIL PROTECTED] writes:
DG ... neither
DG git add .
DG nor
DG git add -r .
DG worked.
These would be much much much nicer than pipe the list of
filenames from stdin which reminds me of cpio ;-).
-
To unsubscribe from this list: send the line unsubscribe git in
the body of
Hello,
so here finally goes git-pasky-0.5, my set of scripts upon Linus
Torvald's git, which aims to provide a humanly usable interface, to a
degree similar to a SCM tool. You can get it at
http://pasky.or.cz/~pasky/dev/git/
See the READMEs etc for some introduction.
This
Dear diary, on Tue, Apr 19, 2005 at 12:18:12AM CEST, I got a letter
where David Greaves [EMAIL PROTECTED] told me that...
Junio C Hamano wrote:
DG It allows:
DG find src -type f | git add -
I am slow today, but have you considered using xargs?
yep thanks :)
I know you _could_ do
Dear diary, on Tue, Apr 19, 2005 at 12:18:07AM CEST, I got a letter
where David Greaves [EMAIL PROTECTED] told me that...
Petr Baudis wrote:
Thanks. Could you please send the patches signed off and either with
content-disposition: inline or in the mail body?
Is this OK.
Thunderbird isn't
Dear diary, on Mon, Apr 18, 2005 at 11:53:57PM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
Maybe Petr can improve the error handling, and incorporate it (or at
least some of it) into git-pasky
This does not need to touch git pull at all now; all the relevant logic
On Tue, Apr 19, 2005 at 12:48:52AM +0200, Petr Baudis wrote:
Dear diary, on Mon, Apr 18, 2005 at 11:53:57PM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
Maybe Petr can improve the error handling, and incorporate it (or at
least some of it) into git-pasky
This
On Mon, 18 Apr 2005, Greg KH wrote:
Hm, have you pushed all of the recent changes public?
Oops. Obviously not. Will fix.
Linus
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Dear diary, on Tue, Apr 19, 2005 at 12:59:52AM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
In the case I highlighted, we don't want to end up having to require
user intervention. This is a common case here, and was one which was
entirely scripted with BK.
Well,
On Mon, 18 Apr 2005, Greg KH wrote:
Anyway, I try it this way and get:
You should update to the newest version anyway..
$ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch
Applying USB: visor Tapwave Zodiac support patch
fatal: preparing to update file
This makes init-db work for common object database.
Signed-Off-By: Aaron Straus [EMAIL PROTECTED]
init-db.c: aa00fbb1b95624f6c30090a17354c9c08a6ac596
--- a/init-db.c
+++ b/init-db.c
@@ -24,7 +24,7 @@ int main(int argc, char **argv)
sha1_dir = getenv(DB_ENVIRONMENT);
if (sha1_dir)
On Tue, 19 Apr 2005, Petr Baudis wrote:
What is actually a little annoying is having to cd ,,merge and then
back, though. I don't know, but the current pull-merge script does not
bother with the temporary merge directory neither, even though Linus
wanted it. Linus, do you still do? ;-)
Patch 1/6 in the series has already cleaned the interface to
call sq_expand(), but the comment before that function still
carries the stale interface warning. Remove it.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
show-diff.c |3 ---
1 files changed, 3 deletions(-)
show-diff.c:
Hell no.
The commit _does_ specify the patch uniquely and exactly, so I really
don't see the point. You can always get the patch by just doing a
git diff $parent_tree $thistree
so putting the patch in the comment is not an option.
Er... no.
One of darcs' big points is that it has
Dear diary, on Tue, Apr 19, 2005 at 12:16:52AM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
However, it seems that git diff can't handle new files appearing
yet.
Fixed. :-)
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an
On Mon, 18 Apr 2005, James Bottomley wrote:
It looks like the merge tree has contamination from the scsi-misc-2.6
tree ... possibly because the hosting system got the merged objects when
I pushed.
Nope, the way I merge, if I get a few objects it shouldn't matter at all.
I'll just look at
On Mon, 2005-04-18 at 21:04 +, [EMAIL PROTECTED] wrote:
The other is replace very instace of identifier `foo` with identifier`bar`.
That could be derived, however, by a particularly smart parser [1].
Alternately, that itself could be embedded in the comment for patches
sourced from darcs. Of
On 4/18/05, randy_dunlap [EMAIL PROTECTED] wrote:
Here's the beginnings of yet another git usage/howto/tutorial.
It can grow or die... I'll gladly take patches for it,
or Pasky et al can merge more git plumbing and toilet usages
into it, with or without me.
On Mon, 2005-04-18 at 17:03 -0700, Linus Torvalds wrote:
The patches from you I have in my tree are:
scsi: add DID_REQUEUE to the error handling
zfcp: add point-2-point support
[PATCH] Convert i2o to compat_ioctl
[PATCH] kill old EH constants
[PATCH] scsi:
On Tue, 2005-04-19 at 10:10 +1000, David Woodhouse wrote:
On Mon, 2005-04-18 at 17:03 -0700, Linus Torvalds wrote:
Git does work like BK in the way that you cannot remove history when you
have distributed it. Once it's there, it's there.
But older history can be pruned, and there's really
On Mon, 18 Apr 2005, James Bottomley wrote:
Then the git-pull... script actually does the merge and the resulting
tree checks out against BK
So?
What do you intend to do with all the other stuff I've already put on top?
Yes, I can undo my tree, but my tree has had more stuff in it since I
Ray Lee wrote:
On Mon, 2005-04-18 at 21:04 +, [EMAIL PROTECTED] wrote:
The other is replace very instace of identifier `foo` with identifier`bar`.
That could be derived, however, by a particularly smart parser [1].
No, it can't. Seriously. A darcs replace patch is encoded as rules,
On Mon, 2005-04-18 at 18:12 -0700, Greg KH wrote:
Ok, then why display it as one?
Nobody ever displays it as one as far as I'm aware. That would be
something like mailto:$COMMITTER;
But I'll wait for Russell to wake up and start quoting the proper EU
privacy laws that he feels causes him to
On Mon, 18 Apr 2005, Junio C Hamano wrote:
I was looking at the tree part and am thinking that it would
make it much nicer if your tree object records path for each
entry.
You're entirely right, and I've actually now written the code that does
it. I'm planning to send out a patch for that
Here are the things I was saving for after the previous set:
1: Report the actual contents of trees
2: Add functions for scanning history by date
3: Add http-pull, a program to fetch the objects you need by HTTP
4: Change merge-base to find the most recent common ancestor
1 and 2 are core
This patch adds actual information to struct tree, making it possible to
tell what sorts of things the referenced objects are. This is needed for
http-pull, and Junio wanted something of the sort.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: tree.c
Functions for a date-ordered queue of commits, progressively pulled out of
the history incrementally. Linus wanted this for finding the most recent
common ancestor, and it might be relevant to logging.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: commit.c
This adds a command to pull a commit and dependant objects from an HTTP
server.
Signed-Off-By: Daniel Barkalow [EMAIL PROTECTED]
Index: Makefile
===
--- 50afb5dd4184842d8da1da8dcb9ca6a591dfc5b0/Makefile (mode:100644
Ray Lee wrote:
On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
The other is replace very instace of identifier `foo` with
identifier`bar`.
That could be derived, however, by a particularly smart parser [1].
No, it can't. Seriously. A darcs replace patch is encoded as rules, not
Dear diary, on Tue, Apr 19, 2005 at 03:54:56AM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
Index: commit.c
===
--- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.c (mode:100644
Petr Baudis wrote:
[Re: Daniel Barkalow [EMAIL PROTECTED]'s patch]
Note that you are breaking gcc-2.95 compatibility when using declarator
in the middle of a block. Not that it might be a necessarily bad thing
;-) (although I still use gcc-2.95 a lot), just to ring a bell so that
it doesn't slip
Dear diary, on Tue, Apr 19, 2005 at 04:52:26AM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
because I can't find a way to make recent GCC reject C99 features but not
old GNU extensions.
Do we use any?
--
Petr Pasky Baudis
Stuff:
On Mon, 18 Apr 2005, James Bottomley wrote:
Fair enough. If you pull from
rsync://www.parisc-linux.org/~jejb/scsi-misc-2.6.git
Thanks. Pulled and pushed out.
Doing this exposed two bugs in your merge script:
1) It doesn't like a completely new directory (the misc tree contains a
Alright, let's try some small i2c and w1 patches...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is
below, I'll figure out how to send the individual patches later.
thanks,
greg k-h
LT == Linus Torvalds [EMAIL PROTECTED] writes:
LT What's the right way?
LT Maybe
LT if merge $src2 $orig $src1
LT then
LT cp $src2 $4 update-cache --add -- $4 exit 0
LT fi
LT echo Leaving conflict merge in $src2
LT exit 1
LT would work?
Wouldn't this be
On Tue, Apr 19, 2005 at 05:51:07AM +0200, Petr Baudis wrote:
http://pasky.or.cz/~pasky/dev/git
I pulled the tar.bz2 and did make:
gcc -g -O3 -Wall -o merge-cache merge-cache.o libgit.a libgit.a -lssl -lz
gcc -g -O3 -Wall -c -o unpack-file.o unpack-file.c
gcc -g -O3 -Wall -o unpack-file
69 matches
Mail list logo
