Re: Re: Merge with git-pasky II.
* 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 object. I really hate theoretical discussions. i was only replying to your earlier point: Almost all attacks on sha1 will depend on _replacing_ a file with a bogus new one. So guys, instead of using sha256 or going overboard, just make sure that when you synchronize, you NEVER import a file you already have. which point i still believe is subtly wrong. You were suggesting to concentrate on file replacement to counter most of the practical attacks, while i pointed out an attack _using the same basic mechanism that your point above supposed_. [ if you can replace a file with a known hash, with a bogus new one, and you still have enough control over the contents of your bogus new file that it is 1) a valid file that builds 2) compromises the kernel, then you likely have the same amount of control my 'theoretical' attack requires. ] 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 [...] yes, that's why i suggested to not actually trust the hash to be cryptographically secure, but to just assume it's a good generic hash we can design a DB around, and to turn -DCOLLISION_CHECK on and enforce consistency rules on boundaries. [ it's not bad to keep sha1 because even my suggested enhancement still leaves 'content-less trust-pointers to untrusted content via email' vectors open against attack (maintainer sends you an email that commit X in Malice's repository Y is fine to pull, and you pull it blindly, while the attacker has replaced his content with the compromised one meanwhile), but it at least validates the bulk traffic that goes into the DB: patches via emails and trusted repositories. ] so all i was suggesting was to extend your suggested 'overwrite collision check' to a stricter 'content we throw away and use the sha1 shortcut for needs to be checked against the in-DB content as well'. in other words, your suggested 'rename check' is checking for 'positive duplicate content', while my addition would also check for 'negative duplicate content' as well. but as usual, i could be wrong, so dont take this too serious :-) Ingo - 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
Re: SHA1 hash safety
[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*! Why the aitch-ee-double-hockey-sticks didn't you publish this when you found it? Seriously, man. The MD5 has was fine, or at least the code (a) produced the correct results on the published test cases, and, (b) was properly applied to all bytes of the file(s). I was surprised when it happened, which is why I bothered to post to this list at this time, so I make two more points OK, I guess it's time for some remedial math. There are 2^128 = 340282366920938463463374607431768211456 different MD5 hashes. You are suggesting that you found a collision using ~1e6 = ~1,000,000 plaintexts. Let's suppose there were actually 100,000,000 = 1e8 plaintexts, just in case you underestimated the number. Applying the birthday paradox, we have a 50% probability that you'd find one collision if there were ~7,213,475,309,916,173 possible hash values. If you extend the birthday argument (what is the probability of a collision if you take N samples from a set of size M?) you get the following results, with N = 1e8: 50% (1 in 2) probability of collision in 7,213,475,309,916,173. 1% (1 in 100) probability of collision in497,496,027,172,833,194. .05% (1 in 1845) probability of collision in 9,223,372,036,854,775,806. That's where my quick-and-dirty solver craps out, but we're still a really long ways from 340,282,366,920,938,463,463,374,607,431,768,211,456. A simple linear extrapolation (certainly wrong, but not by more than a few dozen orders of magnitude) says that the odds would be 1 in 68,056,473,384,187,692,692 for the full MD5 hash (I'm not even going to dignify that with a percentage). I'm not going to do the sums, but I would hazard a guess that it's more likely your PC suffered a cosmic-ray-induced memory fault - EACH OF THE FOUR TIMES YOU TESTED IT - causing it to report the same MD5, than that you actually discovered a collision with a measly million (or even hundred million) plaintexts. (Of course, I don't know how many tests of the hash you actually did. But the point stands.) Hell, if you're *that* lucky, what are you doing in IT? You could be making a killing at the roulette table. Or, even more likely, there was some other factor in the system (most likely that it was only using a few bits, probably 32, of the hash when looking for collisions) that resulted in a false alarm. 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 absence of actual evidence, we have to assume (just based on the probabilities) that there was some error in your testing. -andy - 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
[patch] fixup GECOS handling
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]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst = p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die(You don't exist. Go away!);
realgecos = pw-pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw-pw_name);
memcpy(realemail, pw-pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst = p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die(You don't exist. Go away!);
realgecos = pw-pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw-pw_name);
memcpy(realemail, pw-pw_name, len);
realemail[len] = '@';
signature.asc
Description: This is a digitally signed message part
[pasky] recent changes to gitdiff.sh
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 sure which it is) Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch] fork optional branch point normazilation
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 Ahh, ok. I'll make the cleanup thing just remove strange characters from the end, that should fix this kind of thing for now. I'd just remove everything after the first strange number, but I can also see people using the lastname, firstname format, and I'd hate to just ignore firstname in that case. If we get the info from /etc/passwd, then we should just use whatever before the first [,;] (see patch I posted earlier). If not, then I think AUTHOR_* should be sane). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re-done kernel archive - real one?
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 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. OT, and probably not much help, but glibc-2.3.5 is out ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch] fixup GECOS handling
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 and subtraction, that's
no real excuse for it.
Err, right. Updated patch.
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.
Signed-off-by: Martin Schlemmer [EMAIL PROTECTED]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst = p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die(You don't exist. Go away!);
realgecos = pw-pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw-pw_name);
memcpy(realemail, pw-pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst = p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die(You don't exist. Go away!);
realgecos = pw-pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw-pw_name);
memcpy(realemail, pw-pw_name, len);
realemail[len] = '@';
signature.asc
Description: This is a digitally signed message part
Re: Yet another base64 patch
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 is retaining hex naming, and not moving to base64, then I don't think what I am about to say is relevant. However, if base64 file naming is still being considered, then vfat32 compatibility may be a concern (I'm not sure about NTFS). Although it is case-preserving, it actually considers both cases as being the same name. So AaA would overwrite aAa. If I'm doing the math right, we would effectively be ignoring roughly one out of 6 base64 bits. This would reduce the collision avoidance capability of SHA-1 (on vfat32) from 160 bits to about 133 bits. Still strong, and probably acceptable, but worth noting. I'll take this opportunity to support David's position that it would be fantastic if git could end up being valuable for a wide range of projects, rather than just the kernel. I also fully understand that the kernel is the primary target, but when there are opportunities to make the data structures more generally useful without causing problems for the kernel project, I hope they are taken. Thanks, Kevin - 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
First git-pasky bug report? :) error: bad signature/verify header failed
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 the directory to one side and reissued the commands and all was well: 723 tar xvfj git-pasky-base.tar.bz2 724 cd git-pasky-0.4/ 725 make 726 git pull pasky 727 make 728 git pull pasky 729 history | tail -10 This is just a heads up in case there's anything useful here. It may just have been locking issues and me pulling whilst the repo was being updated or something... I'll hold the bad directory for a day or two in case anyone wants any diagnostics running. David [EMAIL PROTECTED]:/everything/devel/git/git-pasky-0.4$ git pull pasky MOTD: Welcome to Petr Baudis' rsync archive. MOTD: MOTD: If you are pulling my git branch, please do not repeat that MOTD: every five minutes or so - new stuff is likely not going to MOTD: appear so fast, and my line is not that thick. Nothing wrong MOTD: with pulling every half an hour or so, of course. MOTD: MOTD: Feel free to contact me at [EMAIL PROTECTED], shall you have MOTD: any questions or suggestions. Tree change: c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a *100644-100644 blob 222bce21788308e1bf567304b474225b1681b03b-ad44415110ab63f1daa93e07dc496193d8006d81 Makefile *100755-100755 blob 667f877ae836c418294ef085e91efcb48d30cabb-035a1f470003c8b0963d0eb5f0eb457155f415ad git *100755-100755 blob fadd17e52845c5656ba344a9413b29b641c9ff5f-67e97fb71094693929f56d74bc13e572420d99d4 gitcommit.sh *100755-100755 blob 7ea441e584d603463fb1b83991b88f63a3895cff-18478101980f630f0e9fd95365c6d9f46bf27bfd gitmerge.sh *100755-100755 blob 9bda6555a1dafc1db762bc46db60d2a9485dc523-8e016f7d3aeb0244c8a6524ddaa4b2cb1ff8015f gitpull.sh +100755 blobb6e318b31eb2ed6d2e137833a2064327331504b4gitseek.sh *100755-100755 blob 30654380c10edde32def8e5fa2e2c956fbff3d58-ce44c1d4ce3b949b8ac99f1b90927da4e698e3de gittrack.sh -100755 blob2488078570c4a5709332d92d7a1b5b65036ff3a0gitupdate.sh Tracked branch, applying changes... error: bad signature error: verify header failed read_cache: Invalid argument error: bad signature error: verify header failed error: bad signature error: verify header failed At this point I moved the directory aside... -- - 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
Re: First git-pasky bug report? :) error: bad signature/verify header failed
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 changes... error: bad signature error: verify header failed read_cache: Invalid argument error: bad signature error: verify header failed error: bad signature error: verify header failed this is a known problem, caused by the directory cache index format change (to fix endianity issues). You can solve it by doing read-tree $(tree-id) update-cache --refresh (if you are reading this and didn't to the problematic pull yet, do it right after you get git-pasky-base, do your first pull and rebuild; you won't get into problems that way). To recover, do this now, and then do: (i) if you have local commits: git merge -b c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf \ 5bf2f464d382b0bd746d06e264bc6951e7bfcd3a (ii) if you don't have local commits: git diff -r c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a \ | git apply I'm thinking how to handle future directory cache changes. Doing read-tree $(tree-id) update-cache --refresh on the kernel tree is fast (three seconds?) if you have it in cache already, but SLOW (more than a minute) if you have cold cache; so I wouldn't do it always. I think I will do something like check-cache which will just return exitcode based on whether the cache is ok or not, and do this time in the git multiplexer. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Re-done kernel archive - real one?
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, you had a dotest program to apply patches in email form to a bk tree. And from what I can gather, you've changed that to handle git archives, right? Any pointers to where I can find this so I could try to build up some git trees for you to merge with? I think I can even make a tree with a merge issue if you want to test that out :) thanks, greg k-h - 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
Re: Re-done kernel archive - real one?
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 complex) thing I described by the merge, but noticing that one of the commits you are merging is a proper subset of the other one, and just updating the head instead of actually doing a real merge (ie skipping the read-tree -m and write-tree phases). This was with some random version of git-pasky-0.04. Unfortunately, this version doesn't have the sha1 ID appended, so I couldn't say definitively that it's the latest and greatest. It might be a day old. I'm afraid that until Pasky's tools script this properly, a pull really ends up being something like this (which _can_ be scripted, never fear): NOTE NOTE NOTE! This is untested! I'm writing this within the email editor, so do _not_ do this on a tree that you care about. #!/bin/sh # # use $1 or something in a real script, this # just hard-codes it. # merge_repo=master.kernel.org:/pub/linux/kernel/people/torvalds/linux-2.6.git echo Getting object database rsync -avz --ignore-existing $merge_repo/ .git/ echo Getting remote head rsync -avz $merge_repo/HEAD .git/MERGE_HEAD head=$(cat .git/HEAD) merge_head=$(cat .git/MERGE-HEAD) common=$(merge-base $head $merge_head) if [ -z $common ]; then echo Unable to find common commit between $merge_head $head exit 1 fi # Get the trees associated with those commits common_tree=tree=$(cat-file commit $common | sed 's/tree //;q') head_tree=tree=$(cat-file commit $head | sed 's/tree //;q') merge_tree=tree=$(cat-file commit $merge | sed 's/tree //;q') if [ $common == $merge_head ]; then echo Already up-to-date. Yeeah! exit 0 fi if [ $common == $head ]; then echo Updating from $head to $merge_head. echo Destroying all noncommitted data! echo Kill me within 3 seconds.. sleep 3 read-tree $merge_tree checkout-cache -f -a echo $merge_head .git/HEAD exit 0 fi echo Trying to merge $merge_head into $head read-tree -m $common_tree $head_tree $merge_tree result_tree=$(write-tree) || exit 1 result_commit=$(echo Merge $merge_repo | commit-tree $result_tree -p $head -p $merge_head) echo Committed merge $result_commit echo $result_commit .git/HEAD read-tree $result_tree checkout-cache -f -a The above looks like it might work, but I also warn you: it's not only untested, but it's pretty fragile in that if something breaks, you are probably left with a mess. I _tried_ to do the right thing, but... So it obviously will need testing, tweaking and just general tender loving care. And if the merge isn't clean, it will exit early thanks to the write-tree || exit 1 and now you have to resolve the merge yourself. There are tools to help you do so automatically, but that's really a separate script. You shouldn't hit the merge case at all right now, you should hit the Updating from $head to $merge_head thing. If Pesky wants to take the above script, test it, and see if it works, that would be good. It's definitely a much better pull than trying to apply the patches forward.. Linus - 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
Re: Re-done kernel archive - real one?
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, I say. Rough interfaces is a big issue. | | Speaking of tools, you had a dotest program to apply patches in email | form to a bk tree. And from what I can gather, you've changed that to | handle git archives, right? Any pointers to where I can find this so I | could try to build up some git trees for you to merge with? I think I | can even make a tree with a merge issue if you want to test that out :) it's at http://www.kernel.org/pub/linux/kernel/people/torvalds/git-tools.git/ --- ~Randy - 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
Re: optimize gitdiff-do script
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 of my first one.
2) 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 3 15
with:
tmp=${TMPDIR-/tmp}
tmp=$tmp/gitdiff-do.$RANDOM.$RANDOM.$RANDOM.$$
(umask 077 mkdir $tmp) || {
echo Could not create temporary directory! Exiting. 12
exit 1
}
trap 'rm -fr $tmp; trap 0; exit 0' 0 1 2 3 15
t=$tmp/tmp
From the www.linuxsecurity.com link that Dave Jones provided, the
above $tmp directory is about as good as using mktemp, while
avoiding both dependency on mktemp options not everyone has.
3) If interested in (2), would you want it instead of my previous mktemp
removal patch, or on top of 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: 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
Re: A couple of questions
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 cannot
reconstruct the contents of file objects/xy/z{38} from its name
xyz{38}.
Nothing beats backups and distribution. The distributed nature of git
means that you can replicate your objects abitrarily.
Another problem might come up if the file does pass the simple
consistency test but the file's contents is not a valid git file,
Run fsck-cache. It not only tests SHA1 and general object sanity, but it
does full tracking of the resulting reachability and everything else. It
prints out any corruption it finds (missing or bad objects), and if you
use the --unreachable flag it will also print out objects that exist but
that aren't readable from any of the HEAD nodes (which you need to
specify).
So for example
fsck-cache --unreachable $(cat .git/HEAD)
will do quite a _lot_ of verification on the tree. There are a few extra
validity tests I'm going to add (make sure that tree objects are sorted
properly etc), but on the whole if fsck-cache is happy, you do have a
valid tree.
Any corrupt objects you will have to find in backups or other archives (ie
you can just remove them and do an rsync with some other site in the
hopes that somebody else has the object you have corrupted).
Of course, valid tree doesn't mean that it wasn't generated by some evil
person, and the end result might be crap. Git is a revision tracking
system, not a quality assurance system ;)
Linus
-
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
Re: Re-done kernel archive - real 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 interfaces is a big issue. Speaking of tools, you had a dotest program to apply patches in email form to a bk tree. And from what I can gather, you've changed that to handle git archives, right? Yup. It's a git archive at kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git and it seems to work. It's what I've used for all the kernel patches (except for the merge), and it's what I use for the git stuff that shows up as authored by others. Linus - 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
Re: A couple of questions
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 ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - 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
(no subject)
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
Re: [PATCH] Add help details to git help command.
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 print any comments in the entire file, which may
not be desired. If a command name and shell script filename
do not follow the usual convention, this won't work, e.g. ci for commit.
Hey, those BUGS are the only slightly non-trivial thing on the whole
thing! I could do this patch myself... ;-) Also, you don't want to print
the first newline and the Copyright notices.
Fixed extra vertical whitespace, Copyright notice problems, and issue
with git help ci.
Here's a better version. Didn't fix the more interesting bugs, as I'm
pressed for time (aren't we all). Perhaps someone can polish this up.
Anyway, I think it's pretty useful in its present form.
Thanks,
Steven
-
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 print any comments in the entire file, which may
not be desired. If a command name and shell script filename
do not follow the usual convention, this won't work.
git: b648169640025bd68d1b27a0fcc85b65d85e4440
--- git
+++ git 2005-04-18 10:34:17.0 -0600
@@ -19,6 +19,11 @@
help () {
+
+command=$1
+scriptfile=git$command.sh
+
+if [ ! $command ]; then
cat __END__
The GIT scripted toolkit $(gitversion.sh)
@@ -48,7 +53,10 @@
track [RNAME]
version
+Additional help is available with: git help COMMAND
+
Note that these expressions can be used interchangably as IDs:
+
empty string (current HEAD)
local (the local branch if tracking a remote one)
remote name (as registered with git addremote)
@@ -57,6 +65,14 @@
commit object hash (as returned by commit-id)
tree object hash (accepted only by some commands)
__END__
+fi
+if [ $scriptfile = gitci.sh ]; then
+ scriptfile=gitcommit.sh
+fi
+if [ ! $scriptfile = git.sh ]; then
+ grep ^# $scriptfile | grep -v !/bin | grep -v (c) \
+ | cut -c 2- | grep ^.
+fi
}
-
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
Re: Re-done kernel archive - real one?
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 far. Sorry, Linus - 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
Re: SHA1 hash safety
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 absence of actual evidence, we have to assume (just based on the probabilities) that there was some error in your testing. I've already had a long correspondence with this poster. He claims that this happened 7 years ago, involved a commercial contract covered by Swiss Banking Law (with caps!) and that, of course, he certainly doesn't retain [his] client's documents, and even if he *did*, he wouldn't show them to *me*. And then he was unable to comprehend that I couldn't accept his word alone as prima facie evidence that the laws of probability did not apply to him or his clients. I've been a coder far too long to attribute to The Mysterious Hand Of God what can adequately be described by subtle programmer error. The most reasonable explanation, given the (lack of) evidence, is that the programmer involved quickly took refuge in a (wildly improbable, but his clients'll never know) MD5 collision instead of buckling down and finding the bug in his code. --scott ODOATH Ortega FBI SGUAT AEBARMAN India Peking ODACID operation RYBAT [Hello to all my fans in domestic surveillance] for Dummies KUCLUB ( http://cscott.net/ ) - 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
Re: Re-done kernel archive - real one?
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, [... ] 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 far. Sorry, No problem. :-) Or you can just call me Petr if you want. ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: optimize gitdiff-do script
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 it. ;-)
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 of my first one.
Resend from scratch, please.
I cannot guarantee I will look at it immediately, though. Optimizing is
nice, but gitdiff-do's speed is already usable and there are much more
pressing issues for git-pasky right now.
2) 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 3 15
with:
tmp=${TMPDIR-/tmp}
tmp=$tmp/gitdiff-do.$RANDOM.$RANDOM.$RANDOM.$$
(umask 077 mkdir $tmp) || {
echo Could not create temporary directory! Exiting. 12
exit 1
}
trap 'rm -fr $tmp; trap 0; exit 0' 0 1 2 3 15
t=$tmp/tmp
From the www.linuxsecurity.com link that Dave Jones provided, the
above $tmp directory is about as good as using mktemp, while
avoiding both dependency on mktemp options not everyone has.
3) If interested in (2), would you want it instead of my previous mktemp
removal patch, or on top of it?
Instead of the previous patch. But what I said still holds - this can go
in only after we have a shell library sharing the common functions - I
don't want to have this horrid stuff in every file.
Actually, if you will make a mktemp shell function, no changes
whatsoever might be needed to the other scripts.
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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
Re: [0/5] Parsers for git objects, porting some programs
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 the code, I don't have any objections at all. Could you clarify the fsck issue about reading the same object twice? When does that happen? Linus - 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
Re: [darcs-devel] Darcs and git: plan of action
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, in the context of making hunks better align with blocks of code). We could perhaps tell users not to use replace patches. But avoiding mv patches would be downright silly. Okay, I still haven't used git yet (and have only toyed around with darcs for a bit), so take what I'm saying with a grain of salt. Regardless, I think you may be asking the wrong question. The tracking of renames was bandied about pretty thoroughly on-list from Wednesday through Friday (for far better commentary and insight, see Linus' messages with subject: Merge with git-pasky II.) git does track changesets that describe the parent tree(s) and the result. The trees track filenames and hashes. So, doing a fairly straightforward compare on two trees will let you immediately discover renames that have occurred, as the filename in the tree changed while the hash didn't. So, the question then becomes, can an outside tool cheaply derive all the information that darcs would need to perform it's work? The renames should be easy, as long as no content changed during the rename. As for token replacement (and whitespace changes, etc.), that could be discovered via domain-specific parsers (something specific per language, for example). Linus tossed a link to one such tool (hmm, where was it. Sheesh. You sure right a lot, dude :-).) http://minnie.tuhs.org/Programs (see Ctcompare) ...which should be viewed more as a proof-of-concept than a mergeable code-set. It does show that diff's vocabulary is sadly lacking in expressiveness, and improving that, I think, would be a useful area to expend effort. Again, I may be off here, especially considering I've a backlog of a couple hundred messages to read since the weekend. (You guys need to go outside more often.) Ray - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
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 agree. My current merge-one-file-script doesn't actually look at what the original file was in this situation, and clearly it should. I think I'll leave it for the user to decide what happens when somebody has modified the deleted file, but clearly we should delete it if the other branch has not touched it. 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 the unpacking itself with a simple cat-file blob $sha1. And the fact is, many of the trivial merges should be handled by just looking at the content, and doing a cmp on the files seems to be a stupid way to do that when we had the sha1 earlier. Done, and pushed out. Does the new merge infrastructure work for you? Linus - 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
Re: Re-done kernel archive - real one?
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 test... In doing so, I noticed that I'd messed up one of the commits - there's a missing new file. Grr. I'll put that down to being a newbie git. Actually, you should put that down to horribly bad interface tools. With BK, we had these nice tools that pointed out that there were files that you might want to commit (ie bk citool), and made this very obvious. 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. Ok, I just tried pulling your tree into the tree you pulled from, and got this: ... 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. I then checked whether my objects matched the objects which I uploaded to master.kernel.org, and discovered I'd removed some extra ones. With them restored, I have an additional dangling commit. Now, I'm pretty sure that I had an up to date tree when I did the original commits, so I'm a little confused. What I'm seeing is: b4a9a5114b3c6da131a832a8e2cd1941161eb348 +- e7905b2f22eb5d5308c9122b9c06c2d02473dd4f +- dc90c0db0dd5214aca5304fd17ccd741031e5493 -- extra dangling head +- 488faba31f59c5960aabbb2a5877a0f2923937a3 +- 5d9a545981893629c8f95e2b8b50d15d18c6ddbc +- d5922e9c35d21f0b6b82d1fd8b1444cfce57ca34 +- ff219d69be01af1fd04ada305b5fe7cd4c563cc6 +- df4449813c900973841d0fa5a9e9bc7186956e1e -- my head It's very much like I somehow committed against the _parent_ of the head, rather than the head itself. However, I've lost the state that this tree was in when I did the initial commit, so who knows why this happened... I think it's something to keep an eye out for though. -- Russell King - 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
Re: Re-done kernel archive - real one?
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 just want to go back in time, you can do this (it's equivalent to undo in BK speak): git log | less -S .. find which HEAD it was that you trusted.. In this case your HEAD before I merged with it was this one: df4449813c900973841d0fa5a9e9bc7186956e1e So to get back to that one, you can do echo df4449813c900973841d0fa5a9e9bc7186956e1e .git/HEAD and now cat-file commit $(cat .git/HEAD) | head -1 gives you tree a43c4447b2edc9fb01a6369f10c1165de4494c88 so you can restore your checked-out state with read-tree a43c4447b2edc9fb01a6369f10c1165de4494c88 checkout-cache -f -a update-cache --refresh and your tree should be valid again. Now, to remove any bogus objects, you can then run my git-prune-script (look at it carefully first to make sure you realize what you are doing). NOTE NOTE NOTE! This will _revert_ everything you had done after the trusted point. So you may not actually want to do this. Instead: It's very much like I somehow committed against the _parent_ of the head, rather than the head itself. That's very common if you just forget to update your new .git/HEAD when you do a commit. Again, it's the tools that make it a bit too easy to mess up. The commit-tree thing is supposed to really only be used from scripts (which would do something like result=$(commit-tree ...) echo $result .git/HEAD but when doing things by hand, if you forget to update your HEAD, your next commit will be done against the wrong head, and you get dangling commits. The good news is that this is not that hard to fix up. The _trees_ are all correct, and the objects are all correct, so what you can do is just generate a few new (proper) commit objects, with the right parents. Then you can do the git-prune-script thing that will throw away the old broken commits, since they won't be reachable from your new commits (even though their _trees_ will be there and be the same). So in this case: b4a9a5114b3c6da131a832a8e2cd1941161eb348 +- e7905b2f22eb5d5308c9122b9c06c2d02473dd4f +- dc90c0db0dd5214aca5304fd17ccd741031e5493 -- extra dangling head +- 488faba31f59c5960aabbb2a5877a0f2923937a3 you can do cat-file commit dc90c0db0dd5214aca5304fd17ccd741031e5493 to remind you what your old tree and commit message was, and then just re-commit that tree with the same message but with the proper parent: commit-tree -p 488faba31f59c5960aabbb2a5877a0f2923937a3 and then you need to do the same thing for the other commits (which will now need to be re-based to have the new commit-chain as their parents). Then, when you fixed up the final one, remember to update .git/HEAD with its commit ID, and now the prune-thing will get rid of the old dangling commits that you just created new duplicates of. Linus - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
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 the unpacking itself with a simple cat-file blob $sha1. So, I'm confused. Why did you introduce unpack-file instead of doing just this? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Re-done kernel archive - real one?
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 newbie might be part of it, but it's the smaller part, I say. Rough interfaces is a big issue. Speaking of tools, you had a dotest program to apply patches in email form to a bk tree. And from what I can gather, you've changed that to handle git archives, right? Yup. It's a git archive at kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git and it seems to work. It's what I've used for all the kernel patches (except for the merge), and it's what I use for the git stuff that shows up as authored by others. Hm, have you pushed all of the recent changes public? I get the following when trying to apply a patch: $ ../git-tools/dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch mailsplit mbox directory $ I set my PATH to point to the git-tools/ directory: $ which mailsplit /home/greg/linux/git/git-tools/mailsplit Any thoughts? thanks, greg k-h - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
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... Linus - 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
Re: Re-done kernel archive - real one?
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 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, you had a dotest program to apply patches in email form to a bk tree. And from what I can gather, you've changed that to handle git archives, right? Yup. It's a git archive at kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git and it seems to work. It's what I've used for all the kernel patches (except for the merge), and it's what I use for the git stuff that shows up as authored by others. Hm, have you pushed all of the recent changes public? I get the following when trying to apply a patch: $ ../git-tools/dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch mailsplit mbox directory Doh, you want it as a command line argument now. Stupid me... Anyway, I try it this way and get: $ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch Applying USB: visor Tapwave Zodiac support patch fatal: preparing to update file 'drivers/usb/serial/visor.c' not uptodate in cache What did I forget to do? thanks, greg k-h - 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
Re: Re-done kernel archive - real one?
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(+) However, it seems that git diff can't handle new files appearing yet. The other interesting thing to note is that patches are generated for '-p0' rather than '-p1' application, which is contary to our historical requirements. This is going to confuse people - can we make it generate -p1 patches please? Linus - assuming I un-messed-up my tree properly (it appears to be correct and fsck-cache $(commit-id) is happy) please merge this. Thanks. Linus, Please incorporate the latest ARM changes, which can be found at: master.kernel.org:/home/rmk/linux-2.6-rmk.git This will update the following files: 0 files changed through these ChangeSets: From: Russell King: Mon Apr 18 22:50:01 BST 2005 [PATCH] ARM: Add missing new file for bitops patch Signed-off-by: Russell King -- Russell King - 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
Re: Add + Status patches
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 git add . nor git add -r . worked. That meant that I had to fix it so I started with the ability to handle a list and, since I got a friendly response, I can hopefully move on to help make git nicer to use for mere mortals. David - 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
Re: Add + Status patches
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 a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] git-pasky-0.5
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 contains plenty of changes, it's difficult to sum it up. It has been reworked to better support the concept of branches; you can create local branches which share the GIT object repository by git fork. There is also git init which will yet you start a new GIT object repository (possibly seeding it from some rsync URL), git status, better git log, much cleaner concept of tracking (and consequently simpler yet better git pull). Of course it contains the latest updates from Linus' branch too. There is also git merge, which does some merging, but note well that it is vastly inferior to what we _can_ do (and what I will do now). Expect 0.6 soon where git merge will actually make use of the merging facilities. I released 0.5 basically only because I have been postponing it so long that I really feel ashamed of myself. ;-) Have fun, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Add + Status patches
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 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 git add . nor git add -r . worked. Actually, when I saw your patch, the xargs solution rushed through my mind but I thought that '-' might be practical too. Thinking about it, I couldn't come up with anything. So, what about instead making git add . to work? ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: [PATCH 1/1] add, rm + status patches
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 the best for attaching patches. Yes. The patch you inserted is useless, whitespaces are mangled away. I think it would be cleaner to do the testing for the dash in the for loop, so that I can do git add foo bar -. Also, don't forget to update git add's documentation at the top. For the usage string, I'd probably prefer (-|FILE)... thanks, Here you are: * git add and git rm now take (-|FILE)... * noted some bugs to be fixed * introduced de-dupe code into add and rm * git status reports added/removed files (although there are extra entries) * README, git and command docs updated I realise as I write this that I should have split these patches up - I will do so next time. Well, I didn't ask you to split the patch the first time since it was quite trivial for me to do, but this is too much. ;-) Has a decision been reached to _not_ code the cogito part of the git suite in perl? I ask because the code in git status is getting pretty ugly. I'd be happy to help with a preliminary port to perl. I'm fine with Perl. I chose shell for the very initial implementation since it actually was simplest, but now, I wouldn't have anything against Perl if it makes is simpler. (And as long as your Perl is nice. I'm harsh reviewer. ;-) Index: gitadd.sh === --- c0aff9b98c4242ab8965c428241df1d8f7a1d4bb/gitadd.sh (mode:100755 sha1:3ed93ea0fcb995673ba9ee1982e0e7abdbe35982) +++ cd5cd7a9272ce1966aca3bfce15f703e33cafc04/gitadd.sh (mode:100755 sha1:a3e83ac52abd5a9cdc6abd560f95b2f19646fd99) \ No newline at end of file Note this. Something is wrong with your text editor, too. Kind regards, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Re-done kernel archive - real one?
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 can change in git merge (and git commit), and I'm hacking that now. It should be rather easy, I think. I think I won't make git merge commit automatically - I think the user should get a chance to do a git diff on what is getting merged to check if everything is all right. 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? ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Re-done kernel archive - real one?
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 does not need to touch git pull at all now; all the relevant logic can change in git merge (and git commit), and I'm hacking that now. It should be rather easy, I think. I think I won't make git merge commit automatically - I think the user should get a chance to do a git diff on what is getting merged to check if everything is all right. 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? ;-) 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. Essentially, with BK, at 7am localtime each morning, I'd: - update my baseline linux 2.6 tree - for each working tree which may be pulled from - if the baseline is a superset - update working tree from baseline The net result is that my workflow consisted entirely of: 1. commit whatever into working tree 2. test 3. send linus a pull request 4. repeat next day The tree resynchronisation happened completely and entirely in the background with no user intervention required at all. With your suggested requirement for user intervention whenever there's a merge, it means that this just isn't possible - you could automate the pulls, but you need to ensure that you'd visited each and every unmerged tree before the next day, or you don't script it at all and do the whole thing manually. Hey, I'm lazy, and that means that just won't get done, and my trees will end up being horrendously out of date all the time. But isn't this precisely what we have computers and scripts for? -- Russell King - 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
Re: Re-done kernel archive - real one?
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 http://vger.kernel.org/majordomo-info.html
Re: Re-done kernel archive - real one?
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, you can script that cd ,,merge echo 'Merge with Linus' | git ci cd .. too. ;-) But it seems like a good idea to just proceed with commit in case of no conflicts (and possibly have a switch which will tell git merge to just merge, not commit). Essentially, with BK, at 7am localtime each morning, I'd: - update my baseline linux 2.6 tree - for each working tree which may be pulled from - if the baseline is a superset - update working tree from baseline The net result is that my workflow consisted entirely of: 1. commit whatever into working tree 2. test 3. send linus a pull request 4. repeat next day The tree resynchronisation happened completely and entirely in the background with no user intervention required at all. And in the case of conflicts...? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: Re-done kernel archive - real one?
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 'drivers/usb/serial/visor.c' not uptodate in cache What did I forget to do? The most common reason is that the scripts _really_ want the index to match your current tree exactly. Run update-cache --refresh. And if you have any uncommitted information, make sure to commit it first. (Not _strictly_ true - you can leave edited files in your directory, and just hope the patch never touches them. The thing you should _not_ do is to do an update-cache .c to commit any changes to the 'index', because then the patch applicator will actually commit that one too). Linus - 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
[PATCH] trivial fix for init-db
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) {
struct stat st;
- if (!stat(sha1_dir, st) 0 S_ISDIR(st.st_mode))
+ if (!stat(sha1_dir, st) S_ISDIR(st.st_mode))
return 0;
fprintf(stderr, DB_ENVIRONMENT set to bad directory %s: ,
sha1_dir);
}
-
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
Re: Re-done kernel archive - real one?
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? ;-) No, now that the merge is done entirely in the index file, I don't care any more. The index file _is_ the temporary directory as far as I'm concerned. Linus - 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
[PATCH 7/6] show-diff: Remove stale comments
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: b592fb131fc3949e1197bed461b8eb143f8e73ff
--- a/show-diff.c
+++ b/show-diff.c
@@ -34,9 +34,6 @@ static void prepare_diff_cmd(void)
* name == name == 'name'
* a b == a b == 'a b'
* a'b == a'\''b== 'a'\''b'
- *
- * NOTE! The returned memory belongs to this function so
- * do not free it.
*/
static char *sq_expand(char *src)
{
-
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
Re: [darcs-devel] Darcs and git: plan of action
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 at least two fundamentally different *kinds* of patches. One is the classic diff(1) style. The other is replace very instace of identifier `foo` with identifier`bar`. Note that merging such a patch with another that adds a new instance of foo has a quite different effect from a similar diff-style patch. Even though both have identical effects on the tree to which they were initially merged. And darcs is specifically intended to support additional kinds of patches. Again, all in order that the patch can work better when applied to trees *other* that the one it was originally developed against. Anyway, the point is that, in the darcs world, it is NOT possible to reconstruct a patch from the before and after trees. - 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
Re: Re-done kernel archive - real one?
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 octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: SCSI trees, merges and git status
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 your HEAD, and merge with the objects that represents. Afterwards, if I have extra objects, I'll see them with fsck-cache. Could you strip it back and I'll check out the repos on www.parisc- linux.org? 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. 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: remove meaningless scsi_cmnd-serial_number_at_timeout field [PATCH] scsi: remove unused scsi_cmnd-internal_timeout field [PATCH] remove outdated print_* functions [PATCH] consolidate timeout defintions in scsi.h or at least that's what they claim in their changelogs. Oh, and here's the diffstat that matches scsi: drivers/block/scsi_ioctl.c |5 - drivers/s390/scsi/zfcp_aux.c |4 - drivers/s390/scsi/zfcp_def.h |5 + drivers/s390/scsi/zfcp_erp.c | 20 + drivers/s390/scsi/zfcp_fsf.c | 38 -- drivers/s390/scsi/zfcp_fsf.h |6 + drivers/s390/scsi/zfcp_sysfs_adapter.c |6 + drivers/scsi/53c7xx.c | 23 +++--- drivers/scsi/BusLogic.c|7 - drivers/scsi/NCR5380.c |9 +- drivers/scsi/advansys.c|7 - drivers/scsi/aha152x.c | 17 ++-- drivers/scsi/arm/acornscsi.c |9 +- drivers/scsi/arm/fas216.c |9 +- drivers/scsi/arm/scsi.h|2 drivers/scsi/atari_NCR5380.c |9 +- drivers/scsi/constants.c |2 drivers/scsi/ips.c |7 - drivers/scsi/ncr53c8xx.c | 14 --- drivers/scsi/pci2000.c |4 - drivers/scsi/qla2xxx/qla_dbg.c |6 - drivers/scsi/scsi.c|5 - drivers/scsi/scsi.h| 43 --- drivers/scsi/scsi_error.c | 11 --- drivers/scsi/scsi_ioctl.c |5 - drivers/scsi/scsi_lib.c|2 drivers/scsi/scsi_obsolete.h | 106 - drivers/scsi/scsi_priv.h |5 - drivers/scsi/seagate.c |5 - drivers/scsi/sg.c |3 drivers/scsi/sun3_NCR5380.c|9 +- drivers/scsi/sym53c8xx_2/sym_glue.c|6 - drivers/scsi/ultrastor.c |4 - so it doesn't look like there's a _lot_ wrong. Send in a patch to revert anything that needs reverting.. Linus - 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
Re: [darcs-devel] Darcs and git: plan of action
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 course, that means patches from others are less commutable than from other darcs users, but that's the price you'd pay for relying on the user to explicitly note a token rename. [1] An example: http://minnie.tuhs.org/Programs/Ctcompare/index.html As for darcs mv, that can be derived from the before/after pictures of the trees. And darcs is specifically intended to support additional kinds of patches. Anything missing out of what I listed above? (darcs has adddir and addfile, IIRC, but those are trivially discovered via inspection of the trees as well, I think.) Anyway, the point is that, in the darcs world, it is NOT possible to reconstruct a patch from the before and after trees. Not yet, and maybe not ever, but I think we can certainly get closer to discovering what the coder was thinking during a changeset. Ray - 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
Re: yet another gitting started
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. http://www.xenotime.net/linux/doc/git-usage-howto Thanks! Helped me to start :) - 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
Re: SCSI trees, merges and git status
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: remove meaningless scsi_cmnd-serial_number_at_timeout field [PATCH] scsi: remove unused scsi_cmnd-internal_timeout field [PATCH] remove outdated print_* functions [PATCH] consolidate timeout defintions in scsi.h Those are a subset of patches from my scsi-misc-2.6 tree .. that's the problem. The actual patches should be: o zfcp: convert to compat_ioctl o sg.c: update o updates for CFQ oops fix o finally fix 53c700 to use the generic iomem infrastructure o fix NMI lockup with CFQ scheduler I've redone the scsi-rc-fixes-2.6 tree to remove all the contamination and reset the head correctly. I've verified that if I strip your tree back to 54ff646c589dcc35182d01c5b557806759301aa3 and then do a git-pull-script rsync://www.parisc-linux.org/~jejb/scsi-rc-fixes-2.6.git Then the git-pull... script actually does the merge and the resulting tree checks out against BK Sorry for the screw up. James or at least that's what they claim in their changelogs. Oh, and here's the diffstat that matches scsi: drivers/block/scsi_ioctl.c |5 - drivers/s390/scsi/zfcp_aux.c |4 - drivers/s390/scsi/zfcp_def.h |5 + drivers/s390/scsi/zfcp_erp.c | 20 + drivers/s390/scsi/zfcp_fsf.c | 38 -- drivers/s390/scsi/zfcp_fsf.h |6 + drivers/s390/scsi/zfcp_sysfs_adapter.c |6 + drivers/scsi/53c7xx.c | 23 +++--- drivers/scsi/BusLogic.c|7 - drivers/scsi/NCR5380.c |9 +- drivers/scsi/advansys.c|7 - drivers/scsi/aha152x.c | 17 ++-- drivers/scsi/arm/acornscsi.c |9 +- drivers/scsi/arm/fas216.c |9 +- drivers/scsi/arm/scsi.h|2 drivers/scsi/atari_NCR5380.c |9 +- drivers/scsi/constants.c |2 drivers/scsi/ips.c |7 - drivers/scsi/ncr53c8xx.c | 14 --- drivers/scsi/pci2000.c |4 - drivers/scsi/qla2xxx/qla_dbg.c |6 - drivers/scsi/scsi.c|5 - drivers/scsi/scsi.h| 43 --- drivers/scsi/scsi_error.c | 11 --- drivers/scsi/scsi_ioctl.c |5 - drivers/scsi/scsi_lib.c|2 drivers/scsi/scsi_obsolete.h | 106 - drivers/scsi/scsi_priv.h |5 - drivers/scsi/seagate.c |5 - drivers/scsi/sg.c |3 drivers/scsi/sun3_NCR5380.c|9 +- drivers/scsi/sym53c8xx_2/sym_glue.c|6 - drivers/scsi/ultrastor.c |4 - so it doesn't look like there's a _lot_ wrong. Send in a patch to revert anything that needs reverting.. Linus - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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
Re: SCSI trees, merges and git status
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 no reason why an
http-based 'git pull' couldn't simply refrain from fetching commits
older than a certain threshold.
Yes, that's what I did to get back to the commit just before the merge:
fsck-cache --unreachable 54ff646c589dcc35182d01c5b557806759301aa3|awk
'/^unreachable /{print $2}'|sed 's:^\(..\):.git/objects/\1/:'|xargs rm
removes all the objects from the tree prior to the bogus commit---it's
based on your (Linus') git-prune-script.
James
-
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
Re: SCSI trees, merges and git status
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 pulled from you, so not only will that confuse everybody who already got the up-to-date tree, it will also undo stuff that was correct. In other words, HISTORY CANNOT BE UNDONE. That's the rule, and it's a damn good one. It was the rule when we used BK, and it's the rule now. The fact that you can undo your history in _your_ tree doesn't change anything at all. So I can merge with your new tree, but that won't actually help any: I'll just get a superset, the way you did things. The way to remove patches is to explicitly revert them (effectively applying a reverse diff), but I'm wondering if it's worth it in this case. I looked at the patches I did get, and they didn't look horribly bad per se. Are they dangerous? 2.6.12 is some time away, if for no other reason than the fact that this SCM thing has obviously eaten two weeks of my time. So I'd be inclined to chalk this up as a learning experience with git, and just go forward. Linus - 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
Re: [darcs-devel] Darcs and git: plan of action
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, not effects, and it is impossible to derive the rules just by looking at the results. Not difficult. Impossible. You could guess, but that's not good enough for darcs to be able to reliably commute the patches later. I am curious whether Linus's suggestion about including the corresponding darcs patch id in the git commit comments would be good enough. As for darcs mv, that can be derived from the before/after pictures of the trees. Perhaps. If a file is moved and edited within the same commit, I'm not sure that you can be certain whether it was done with d 'darcs mv' or not. Requiring separate checkins for the rename and the subsequent modify would make things easier on SCM's, but is impractical in real life. Automated refactoring tools, for example, perform the rename+modify as an atomic operation. Now, git might not need to deal with any of this, because it only needs to work with the kernel project. But darcs does have to deal with this wide range of uses, as does just about any other SCM. I'm *not* advocating cluttering up git with features that are not directly needed for kernel development. I'm just trying to clarify the facts so everyone can understand what darcs is trying to do. Kevin - 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
Re: [PATCH] provide better committer information to commit-tree.c
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 be forced to obfuscate his email addresses in the changelog commits (as he did for the bk ones.) He's talking about his own interpretation of the UK's Data Protection Act, which requires you to be registered and fulfil certain other requirements if you keep personal information about people in a database. Email addresses have been ruled to be 'personal information' in this context, but this _isn't_ an email address -- and there are other get-out clauses for noncommercial situations such as this anyway, I believe. Besides, he can still obscure the author information as he unfortunately insists on doing; it's the _committer_ information which we're discussing here -- and that's always going to be himself in this case. -- dwmw2 - 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
Re: [0/5] Parsers for git objects, porting some programs
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 shortly. Currently it just borrows from object.refs to represent its children Note that object.refs needs to get filled out for those applications, even if the information is also included in the parse; object.refs is for finding what you can reach without worrying about how you do it. -Daniel *This .sig left intentionally blank* - 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
More patches
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 extensions. 3 might be best for the pasky tree. 4 is mostly a demo of 2 and because Linus thought it was a better algorithm. -Daniel *This .sig left intentionally blank* - 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
[1/4] Report info from trees
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
===
--- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.c (mode:100644
sha1:7c5e5e46f4967b0812b06c0114946c3a6432c8d8)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.c (mode:100644
sha1:39f9cbd1908e9046c148339f816025c9313ec142)
@@ -27,6 +27,7 @@
char type[20];
void *buffer, *bufptr;
unsigned long size;
+ struct tree_entry_list **list_p;
if (item-object.parsed)
return 0;
item-object.parsed = 1;
@@ -38,8 +39,10 @@
if (strcmp(type, tree_type))
return error(Object %s not a tree,
sha1_to_hex(item-object.sha1));
+ list_p = item-entries;
while (size) {
struct object *obj;
+ struct tree_entry_list *entry;
int len = 1+strlen(bufptr);
unsigned char *file_sha1 = bufptr + len;
char *path = strchr(bufptr, ' ');
@@ -48,6 +51,11 @@
sscanf(bufptr, %o, mode) != 1)
return -1;
+ entry = malloc(sizeof(struct tree_entry_list));
+ entry-directory = S_ISDIR(mode);
+ entry-executable = mode S_IXUSR;
+ entry-next = NULL;
+
/* Warn about trees that don't do the recursive thing.. */
if (strchr(path, '/')) {
item-has_full_path = 1;
@@ -56,12 +64,17 @@
bufptr += len + 20;
size -= len + 20;
- if (S_ISDIR(mode)) {
- obj = lookup_tree(file_sha1)-object;
+ if (entry-directory) {
+ entry-item.tree = lookup_tree(file_sha1);
+ obj = entry-item.tree-object;
} else {
- obj = lookup_blob(file_sha1)-object;
+ entry-item.blob = lookup_blob(file_sha1);
+ obj = entry-item.blob-object;
}
add_ref(item-object, obj);
+
+ *list_p = entry;
+ list_p = entry-next;
}
return 0;
}
Index: tree.h
===
--- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.h (mode:100644
sha1:14ebbacded09d5e058c7f94652dcb9e12bc31cae)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.h (mode:100644
sha1:985500e2a9130fe8c33134ca121838af9320c465)
@@ -5,9 +5,20 @@
extern const char *tree_type;
+struct tree_entry_list {
+ struct tree_entry_list *next;
+ unsigned directory : 1;
+ unsigned executable : 1;
+ union {
+ struct tree *tree;
+ struct blob *blob;
+ } item;
+};
+
struct tree {
struct object object;
unsigned has_full_path : 1;
+ struct tree_entry_list *entries;
};
struct tree *lookup_tree(unsigned char *sha1);
-
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
[2/4] Sorting commits by date
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
===
--- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.c (mode:100644
sha1:0099baa63971d86ee30ef2a7da25057f0f45a964)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.c (mode:100644
sha1:ef9af397471817837e1799d72f6707e0ccc949b9)
@@ -83,3 +83,47 @@
free(temp);
}
}
+
+static void insert_by_date(struct commit_list **list, struct commit *item)
+{
+ struct commit_list **pp = list;
+ struct commit_list *p;
+ while ((p = *pp) != NULL) {
+ if (p-item-date item-date) {
+ break;
+ }
+ pp = p-next;
+ }
+ struct commit_list *insert = malloc(sizeof(struct commit_list));
+ insert-next = *pp;
+ *pp = insert;
+ insert-item = item;
+}
+
+
+void sort_by_date(struct commit_list **list)
+{
+ struct commit_list *ret = NULL;
+ while (*list) {
+ insert_by_date(ret, (*list)-item);
+ *list = (*list)-next;
+ }
+ *list = ret;
+}
+
+struct commit *pop_most_recent_commit(struct commit_list **list)
+{
+ struct commit *ret = (*list)-item;
+ struct commit_list *parents = ret-parents;
+ struct commit_list *old = *list;
+
+ *list = (*list)-next;
+ free(old);
+
+ while (parents) {
+ parse_commit(parents-item);
+ insert_by_date(list, parents-item);
+ parents = parents-next;
+ }
+ return ret;
+}
Index: commit.h
===
--- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.h (mode:100644
sha1:8cd20b046875f5f7e534b0607fdd97f330f53272)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.h (mode:100644
sha1:35679482132ae5a6b7d72bbb684f21472470717c)
@@ -24,4 +24,8 @@
void free_commit_list(struct commit_list *list);
+void sort_by_date(struct commit_list **list);
+
+struct commit *pop_most_recent_commit(struct commit_list **list);
+
#endif /* COMMIT_H */
-
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
[3/4] Add http-pull
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
sha1:803f1d49c436efa570d779db6d350efbceb29ddd)
+++ f7f62e0d2a822ad0937fd98a826f65ac7f938217/Makefile (mode:100644
sha1:a3d26213c085e8b6bbc1ec352df0996e558e7c38)
@@ -15,7 +15,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 merge-base merge-cache unpack-file
+ check-files ls-tree merge-base merge-cache unpack-file http-pull
all: $(PROG)
@@ -81,6 +81,11 @@
unpack-file: unpack-file.o $(LIB_FILE)
$(CC) $(CFLAGS) -o unpack-file unpack-file.o $(LIBS)
+http-pull: LIBS += -lcurl
+
+http-pull: http-pull.o $(LIB_FILE)
+ $(CC) $(CFLAGS) -o http-pull http-pull.o $(LIBS)
+
blob.o: $(LIB_H)
cat-file.o: $(LIB_H)
check-files.o: $(LIB_H)
@@ -105,6 +110,7 @@
usage.o: $(LIB_H)
unpack-file.o: $(LIB_H)
write-tree.o: $(LIB_H)
+http-pull.o: $(LIB_H)
clean:
rm -f *.o $(PROG) $(LIB_FILE)
Index: http-pull.c
===
--- /dev/null (tree:50afb5dd4184842d8da1da8dcb9ca6a591dfc5b0)
+++ f7f62e0d2a822ad0937fd98a826f65ac7f938217/http-pull.c (mode:100644
sha1:bd251f9e0748784bbd2cd5cf720f126d852fe888)
@@ -0,0 +1,170 @@
+#include fcntl.h
+#include unistd.h
+#include string.h
+#include stdlib.h
+#include cache.h
+#include commit.h
+#include errno.h
+#include stdio.h
+
+#include curl/curl.h
+#include curl/easy.h
+
+static CURL *curl;
+
+static char *base;
+
+static int tree = 0;
+static int commits = 0;
+static int all = 0;
+
+static int has(unsigned char *sha1)
+{
+ char *filename = sha1_file_name(sha1);
+ struct stat st;
+
+ if (!stat(filename, st))
+ return 1;
+ return 0;
+}
+
+static int fetch(unsigned char *sha1)
+{
+ char *hex = sha1_to_hex(sha1);
+ char *filename = sha1_file_name(sha1);
+
+ char *url;
+ char *posn;
+ FILE *local;
+ struct stat st;
+
+ if (!stat(filename, st)) {
+ return 0;
+ }
+
+ local = fopen(filename, w);
+
+ if (!local)
+ return error(Couldn't open %s\n, filename);
+
+ curl_easy_setopt(curl, CURLOPT_FILE, local);
+
+ url = malloc(strlen(base) + 50);
+ strcpy(url, base);
+ posn = url + strlen(base);
+ strcpy(posn, objects/);
+ posn += 8;
+ memcpy(posn, hex, 2);
+ posn += 2;
+ *(posn++) = '/';
+ strcpy(posn, hex + 2);
+
+ curl_easy_setopt(curl, CURLOPT_URL, url);
+
+ printf(Getting %s\n, hex);
+
+ if (curl_easy_perform(curl))
+ return error(Couldn't get %s for %s\n, url, hex);
+
+ fclose(local);
+
+ return 0;
+}
+
+static int process_tree(unsigned char *sha1)
+{
+ struct tree *tree = lookup_tree(sha1);
+ struct tree_entry_list *entries;
+
+ if (parse_tree(tree))
+ return -1;
+
+ for (entries = tree-entries; entries; entries = entries-next) {
+ if (fetch(entries-item.tree-object.sha1))
+ return -1;
+ if (entries-directory) {
+ if (process_tree(entries-item.tree-object.sha1))
+ return -1;
+ }
+ }
+ return 0;
+}
+
+static int process_commit(unsigned char *sha1)
+{
+ struct commit *obj = lookup_commit(sha1);
+
+ if (fetch(sha1))
+ return -1;
+
+ if (parse_commit(obj))
+ return -1;
+
+ if (tree) {
+ if (fetch(obj-tree-object.sha1))
+ return -1;
+ if (process_tree(obj-tree-object.sha1))
+ return -1;
+ if (!all)
+ tree = 0;
+ }
+ if (commits) {
+ struct commit_list *parents = obj-parents;
+ for (; parents; parents = parents-next) {
+ if (has(parents-item-object.sha1))
+ continue;
+ if (fetch(parents-item-object.sha1)) {
+ /* The server might not have it, and
+* we don't mind.
+*/
+ continue;
+ }
+ if (process_commit(parents-item-object.sha1))
+ return -1;
+ }
+ }
+ return 0;
+}
+
+int main(int argc, char **argv)
+{
+ char *commit_id;
+ char *url;
+ int arg = 1;
+ unsigned char sha1[20];
+
+ while (arg argc argv[arg][0] == '-') {
+ if (argv[arg][1] == 't') {
+
Re: [darcs-devel] Darcs and git: plan of action
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 effects, and it is impossible to derive the rules just by looking at the results. Not difficult. Impossible. Okay, either I'm a sight stupider than I thought, or I'm not communicating well. Same net effect either way, I 'spose. If I do a token replace in an editor (say one of those fancy new-fangled refactoring thangs, or good ol' vi), a token-level comparator can discover what I did. That link I sent is an example of one such beast. The big feature of a darcs replace patch is that it works forward and backward in time. Let me try to come up with an example that can help explain it. Hopefully I'll get it right. Let's start with a file like this that exists in a project for which both you and I have darcs repos: cat dog fish Now, you change it to: cat dog dog fish while I simultaneously do a replace of dog with plant, resulting in: cat plant fish We merge. The final result in both of our trees is: cat plant plant fish Notice that just by looking at my diffs, you can't tell that I used a replace operation. I didn't just replace the instances of dog that were in my file at that moment. I conceptually replaced all instances, including ones that aren't there yet. Now, I should mention here that I personally dislike the replace operation, and I think it is more dangerous than helpful. However, other darcs users are quite happy with it, and it certainly is a creative and powerful feature. Other creative patch types have also been dreamed of. For example, a powerful language-specific refactoring operation has been discussed as a far-future possibility. That would be safe, and cool. Automated refactoring tools, for example, perform the rename+modify as an atomic operation. And that's harder, I agree. But unless I'm missing some nifty refactoring editor out there that integrates with darcs during the edit session, the user *still* has to tell the SCM about the rename manually. Although there are no such nifty refactoring tools available today, they will exist at some point. If they existed today, the world would be a better place. Even without tools, many shops have policies against checking in code that won't compile. If you rename a java class, you must simultaneously perform the rename and modify the class name inside. If you commit between those steps, it's broken. [I do realize that the kernel doesn't have java code, by the way.] I should also mention that I currently believe that Linus is correct that explicit rename tracking is not required for git. I have every hope that his plan for handling the more general case of moved text will take care of renames as a side effect. I don't know if that will be sufficient to allow a two-way lossless gateway between git and darcs or other systems that do track renames explicitly. Kevin - 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
Re: [2/4] Sorting commits by date
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
sha1:0099baa63971d86ee30ef2a7da25057f0f45a964)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.c (mode:100644
sha1:ef9af397471817837e1799d72f6707e0ccc949b9)
@@ -83,3 +83,47 @@
free(temp);
}
}
+
+static void insert_by_date(struct commit_list **list, struct commit *item)
+{
+ struct commit_list **pp = list;
+ struct commit_list *p;
+ while ((p = *pp) != NULL) {
+ if (p-item-date item-date) {
+ break;
+ }
+ pp = p-next;
+ }
+ struct commit_list *insert = malloc(sizeof(struct commit_list));
+ insert-next = *pp;
+ *pp = insert;
+ insert-item = item;
+}
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 through unnoticed and we can decide on a policy
regarding this.
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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
Re: [2/4] Sorting commits by date
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 through unnoticed and we can decide on a policy regarding this. I, at least, would REALLY like to see _highly_ portable C code; I'm looking at git as a potential long-term useful SCM tool for LOTS of projects, and if you're going to write C, it'd be nice to just write it portably to start with. There's certainly no crisis in using separate declarators. In fact, in the LONG term I'd like to see the shell code replaced with code that easily runs everywhere (Windows, etc.), again, for portability's sake. I think that would be unwise to do that right now; the shell is an excellent prototyping tool. But once things have settled down there's been some experience with the tools, the pieces could be slowly recoded. (Yes, I know of use Cygwin. And I prefer Python over Perl, but I'm really uninterested in language wars.) --- David A. Wheeler - 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
Re: [2/4] Sorting commits by date
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: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: SCSI trees, merges and git status
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 new drivers/scsi/lpfc) 2) the merge testing logic is wrong. You only want to exit 1 if the merge fails. Applied. Linus - 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
[GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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 drivers/i2c/chips/it87.c|2 +- drivers/i2c/chips/via686a.c |7 ++- drivers/w1/w1.c |9 + drivers/w1/w1_smem.c|4 ++-- 4 files changed, 10 insertions(+), 12 deletions(-) - 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
Re: [PATCH] Automerge fix
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 more readable, short and sweet?
merge $src2 $orig $src1 || {
echo Leaving conflict merge in $src2 exit 1
}
cp $src2 $4 exec update-cache --add -- $4
You did not want subshell so I just changed the () pair to the
{} pair, and while I was at it I folded the exit 0 into the
last command before it, which should be better. You'd want to
know if update-cache --add failed for whatever reason.
-
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
Re: True git merge in git-pasky
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 unpack-file.o libgit.a libgit.a -lssl -lz make: commit-id: Command not found Generating gitversion.sh... Is this bad? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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
