Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-16 Thread Junio C Hamano
LT == Linus Torvalds [EMAIL PROTECTED] writes: LT Damn, my cunning plan is some good stuff. I really like this a lot. It is *so* *simple*, clear, flexible and an example of elegance. This is one of the things I would happily say Sheesh! Why didn't *I* think of *THAT* first!!!

git-pasky file mode handling

2005-04-16 Thread Russell King
Hi, It seems that there's something weird going on with the file mode handling. Firstly, some files in the git-pasky repository have mode 0664 while others have 0644. Having pulled from git-pasky a number of times, with Petr's being the tracked repository, I now find that when I do an

[PATCH 1/2] Add --stage to show-files for new stage dircache.

2005-04-16 Thread Junio C Hamano
JNH == Junio C Hamano [EMAIL PROTECTED] writes: LT == Linus Torvalds [EMAIL PROTECTED] writes: LT I should make ls-files have a -l format, which shows the LT index and the mode for each file too. JNH You probably meant ls-tree. You used the word mode but it JNH already shows the mode so I

[PATCH 2/2] Add --stage to show-files for new stage dircache.

2005-04-16 Thread Junio C Hamano
This adds --stage option to show-files command. It shows file-mode, SHA1, stage and pathname. Record separator follows the usual convention of -z option as before. The patch is on top of the byte order fix for create_ce_flags in my previous message. Signed-off-by: Junio C Hamano [EMAIL

Re: Re: Re: Add clone support to lntree

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Sat, 16 Apr 2005, Petr Baudis wrote: I'm wondering, whether each tree should be fixed to a certain branch. I'm wondering why you talk about branches at all. No

Re: Merge with git-pasky II.

2005-04-16 Thread David Lang
On Fri, Apr 15, 2005 at 08:32:46AM -0700, Linus Torvalds wrote: In other words, I'm right. I'm always right, but sometimes I'm more right than other times. And dammit, when I say files don't matter, I'm really really Right(tm). You're right, of course (All Hail Linus!), if you can make it work

Re: space compression (again)

2005-04-16 Thread David Lang
we alrady have the concept of objects that contain objects and therefor don'e need to be re-checked (directories), the chunks inside a file could be the same type of thing. currently we say that if the hash on the directory is the same we don't need to re-check each of the files in that

Re: SHA1 hash safety

2005-04-16 Thread Ingo Molnar
* David Lang [EMAIL PROTECTED] wrote: this issue was raised a few days ago in the context of someone tampering with the files and it was decided that the extra checks were good enough to prevent this (at least for now), but what about accidental collisions? if I am understanding things

Re: SHA1 hash safety

2005-04-16 Thread Brian O'Mahoney
Three points: (1) I _have_ seen real-life collisions with MD5, in the context of Document management systems containing ~10^6 ms-WORD documents. (2) The HMAC (ethernet-harware-address) of any interface _should_ help to make a unique Id. (3) While I havn't looked at the details of the

Proposal for simplification and impovement of the git model

2005-04-16 Thread Luca Barbieri
In this message, a method to simplify and at the same time make more powerful the git abstraction is presented. I believe that the enhancements I propose make git adhere even more to its spirit and make it more intuitive. The proposal makes it much easier to build an SCM over git, obtaining in

Re: full kernel history, in patchset format

2005-04-16 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: the patches contain all the existing metadata, dates, log messages and revision history. (What i think is missing is the BK tree merge information, but i'm not sure we want/need to convert them to GIT.) author names are abbreviated, e.g. 'viro'

Re: git-pasky file mode handling

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 11:45:59AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... Hi, Hello, It seems that there's something weird going on with the file mode handling. Firstly, some files in the git-pasky repository have mode 0664 while others have

Re: full kernel history, in patchset format

2005-04-16 Thread Francois Romieu
Ingo Molnar [EMAIL PROTECTED] : [...] the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a script that will apply all the patches in order and will create a pristine 2.6.12-rc2 tree. 127 weeks of bk-commit mail for the 2.6 branch alone since october 2002 provides more

Re: Re: SHA1 hash safety

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 04:58:15PM CEST, I got a letter where C. Scott Ananian [EMAIL PROTECTED] told me that... On Sat, 16 Apr 2005, 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

Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: LT NOTE NOTE NOTE! I could make read-tree do some of these nontrivial LT merges, but I ended up deciding that only the matches in all three LT states thing collapses by default. * Understood and agreed. Having slept on it, I think I'll merge

Re: Merge with git-pasky II.

2005-04-16 Thread Johannes Schindelin
Hi, On Fri, 15 Apr 2005, David Woodhouse wrote: But if it can be done cheaply enough at a later date even though we end up repeating ourselves, and if it can be done _well_ enough that we shouldn't have just asked the user in the first place, then yes, OK I agree. The repetition could be

Re: Re: Merge with git-pasky II.

2005-04-16 Thread Simon Fowler
On Sat, Apr 16, 2005 at 06:03:33PM +0200, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter where Simon Fowler [EMAIL PROTECTED] told me that... On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote: Simon given that you have multiple

Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Linus Torvalds wrote: Having slept on it, I think I'll merge all the trivial cases that don't involve a file going away or being added. Ie if the file is in all three trees, but it's the same in two of them, we know what to do. Junio, I pushed this out, along with

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Ingo Molnar wrote: i've converted the Linux kernel CVS tree into 'flat patchset' format, which gave a series of 28237 separate patches. (Each patch represents a changeset, in the order they were applied. I've used the cvsps utility.) the history data starts at

Re: full kernel history, in patchset format

2005-04-16 Thread Thomas Gleixner
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

Re: Re: full kernel history, in patchset format

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter where Thomas Gleixner [EMAIL PROTECTED] told me that... One remark on the tree blob storage format. The binary storage of the sha1sum of the refered object is a PITA for scripting. Converting the ASCII - binary for the

Re: full kernel history, in patchset format

2005-04-16 Thread Mike Taht
* A script git-archive-tar is used to create a base tarball that roughly corresponds to linux-*.tar.gz. This works as follows: $ git-archive-tar C [B1 B2...] This reads the named commit C, grabs the associated tree (i.e. its sub-tree objects and the blob they refer to), and

Re: Re: Re: full kernel history, in patchset format

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 08:32:32PM CEST, I got a letter where Petr Baudis [EMAIL PROTECTED] told me that... Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter where Thomas Gleixner [EMAIL PROTECTED] told me that... One remark on the tree blob storage format. The

Re: Re: full kernel history, in patchset format

2005-04-16 Thread Thomas Gleixner
On Sat, 2005-04-16 at 20:32 +0200, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter where Thomas Gleixner [EMAIL PROTECTED] told me that... One remark on the tree blob storage format. The binary storage of the sha1sum of the refered object is a PITA for

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Thomas Gleixner wrote: One remark on the tree blob storage format. The binary storage of the sha1sum of the refered object is a PITA for scripting. Converting the ASCII - binary for the sha1sum comparision should not take much longer than the binary - ASCII

Re: full kernel history, in patchset format

2005-04-16 Thread Junio C Hamano
JCH == Junio C Hamano [EMAIL PROTECTED] writes: JCH I have been cooking this idea before I dove into the merge stuff JCH and did not have time to implement it myself (Hint Hint), but I JCH think something along the following lines would work nicely: It should be fairly obvious from the context

Re: full kernel history, in patchset format

2005-04-16 Thread Thomas Gleixner
On Sat, 2005-04-16 at 11:44 -0700, Linus Torvalds wrote: That level of abstraction (we never look directly at the objects) is what allows us to change the object structure later. For example, we already changed the commit date thing once, and the tree object has obviously evolved a bit,

Re: Re: full kernel history, in patchset format

2005-04-16 Thread Christopher Li
On Sat, Apr 16, 2005 at 07:43:27PM +0200, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 07:04:31PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... So I'd _almost_ suggest just starting from a clean slate after all. Keeping the old history around, of

Re: full kernel history, in patchset format

2005-04-16 Thread Jan-Benedict Glaw
On Sat, 2005-04-16 10:04:31 -0700, Linus Torvalds [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: 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

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Thomas Gleixner wrote: For the export stuff its terrible slow. :( I don't really see your point. If you already know what the tree is like you say, you don't care about the tree object. And if you don't know what the tree is, what _are_ you doing? In other words, show

Re: full kernel history, in patchset format

2005-04-16 Thread Ingo Molnar
* David Mansfield [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: the patches contain all the existing metadata, dates, log messages and revision history. (What i think is missing is the BK tree merge information, but i'm not sure we want/need to

Re: full kernel history, in patchset format

2005-04-16 Thread Ingo Molnar
* Linus Torvalds [EMAIL PROTECTED] wrote: the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a script that will apply all the patches in order and will create a pristine 2.6.12-rc2 tree. Hey, that's great. I got the CVS repo too, and I was looking at it, but the

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Martin Mares
Hello! This adds a program to download a commit, the trees, and the blobs in them from a remote repository using HTTP. It skips anything you already have. Is it really necessary to write your own HTTP downloader? If so, is it necessary to forget basic stuff like the Host: header? ;-) If you

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Daniel Barkalow
On Sat, 16 Apr 2005, Tony Luck wrote: On 4/16/05, Daniel Barkalow [EMAIL PROTECTED] wrote: +buffer = read_sha1_file(sha1, type, size); You never free this buffer. Ideally, this should all be rearranged to share the code with read-tree, and it should be fixed in common. It would

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Adam Kropelin
Tony Luck wrote: Otherwise this looks really nice. I was going to script something similar using wget ... but that would have made zillions of seperate connections. Not so kind to the server. How about building a file list and doing a batch download via 'wget -i /tmp/foo'? A quick test (on my

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Daniel Barkalow
On Sun, 17 Apr 2005, Martin Mares wrote: Hello! This adds a program to download a commit, the trees, and the blobs in them from a remote repository using HTTP. It skips anything you already have. Is it really necessary to write your own HTTP downloader? If so, is it necessary to forget

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Daniel Barkalow
On Sat, 16 Apr 2005, Adam Kropelin wrote: Tony Luck wrote: Otherwise this looks really nice. I was going to script something similar using wget ... but that would have made zillions of seperate connections. Not so kind to the server. How about building a file list and doing a batch

Re: SHA1 hash safety

2005-04-16 Thread David Lang
that's the difference between CS researchers and sysadmins. sysadmins realize that there are an infinante number of files that map to the same hash value and plan accordingly (becouse we KNOW we will run across them eventually), and don't see it as a big deal when we finally do. CS researches

[PATCH] update-cache --refresh cache entry leak

2005-04-16 Thread Junio C Hamano
When update-cache --refresh replaces an existing cache entry with a new one, it forgets to free the original. Signed-off-by: Junio C Hamano [EMAIL PROTECTED] --- update-cache.c: 61d2b93a751f35ba24f479cd4fc151188916f02a --- update-cache.c +++ update-cache.c 2005-04-16 15:49:03.0

Full history

2005-04-16 Thread Thomas Gleixner
Hi, I can publish the stuff on monday from a university nearby. --- total blob objects = 228384 total tree objects = 172507 total commit objects = 55877 The empty changesets which are noting merges are omitted at the moment. Is it of interest to include them ?? It might also be

Re: Re: Add clone support to lntree

2005-04-16 Thread Daniel Barkalow
On Sun, 17 Apr 2005, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... I think fork is as good as anything for describing the operation. I had thought about clone because it seemed to fill the role

Re: full kernel history, in patchset format

2005-04-16 Thread David Lang
On Sat, 16 Apr 2005, Thomas Gleixner wrote: 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

Re: SHA1 hash safety

2005-04-16 Thread Paul Jackson
what I'm talking about is the chance that somewhere, sometime there will be two different documents that end up with the same hash I have vastly greater chance of a file colliding due to hardware or software glitch than a random message digest collision of two legitimate documents. I've lost

Re: SHA1 hash safety

2005-04-16 Thread Paul Jackson
sysadmins realize that there are an infinante number of files that map to Sysadmins know that there are an infinite ways for their systems to crap out, and try to cover for the ones that there is a snow balls chance in Hades of them seeing in their lifetime. -- I won't rest

[PATCH] Optionally tell show-diff to show only named files

2005-04-16 Thread Junio C Hamano
SCMs have ways to say I want diff only this particular file, or I want diff files under this directory. This patch teaches show-diff to do something similar. Without command line arguments, it still examines everything in the dircache as before. Signed-off-by: Junio C Hamano [EMAIL PROTECTED]

Re: SHA1 hash safety

2005-04-16 Thread Martin Mares
Hi! We've already computed the chances of a random pure hash collision with SHA1 - it's something like an average of 1 collision every 10 billion years if we have 10,000 coders generating 1 new file version every minute, non-stop, 24 hours a day, 365 days a year. GIT is safe even for the

[PATCH] optimize gitdiff-do script

2005-04-16 Thread Paul Jackson
Rewrite gitdiff-do so that it works with arbitrary whitespace (space, tab, newline, ...) in filenames. Reduce number of subcommands execv'd by a third, by only calling 'rm' once, at end, not each loop. Avoid using shell arrays; perhaps more portable. Avoid 'echo -e' when displaying names; dont

[PATCH] missing mkdir -p flag in gitdiff-do

2005-04-16 Thread Paul Jackson
First mkdir in gitdiff-do missing -p, so useless error Signed-off-by: Paul Jackson [EMAIL PROTECTED] Index: git-pasky-0.4/gitdiff-do === --- git-pasky-0.4.orig/gitdiff-do 2005-04-16 13:18:29.0 -0700 +++

[PATCH] show-diff -z option for machine readable output.

2005-04-16 Thread Junio C Hamano
This patch adds the -z option to the show-diff command, primarily for use by scripts. The information emitted is similar to that of -q option, but in a more machine readable form. Records are terminated with NUL instead of LF, so that the scripts can deal with pathnames with embedded newlines.

Re: Re: Re: Add clone support to lntree

2005-04-16 Thread Petr Baudis
Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... On Sat, 16 Apr 2005, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter where Petr Baudis [EMAIL PROTECTED] told me that...

Re: [PATCH] fix mktemp (remove mktemp ;)

2005-04-16 Thread Jan-Benedict Glaw
On Sat, 2005-04-16 16:27:43 -0700, Paul Jackson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Index: git-pasky-0.4/gitcommit.sh === --- git-pasky-0.4.orig/gitcommit.sh 2005-04-12 10:39:14.0 -0700 +++

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Petr Baudis
Dear diary, on Sun, Apr 17, 2005 at 01:27:43AM CEST, I got a letter where Paul Jackson [EMAIL PROTECTED] told me that... Remove mktemp usage - it doesn't work on some Mandrakes, nor on my SuSE 8.2 with mktemp-1.5-531. Replace with simple use of $$ (pid). I've been using this same pattern

Re: Storing permissions

2005-04-16 Thread Junio C Hamano
PJ == Paul Jackson [EMAIL PROTECTED] writes: PJ That matches my experience - store 1 bit of mode state - executable or not. Sounds like svn ;-). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: Re: Re: Add clone support to lntree

2005-04-16 Thread Petr Baudis
Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... Actually, what about if git pull outside of repository did what git clone does now? I'd kinda like clone instead of fork too. This seems like the best solution to me,

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread Adam Kropelin
Daniel Barkalow wrote: On Sat, 16 Apr 2005, Adam Kropelin wrote: How about building a file list and doing a batch download via 'wget -i /tmp/foo'? A quick test (on my ancient wget-1.7) indicates that it reuses connectionss when successive URLs point to the same server. You need to look at some of

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Paul Jackson
And racy. And not guaranteed to come up with fresh new files. In theory perhaps. In practice no. Even mktemp(1) can collide, in theory, since there is no practical way in shell scripts to hold open and locked the file from the instant of it is determined to be a unique name. The window of

Re: Storing permissions

2005-04-16 Thread Paul Jackson
Junio wrote: Sounds like svn I have no idea what svn is. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line

Re: Re: Re: Add clone support to lntree

2005-04-16 Thread Daniel Barkalow
On Sun, 17 Apr 2005, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... On Sat, 16 Apr 2005, Petr Baudis wrote: Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter where Petr

Re: optimize gitdiff-do script

2005-04-16 Thread Paul Jackson
Petr wrote: Please don't reindent the scripts. It violates the current coding style and the patch is unreviewable. Sorry - I had not realized that there was a style in this case. I am all in favor of such coding styles, and will gladly fit this one. Do you want the patch resent, or a patch to

[PATCH] Use libcurl to use HTTP to get repositories

2005-04-16 Thread Daniel Barkalow
This enables the use of HTTP to download commits and associated objects from remote repositories. It now uses libcurl instead of local hack code. Still causes warnings for fsck-cache and rev-tree, due to unshared code. Still leaks a bit of memory due to bug copied from read-tree. Needs libcurl

Re: [PATCH] Use libcurl to use HTTP to get repositories

2005-04-16 Thread Paul Jackson
Needs libcurl post 7.7 or so. That could be mentioned in the README, which has a list of 'Software requirements.' Actually, zlib-devel and openssl should be on this list as well. My laziness got in the way of my sending in a patch for that. -- I won't rest till it's the

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Dave Jones
On Sat, Apr 16, 2005 at 05:02:21PM -0700, Paul Jackson wrote: And racy. And not guaranteed to come up with fresh new files. In theory perhaps. In practice no. Even mktemp(1) can collide, in theory, since there is no practical way in shell scripts to hold open and locked the file

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Erik van Konijnenburg
On Sat, Apr 16, 2005 at 08:33:25PM -0400, Dave Jones wrote: On Sat, Apr 16, 2005 at 05:02:21PM -0700, Paul Jackson wrote: And racy. And not guaranteed to come up with fresh new files. In theory perhaps. In practice no. Even mktemp(1) can collide, in theory, since there is no

Re: [PATCH] show-diff shell safety

2005-04-16 Thread Paul Jackson
Junio wrote: The command line for running diff command is built without taking shell metacharacters into account. Ack - you're right. One should avoid popen and system in all but personal hacking code. There are many ways, beyond just embedded shell redirection, to cause problems with these

Re: Storing permissions

2005-04-16 Thread Morten Welinder
Does it really make sense to store full permissions in the trees? I think that remembering the x-bit should be good enough for almost all purposes and the other permissions should be left to the local environment. It makes some sense in principle, but without storing what they mean (i.e.,

[PATCH] Rename confusing variable in show-diff

2005-04-16 Thread Junio C Hamano
The show-diff command uses a variable new but it is always used to point at the original data recorded in the dircache before the user started editing in the working file. Rename it to old to avoid confusion. To be applied on top of my previous patches: [PATCH] Optionally tell show-diff to

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Paul Jackson
Dave wrote: http://www.linuxsecurity.com/content/view/115462/151/ Nice - thanks. Pasky - would you be interested in a patch that used a more robust tmp file creation, along the lines of replacing t=${TMPDIR:-/usr/tmp}/gitdiff.$$ trap 'set +f; rm -fr $t.?; trap 0; exit 0' 0 1 2

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Paul Jackson
Erik wrote: How about putting using .git/tmp.$$ or similar as tempfile? One could, but best to normally honor the users TMPDIR setting. Could one 'git diff' a readonly git repository? Perhaps someone has a reason for putting their tmp files where they choose - say a local file system in a

[PATCH] (take 2) Rename confusing variable in show-diff

2005-04-16 Thread Junio C Hamano
Oops, sorry I screwed up and sent a wrong patch. Please discard the previous one. The show-diff command uses a variable new but it is always used to point at the original data recorded in the dircache before the user started editing in the working file. Rename it to old to avoid confusion. To

Re: Storing permissions

2005-04-16 Thread Paul Jackson
Morten wrote: It makes some sense in principle, but without storing what they mean (i.e., group==?) it certainly makes no sense. There's no they there. I think Martin's proposal, to which I agreed, was to store a _single_ bit. If any of the execute permissions of the incoming file are set,

[PATCH] show-diff style fix.

2005-04-16 Thread Junio C Hamano
This fixes some stylistic problems introduced by my previous set of patches. I'll be sending my last patch to show-diff next, which depends on this cleanup. To be applied on top of my previous patches: [PATCH] Optionally tell show-diff to show only named files. [PATCH] show-diff -z

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Brian O'Mahoney
No, you have to: (a) create a unique, pid specific file name /var/tmp/myapp.$$.xyzzy (b) create it in O_EXCL mode, so you wont smash another's held lock (b-1) It worked, OK (b-2) open failed, try ...xyzzz repeat until (b-1) There are thousands of examples of how to do this with bash. Paul

Re: fix mktemp (remove mktemp ;)

2005-04-16 Thread Paul Jackson
No, you have to: How does this compare with the one I posted about 1 hour 30 minuts ago: tmp=${TMPDIR-/tmp} tmp=$tmp/gitdiff-do.$RANDOM.$RANDOM.$RANDOM.$$ (umask 077 mkdir $tmp) || { echo Could not create temporary directory! Exiting. 12

[PATCH] libgit

2005-04-16 Thread Mike Taht
commit b0550573055abcf8ad19dcb8a036c32dd00a3be4 tree b77882b170769c07732381b9f19ff2dd5c9f1520 parent 866b4aea9313513612f2b0d66814a2f526d17f21 author Mike Taht [EMAIL PROTECTED] 1113704772 -0700 committer Mike Taht [EMAIL PROTECTED] 1113704772 -0700 looks my 1878 line patch to convert git to libgit

Re: [PATCH] Get commits from remote repositories by HTTP

2005-04-16 Thread tony . luck
How about building a file list and doing a batch download via 'wget -i /tmp/foo'? A quick test (on my ancient wget-1.7) indicates that it reuses connectionss when successive URLs point to the same server. Here's a script that does just that. So there is a burst of individual wget commands to

Re: SHA1 hash safety

2005-04-16 Thread Tkil
Brian == Brian O'Mahoney [EMAIL PROTECTED] writes: Brian (1) I _have_ seen real-life collisions with MD5, in the context Brian of Document management systems containing ~10^6 ms-WORD Brian documents. Was this whole-document based, or was it blocked or otherwise chunked? I'm wondering,

Re: [PATCH] update-cache --refresh cache entry leak

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: When update-cache --refresh replaces an existing cache entry with a new one, it forgets to free the original. I've seen this patch now three times, and it's been wrong every single time. Maybe we should add a comment? That active-cache entry you

Re: [PATCH] libgit

2005-04-16 Thread Randy.Dunlap
On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote: | commit b0550573055abcf8ad19dcb8a036c32dd00a3be4 | tree b77882b170769c07732381b9f19ff2dd5c9f1520 | parent 866b4aea9313513612f2b0d66814a2f526d17f21 | author Mike Taht [EMAIL PROTECTED] 1113704772 -0700 | committer Mike Taht [EMAIL PROTECTED]

Re: Yet another base64 patch

2005-04-16 Thread David A. Wheeler
Paul Jackson wrote: Earlier, hpa wrote: The base64 version has 2^12 subdirectories instead of 2^8 (I just used 2 characters as the hash key just like the hex version.) Later, hpa wrote: Ultimately the question is: do we care about old (broken) filesystems? I'd imagine we care a little - just not

Re: Yet another base64 patch

2005-04-16 Thread Paul Jackson
David wrote: It's a trade-off, I know. So where do you recommend we make that trade-off? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe

Re: [PATCH] libgit

2005-04-16 Thread Mike Taht
Fixed. Randy.Dunlap wrote: On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote: | commit b0550573055abcf8ad19dcb8a036c32dd00a3be4 | tree b77882b170769c07732381b9f19ff2dd5c9f1520 | parent 866b4aea9313513612f2b0d66814a2f526d17f21 | author Mike Taht [EMAIL PROTECTED] 1113704772 -0700 | committer Mike

Re: SHA1 hash safety

2005-04-16 Thread Paul Jackson
but the chance of any collision at all wigs me out. Guess you're just going to get wigged out then. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To

Re: Yet another base64 patch

2005-04-16 Thread David Lang
On Thu, 14 Apr 2005, H. Peter Anvin wrote: Linus Torvalds wrote: Even something as simple as ls -l has been known to have O(n**2) behaviour for big directories. For filesystems with linear directories, sure. For sane filesystems, it should have O(n log n). note that default configs of ext2 and

Re: [PATCH] Use libcurl to use HTTP to get repositories

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Paul Jackson wrote: Daniel wrote: I'm working off of Linus's tree when not working on scripts, and it doesn't have that section at all. Ah so - nevermind my README comments then. Well, actually, I suspect that something like this should go to Pasky. I really see my

Re: SHA1 hash safety

2005-04-16 Thread David A. Wheeler
Paul Jackson wrote: what I'm talking about is the chance that somewhere, sometime there will be two different documents that end up with the same hash I have vastly greater chance of a file colliding due to hardware or software glitch than a random message digest collision of two legitimate

Re: [PATCH] update-cache --refresh cache entry leak

2005-04-16 Thread Junio C Hamano
LT == Linus Torvalds [EMAIL PROTECTED] writes: LT I've seen this patch now three times, and it's been wrong every single LT time. Maybe we should add a comment? I found out the previous two just after I sent it out. Sorry about that. - To unsubscribe from this list: send the line

Re: Storing permissions

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Paul Jackson wrote: Morten wrote: It makes some sense in principle, but without storing what they mean (i.e., group==?) it certainly makes no sense. There's no they there. I think Martin's proposal, to which I agreed, was to store a _single_ bit. If any of the

Re: [PATCH] Use libcurl to use HTTP to get repositories

2005-04-16 Thread Ingo Molnar
* Daniel Barkalow [EMAIL PROTECTED] wrote: Still leaks a bit of memory due to bug copied from read-tree. Linus, should i resend the 18 fixes i sent the other day? (as a GIT repository perhaps?) I found roughly 6 common memory leaks, 8 theoretical memory leaks, 2 overflows and did a couple of

Re: Storing permissions

2005-04-16 Thread David A. Wheeler
Paul Jackson wrote: Junio wrote: Sounds like svn I have no idea what svn is. svn = common abbreviation for Subversion, a widely-used centralized SCM tool intentionally similar to CVS. --- David A. Wheeler - To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: SHA1 hash safety

2005-04-16 Thread Paul Jackson
I have nothing further to contribute to this subtopic. Good luck with it. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list:

Re: Issues with higher-order stages in dircache

2005-04-16 Thread Junio C Hamano
Linus, earlier I wrote [*R1*]: - An explicit update-cache [--add] [--remove] path should be taken as a signal from the user (or Cogito) to tell the dircache layer the merge is done and here is the result. So just delete higher-order stages for the path and record the

Re: Issues with higher-order stages in dircache

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: I am wondering if you have a particular reason not to do the same for the removing half. No. Except for me being silly. Please just make it so. Also do you have any comments on this one from the same message? * read-tree - When merging

[PATCH] checkout-cache -a should not extract unmerged stages

2005-04-16 Thread Junio C Hamano
When checkout-cache -a is run, currently it attempts to extract each existing unmerged stage to the same destination and complains to what it itself has done. This is nonsensical. Presumably, the user is running checkout-cache -a in order to verify the result of the part that has cleanly been

Re: Storing permissions

2005-04-16 Thread Paul Jackson
Linus wrote: It might be ok to just change the compare cache check to only care about a few bits, though: S_IXUSR and S_IFDIR. And then ... I think I agree. But since I am reluctant to take enough time to understand the code well enough to write this patch, I'll shut up now ;). --

Re: Storing permissions

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Linus Torvalds wrote: Anybody want to send a patch to do this? Actually, I just did it. Seems to work for the only test-case I tried, namely I just committed it, and checked that the permissions all ended up being recorded as 0644 in the tree (if it has the -x bit set,

[PATCH] show-diff.c: do not include unused header file

2005-04-16 Thread Junio C Hamano
This is my bad. I added #include ctype.h to the file, which I ended up not using and failed to remove it. Signed-off-by: Junio C Hamano [EMAIL PROTECTED] --- show-diff.c: d85d79b97a59342390bd34da09049dd58d56900f --- show-diff.c +++ show-diff.c 2005-04-16 22:37:29.0 -0700 @@ -4,7 +4,6 @@

[PATCH] Add lsremote command.

2005-04-16 Thread Steven Cole
This is a fairly trivial addition, but if users are adding remote repositories with git addremote, then those users should be able to list out the remote list without having to know the details of where the remotes file is kept. Steven Adds lsremote command to list remotes. Signed-Off-By:

[PATCH] Fix off-by-one error in show-diff

2005-04-16 Thread Junio C Hamano
The patch to introduce shell safety to show-diff has an off-by-one error. Here is an fix. Signed-off-by: Junio C Hamano [EMAIL PROTECTED] --- show-diff.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) show-diff.c: 8a24ff62b85a6e23469e3f0e7a20170dfe543ebf --- show-diff.c +++