[PATCH] Make git-rename-script behave much better when faced with input contain Perl regular expression metacharacters.
Also, restore support for the GIT_DIR
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
git-rename-script | 26 ++
1 files changed, 10 insertions(+), 16 deletions(-)
1ed66638c7ce328d882639447b80099f096c2993
diff --git a/git-rename-script b/git-rename-script
--- a/git-rename-script
+++ b/git-rename-script
@@ -12,11 +12,8 @@ use strict;
sub usage($);
# Sanity checks:
-my $GIT_DIR = $$ENV{'GIT_DIR'};
-$GIT_DIR = .git unless defined $GIT_DIR;
-
-unless ( -d $GIT_DIR -d $GIT_DIR . /objects
- -d $GIT_DIR . /objects/00 -d $GIT_DIR . /refs) {
+unless ( -d .git -d .git/objects
+ -d .git/objects/00 -d .git/refs) {
usage(Git repository not found.);
}
@@ -34,26 +31,23 @@ if (-e $dst) {
my (@allfiles,@srcfiles,@dstfiles);
-$/ = \0;
-open(F,-|,git-ls-files,-z)
+open(F,-|,git-ls-files)
or die Failed to open pipe from git-ls-files: . $!;
[EMAIL PROTECTED] = map { chomp; $_; } F;
[EMAIL PROTECTED] = F;
close(F);
+chomp for @allfiles;
+
-my $safesrc = quotemeta($src);
[EMAIL PROTECTED] = grep /^$safesrc/, @allfiles;
[EMAIL PROTECTED] = grep /^$src/, @allfiles;
@dstfiles = @srcfiles;
-s#^$safesrc(/|$)#$dst$1# for @dstfiles;
+s#^$src(/|$)#$dst$1# for @dstfiles;
rename($src,$dst)
or die rename failed: $!;
-my $rc = system(git-update-cache,--add,--,@dstfiles);
-die git-update-cache failed to add new name with code $?\n if $rc;
-
-$rc = system(git-update-cache,--remove,--,@srcfiles);
-die git-update-cache failed to remove old name with code $?\n if $rc;
+system(git-update-cache,--remove,--,@srcfiles);
+system(git-update-cache,--add,--,@dstfiles);
sub usage($) {
--
Ryan Anderson
sometimes Pug Majere
-
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 git-request-pull-script, a short script that generates a summary of pending changes
On Tue, Jul 26, 2005 at 03:30:36AM -0400, Ryan Anderson wrote: A short message requesting a pull from the repository is also included. And, an example (which has a correct version of my fixes to git-rename-script included in it.) To generate this I used: git request-pull origin x rsync://h4x0r5.com/git-ryan.git/ The git repository at: rsync://h4x0r5.com/git-ryan.git/ contains the following changes since commit 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de Ryan Anderson: Add git-request-pull-script, a short script that generates a summary of pending changes Make git-rename-script behave much better when faced with input contain Perl Update the documentation for git-tag-script to reflect current behavior. Add documentation for git-rename-script Add support for directories to git-rename-script. Documentation/git-rename-script.txt | 34 Documentation/git-tag-script.txt| 12 +++-- Makefile|3 - git-rename-script | 74 +--- git-request-pull-script | 36 + 5 files changed, 149 insertions(+), 10 deletions(-) -- Ryan Anderson sometimes Pug Majere - 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] Make git-rename-script behave better with input containing Perl regexp metachars.
Make git-rename-script behave much better when faced with input contain Perl
regular expression metacharacters.
Also, restore support for the GIT_DIR
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
git-rename-script | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
28d2bb7cbb38424c4c6879110bf8aff1e3e5ac42
diff --git a/git-rename-script b/git-rename-script
--- a/git-rename-script
+++ b/git-rename-script
@@ -12,8 +12,11 @@ use strict;
sub usage($);
# Sanity checks:
-unless ( -d .git -d .git/objects
- -d .git/objects/00 -d .git/refs) {
+my $GIT_DIR = $$ENV{'GIT_DIR'};
+$GIT_DIR = .git unless defined $GIT_DIR;
+
+unless ( -d $GIT_DIR -d $GIT_DIR . /objects
+ -d $GIT_DIR . /objects/00 -d $GIT_DIR . /refs) {
usage(Git repository not found.);
}
@@ -31,23 +34,26 @@ if (-e $dst) {
my (@allfiles,@srcfiles,@dstfiles);
-open(F,-|,git-ls-files)
+$/ = \0;
+open(F,-|,git-ls-files,-z)
or die Failed to open pipe from git-ls-files: . $!;
[EMAIL PROTECTED] = F;
[EMAIL PROTECTED] = map { chomp; $_; } F;
close(F);
-chomp for @allfiles;
-
[EMAIL PROTECTED] = grep /^$src/, @allfiles;
+my $safesrc = quotemeta($src);
[EMAIL PROTECTED] = grep /^$safesrc/, @allfiles;
@dstfiles = @srcfiles;
-s#^$src(/|$)#$dst$1# for @dstfiles;
+s#^$safesrc(/|$)#$dst$1# for @dstfiles;
rename($src,$dst)
or die rename failed: $!;
-system(git-update-cache,--remove,--,@srcfiles);
-system(git-update-cache,--add,--,@dstfiles);
+my $rc = system(git-update-cache,--add,--,@dstfiles);
+die git-update-cache failed to add new name with code $?\n if $rc;
+
+$rc = system(git-update-cache,--remove,--,@srcfiles);
+die git-update-cache failed to remove old name with code $?\n if $rc;
sub usage($) {
-
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: updating the git documentation on http://www.kernel.org/pub/software/scm/git/docs/
Junio C Hamano wrote: Thomas Glanzmann [EMAIL PROTECTED] writes: I hope you're the right contact person for this. Could you please update the documentation on http://www.kernel.org/pub/software/scm/git/docs/ . It is a bit outdated. I just wanted to send a co-worker a link to the 'migration from cvs' URL and couldn't find one. Thomas, I suspect you have a wrong David, and would want to ask David Greaves instead. quite right. I've dropped out somewhat since moving house/job. I'll fix it. 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: [PATCH] git-cvsimport-script: parse multidigit revisions
On Mon, 25 Jul 2005, Linus Torvalds wrote: David, how about a patch like this to cvsps? My very very limited testing seems to say that it does the right thing.. Hmm.. David Mansfields address is bouncing, and it's apparently not just that cvsps thing, since it says that the MX machine can't be looked up. Does anybody have an alternate address for him? All the ones I've seen so far with google are at the same failing dm.cobite.com address. 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] git-cvsimport-script: parse multidigit revisions
Linus Torvalds wrote: Hmm.. David Mansfields address is bouncing, and it's apparently not just that cvsps thing, since it says that the MX machine can't be looked up. Does anybody have an alternate address for him? All the ones I've seen so far with google are at the same failing dm.cobite.com address. Last message from him to this list came from david at cobite.com two months ago. Have you tried that one? Rene - 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
Linux BKCVS kernel history git import..
Ok, I'm uploading my current git CVS import results to kernel.org right now, which is my current best effort (meaning: I may try to improve on it even if there aren't any more cvsps bugs/features I have to fix, and obviously I'll re-create it if there _are_ cvsps or cvsimport bugs that cause the import to have problems). I've verified it in the sense that I've done a git-whatchanged -p at various stages of the import, and it looked sane. I also compared doing a tar-tree-export of the 2.6.12-rc2 release, which exists both in my current git tree _and_ in the old bkcvs tree, and they compared identically apart from the fact that the bkcvs tree has the BitKeeper/ directory and a ChangeSet file. It's also pretty aggressively packed - I used --window=50 --depth=50 (rather than the default 10 for both) to make the archive smaller, so it's going to be somewhat more CPU-intensive to use (due to the possibly longer delta chains), but it got the pack-file down from 204MB to 166MB, which I think is pretty damn good for three years of history or whatever it is. Especially considering that a gzip -9'd tar-file of the 2.6.12-rc2 release is 45MB all on its own, that archive is just 3.6 times a single tree. Of course, this _is_ the cvs import, which means that it's basically just a straight-line linearization of the real BK history, but it's a pretty good linearization and so it's certainly useful. If somebody adds some logic to parse_commit() to do the fake parent thing, you can stitch the histories together and see the end result as one big tree. Even without that, you can already do things like git diff v2.6.10..v2.6.12 (which crosses the BK-git transition) by just copying the 166MB pack-file over, along with the tags that come with the thing. I've not verified it, but if that doesn't work, then it's a git bug. It _should_ work. BIG NOTE! This is definitely one archive you want to rsync instead of closing with a git repack. The unpacked archive is somewhere in the 2.4GB region, and since I actually used a higher compression ratio than the default, you'll transfer a smaller pack that way anyway. It will probably take a while to mirror out (in fact, as I write this, the DSL upload just from my local machine out still has fifteen minutes to go), but it should be visible out there soonish. Please holler if you find any problems with the conversion, or if you just have suggestions for improvments. It actually took something like 16 hours to do the conversion on my machine (most of it appears to have been due to CVS being slow, the git parts were quick), so I won't re-convert for any trivial things. I'm planning on doing the 2.4 tree too some day - either as a separate branch in the same archive, or as a separate git archive, I haven't quite decided yet. But I was more interested int he 2.6.x tree (for obvious reasons), and before I do the 2.4.x one I'd like to give that tree some time for people to check if the conversion was ok. One thing that could be verified, for example (but that I have _not_ done), is to do a few random git diff v2.6.x..v2.6.y and comparing the result with the standard diffs that are out there. Just to verify that the archive looks ok. I assume there is some diff-compare out there that can handle the fact that the files are diffed in a different order (and with different flags) etc. 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: Linux BKCVS kernel history git import..
El Tue, 26 Jul 2005 11:57:43 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: I'm planning on doing the 2.4 tree too some day - either as a separate branch in the same archive, or as a separate git archive, I haven't quite It'd be great to have the same thing but for the 1.0 - 2.2 tree. Of course there are no changelogs for that, but incremental patches are still available, and it'd be very interesting (for historical reasons) to see how things were added/removed - 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] git-cvsimport-script: parse multidigit revisions
Linus Torvalds wrote: On Mon, 25 Jul 2005, Linus Torvalds wrote: And they are in the wrong order, so cvsimport ends up committing the last one, which is the _empty_ one. Notice? We'll end up committing COPYING 1.1 (the empty initial create) even though we _should_ have committed COPYING 1.2 (the actual thing that BK committed). David, how about a patch like this to cvsps? My very very limited testing seems to say that it does the right thing.. It's very simple: if we are adding the same file twice to the same PatchSet, we just look at the ordering of the revisions. If the revision we're adding is older than the revision we already have, we just drop that revision entirely. If it's the same, something is really wrong, and we add it to the collisions list. And if it's newer, then we remove the old revision for that file, and add the new one instead. As far as I can tell, the old code really was broken, since it would happen to list different revisions in a random order when you had multiple changes to the same file in the same patchset. This one always selects the last one, which would seem to be the sane behaviour. And this all seem to make git cvsimport -p --bkcvs do the right thing. I've been 'off the web' for a few weeks on vacation. I'll look at the context of the thread. It 'smells' wierd to have to revisions in the same patchset at all, but I suppose you've all been through that before. So let me catch up with this thread and get back to you... 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: Linux BKCVS kernel history git import..
Diego Calleja wrote: El Tue, 26 Jul 2005 11:57:43 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: I'm planning on doing the 2.4 tree too some day - either as a separate branch in the same archive, or as a separate git archive, I haven't quite It'd be great to have the same thing but for the 1.0 - 2.2 tree. Of course there are no changelogs for that, but incremental patches are still available, and it'd be very interesting (for historical reasons) to see how things were added/removed Also a really good stress test for the various git-blame/git-annotate implementations. - 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
