* Re: Linux BKCVS kernel history git import..
From: A Large Angry SCM @ 2005-07-26 22:01 UTC (permalink / raw)
To: git
In-Reply-To: <20050726213643.7ca44e96.diegocg@gmail.com>
Diego Calleja wrote:
> El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
> Linus Torvalds <torvalds@osdl.org> 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.
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: David Mansfield @ 2005-07-26 21:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthias Urlichs, Sven Verdoolaege, Git Mailing List,
David Mansfield
In-Reply-To: <Pine.LNX.4.58.0507252028220.6074@g5.osdl.org>
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
^ permalink raw reply
* Re: Linux BKCVS kernel history git import..
From: Diego Calleja @ 2005-07-26 19:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, linux-kernel
In-Reply-To: <Pine.LNX.4.58.0507261136280.19309@g5.osdl.org>
El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
Linus Torvalds <torvalds@osdl.org> 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
^ permalink raw reply
* Linux BKCVS kernel history git import..
From: Linus Torvalds @ 2005-07-26 18:57 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Rene Scharfe @ 2005-07-26 17:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, Sven Verdoolaege, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507260949140.19309@g5.osdl.org>
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
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Linus Torvalds @ 2005-07-26 16:50 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Sven Verdoolaege, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507252028220.6074@g5.osdl.org>
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
^ permalink raw reply
* Re: Why pack+unpack?
From: Linus Torvalds @ 2005-07-26 16:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <42E5C677.2020403@pobox.com>
On Tue, 26 Jul 2005, Jeff Garzik wrote:
> >
> > Put another way: do you argue that X network transparency is a total waste
> > of time? You could certainly optimize X if you always made it be
> > local-machine only. Or you could make tons of special cases, and have X
> > have separate code-paths for local clients and for remote clients, rather
> > than just always opening a socket connection.
>
> Poor example... sure it opens a socket, but X certainly does have a
> special case local path (mit shm), and they're adding more for 3D due
> the massive amount of data involved in 3D.
.. and that's still a special case. Exactly like git does the "clone -l"
special case.
> Well, I'm not overly concerned, mostly curious. The pack+unpack step
> (a) appears completely redundant and (b) is the step that takes the most
> time here, for local pulls, after the diffstat.
It's not actually redundant. Some of the _compression_ may be, and you
could see if you prefer a smaller delta window (use "--window=0" to
git-pack-objects to totally disable delta compression), but in general you
can't actually just link the files over like with "git clone", because
that would create total chaos and a real mess if the other end was packed.
So "git pull" actually needs to copy one object at a time in order to have
sensible semantics together with "git repack". Now, you could make that
"one object at a time" thing have its own special cases ("if it's packed,
extract it as a unpacked object in the destination, if it's unpacked, just
link it if you can"), but it would just be pretty ugly.
If it ever gets to be a real performance problem, we can certainly fix it,
but in the meantime I _much_ prefer having one single path. I dislike the
rsync (and the http) paths immensely already, but at least I don't have to
use them..
Linus
^ permalink raw reply
* Re: updating the git documentation on http://www.kernel.org/pub/software/scm/git/docs/
From: David Greaves @ 2005-07-26 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Glanzmann, David Woodhouse, GIT
In-Reply-To: <7v1x5mh26l.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Thomas Glanzmann <sithglan@stud.uni-erlangen.de> 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
--
^ permalink raw reply
* [PATCH] Make git-rename-script behave better with input containing Perl regexp metachars.
From: Ryan Anderson @ 2005-07-26 7:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050726065657.GI6098@mythryan2.michonline.com>
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 <ryan@michonline.com>
---
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: " . $!;
-@allfiles = <F>;
+@allfiles = map { chomp; $_; } <F>;
close(F);
-chomp for @allfiles;
-
-@srcfiles = grep /^$src/, @allfiles;
+my $safesrc = quotemeta($src);
+@srcfiles = 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($) {
^ permalink raw reply
* Re: [PATCH] Add git-request-pull-script, a short script that generates a summary of pending changes
From: Ryan Anderson @ 2005-07-26 7:36 UTC (permalink / raw)
To: git, Linus Torvalds
In-Reply-To: <20050726073036.GJ6098@mythryan2.michonline.com>
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
^ permalink raw reply
* [PATCH] Add git-request-pull-script, a short script that generates a summary of pending changes
From: Ryan Anderson @ 2005-07-26 7:30 UTC (permalink / raw)
To: git, Linus Torvalds
A short message requesting a pull from the repository is also included.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Makefile | 3 ++-
git-request-pull-script | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 1 deletions(-)
create mode 100755 git-request-pull-script
834527420cf55d1a11a77372704229e2701108a4
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -37,7 +37,8 @@ SCRIPTS=git git-apply-patch-script git-m
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
- git-ls-remote-script git-clone-dumb-http git-rename-script
+ git-ls-remote-script git-clone-dumb-http git-rename-script \
+ git-request-pull-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-request-pull-script b/git-request-pull-script
new file mode 100755
--- /dev/null
+++ b/git-request-pull-script
@@ -0,0 +1,36 @@
+#!/bin/sh -e
+# Copyright 2005, Ryan Anderson <ryan@michonline.com>
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of Linus Torvalds.
+
+usage()
+{
+ echo "$0 <commit> <filename> <url>"
+ echo " Summarizes the changes since <commit>, stores them in <filename>"
+ echo " and includes <url> in the message generated."
+ exit 1
+}
+
+
+revision=$1
+filename=$2
+url=$3
+
+[ "$revision" ] || usage
+[ "$filename" ] || usage
+[ "$url" ] || usage
+
+baserev=`git-rev-parse $revision`
+
+(
+ echo "The git repository at:"
+ echo " $url"
+ echo "contains the following changes since commit $baserev"
+ echo ""
+ git log $revision.. | git-shortlog ;
+ git diff $revision.. | diffstat ;
+) | tee $filename
+
+echo "The above message is also stored in $filename"
+
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] Make git-rename-script behave much better when faced with input contain Perl regular expression metacharacters.
From: Ryan Anderson @ 2005-07-26 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpst7z9r9.fsf@assigned-by-dhcp.cox.net>
Also, restore support for the GIT_DIR
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
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: " . $!;
-@allfiles = map { chomp; $_; } <F>;
+@allfiles = <F>;
close(F);
+chomp for @allfiles;
+
-my $safesrc = quotemeta($src);
-@srcfiles = grep /^$safesrc/, @allfiles;
+@srcfiles = 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
^ permalink raw reply
* Re: Why pack+unpack?
From: Junio C Hamano @ 2005-07-26 6:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507252145470.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> See? Trying to have one really solid code-path is not a waste of time.
An alternative code path specialized for local case would not be
too bad.
First, finding the list of objects to copy. You can use
alternate object pool to cover the upstream repository to pull
from, and the downstream repository to pull into (both local),
run rev-list --objects, giving it prefix '^' for all refs in the
downstream repository, and the upstream head SHA1 you are
pulling. If the upstream head you are pulling is a tag, then
you may need to dereference it as well.
Among those objects, ones unpacked in the upstream can be
copied/linked to the downstream repository.
Handling packs involves a little bit of policy decision. The
current pack/unpack way always unpacks, and to emulate it, we
can cat-file in the upstream object database, pipe that to
"hash-object -w" (after giving hash-object an option to read
from the standard input) to write in the downstream repository
unpacked. Easier alternative is to just hardlink all the packs
from the upstream object database into the downstream object
database, and keep packed things packed.
Well, it starts to sound somewhat bad...
^ permalink raw reply
* Re: Why pack+unpack?
From: Jeff Garzik @ 2005-07-26 5:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507252145470.6074@g5.osdl.org>
Linus Torvalds wrote:
> First, make sure you have a recent git, it does better at optimizing the
I was using vanilla git, as of 10 minutes before I sent the email. Top
of tree is 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de.
> Secondly, what's the problem? Sure, I could special-case the local case,
> but do you really want to have two _totally_ different code-paths? In
> other words, it's absolutely NOT a complete waste of time: it's very much
> a case of trying to have a unified architecture, and the fact that it
> spends a few seconds doing things in a way that is network-transparent is
> time well spent.
>
> Put another way: do you argue that X network transparency is a total waste
> of time? You could certainly optimize X if you always made it be
> local-machine only. Or you could make tons of special cases, and have X
> have separate code-paths for local clients and for remote clients, rather
> than just always opening a socket connection.
Poor example... sure it opens a socket, but X certainly does have a
special case local path (mit shm), and they're adding more for 3D due
the massive amount of data involved in 3D.
> We do end up having a special code-path for "clone" (the "-l" flag), which
> does need it, but I seriously doubt you need it for a local pull. The most
> expensive operation in a local pull tends to be (if the repositories are
> unpacked and cold-cache) just figuring out the objects to pull, not the
> packing/unpacking per se.
Well, I'm not overly concerned, mostly curious. The pack+unpack step
(a) appears completely redundant and (b) is the step that takes the most
time here, for local pulls, after the diffstat.
Jeff
^ permalink raw reply
* Re: Why pack+unpack?
From: Linus Torvalds @ 2005-07-26 4:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <42D7F415.30609@pobox.com>
On Tue, 26 Jul, Jeff Garzik wrote:
>
> AFAICT this is
> just a complete waste of time. Why does this occur?
>
> Packing 1394 objects
> Unpacking 1394 objects
> 100% (1394/1394) done
>
> It doesn't seem to make any sense to perform work, then immediately undo
> that work, just for a local pull.
First, make sure you have a recent git, it does better at optimizing the
objects, so there are fewer of them. Of course, the above could be a real
pull of a a fair amount of work, but check that your git has this commit:
commit 4311d328fee11fbd80862e3c5de06a26a0e80046
Be more aggressive about marking trees uninteresting
because otherwise you sometimes get a fair number of objects just because
git-rev-list wasn't always being very careful, and took more objects than
it strictly needed.
Secondly, what's the problem? Sure, I could special-case the local case,
but do you really want to have two _totally_ different code-paths? In
other words, it's absolutely NOT a complete waste of time: it's very much
a case of trying to have a unified architecture, and the fact that it
spends a few seconds doing things in a way that is network-transparent is
time well spent.
Put another way: do you argue that X network transparency is a total waste
of time? You could certainly optimize X if you always made it be
local-machine only. Or you could make tons of special cases, and have X
have separate code-paths for local clients and for remote clients, rather
than just always opening a socket connection.
See? Trying to have one really solid code-path is not a waste of time.
We do end up having a special code-path for "clone" (the "-l" flag), which
does need it, but I seriously doubt you need it for a local pull. The most
expensive operation in a local pull tends to be (if the repositories are
unpacked and cold-cache) just figuring out the objects to pull, not the
packing/unpacking per se.
Linus
^ permalink raw reply
* Why pack+unpack?
From: Jeff Garzik @ 2005-07-26 4:39 UTC (permalink / raw)
To: Git Mailing List
Whenever I pull a local repository, such as
cd /spare/repo/libata-dev
git pull /spare/repo/linux-2.6/.git
git will pack, then unpack, the objects being pulled. AFAICT this is
just a complete waste of time. Why does this occur?
Packing 1394 objects
Unpacking 1394 objects
100% (1394/1394) done
It doesn't seem to make any sense to perform work, then immediately undo
that work, just for a local pull.
Jeff
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Ryan Anderson @ 2005-07-26 4:22 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Linus Torvalds, Sven Verdoolaege, Git Mailing List
In-Reply-To: <20050725234257.GC5680@kiste.smurf.noris.de>
On Tue, Jul 26, 2005 at 01:42:57AM +0200, Matthias Urlichs wrote:
> (Side question - why aren't you doing a direct bk2git import?)
The last time I went looking for a tool to do this, I failed to find it
- where can I get this?
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Linus Torvalds @ 2005-07-26 3:43 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Sven Verdoolaege, Git Mailing List, David Mansfield
In-Reply-To: <Pine.LNX.4.58.0507251922310.6074@g5.osdl.org>
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.
Linus
---
diff --git a/cvsps.c b/cvsps.c
--- a/cvsps.c
+++ b/cvsps.c
@@ -2384,8 +2384,31 @@ void patch_set_add_member(PatchSet * ps,
for (next = ps->members.next; next != &ps->members; next = next->next)
{
PatchSetMember * m = list_entry(next, PatchSetMember, link);
- if (m->file == psm->file && ps->collision_link.next == NULL)
- list_add(&ps->collision_link, &collisions);
+ if (m->file == psm->file) {
+ int order = compare_rev_strings(psm->post_rev->rev, m->post_rev->rev);
+
+ /*
+ * Same revision too? Add it to the collision list
+ * if it isn't already.
+ */
+ if (!order) {
+ if (ps->collision_link.next == NULL)
+ list_add(&ps->collision_link, &collisions);
+ return;
+ }
+
+ /*
+ * If this is an older revision than the one we already have
+ * in this patchset, just ignore it
+ */
+ if (order < 0)
+ return;
+
+ /*
+ * This is a newer one, remove the old one
+ */
+ list_del(&m->link);
+ }
}
psm->ps = ps;
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Linus Torvalds @ 2005-07-26 3:07 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Sven Verdoolaege, Git Mailing List, David Mansfield
In-Reply-To: <20050725234257.GC5680@kiste.smurf.noris.de>
On Tue, 26 Jul 2005, Matthias Urlichs wrote:
>
> That's a problem with the bkcvs tree. Remember tht Bitkeeper does
> exactly the same thing -- the 1.0 version of *any* file is empty, and
> content appears only in version 1.1.
Not really. That may be how the SCCS _deltas_ end up being done
internally, but it's definitely not how BK changesets work.
For example, in BK SCCS files (if I understood it correctly, I've not
actually looked very closely) a "rename" ends up being two deltas - the
"diff" delta and the "rename" delta. That does _not_ really mean that BK
considers it two different things, it's purely a SCCS file layout thing,
and it just shows through to bkcvs.
Similarly, apparently in SCCS the "create" event is one revision, and the
"initial data" is another one, and again, that shows up in bkcvs even
though that's not really how BK works conceptually at all.
So then the cvs archives end up showing some of these things as multiple
separate patches, but that just means that cvsps doesn't understand that
they all get collapsed into one changeset in the bk model. The fact that
some changes may end up showing as multiple deltas is just a result of BK
mostly re-using an old fileformat that just doesn't know anything at all
about changesets what-so-ever.
cvsps should really have collapsed those things into _one_ changeset. I
had thought that it would do so automatically based on the date (the date
should always be exactly the same), but it turns out that since the log
messages might be different, cvsps will split _one_ ChangeSet into
multiple patches, which is _wrong_.
In fact, I guess the log messages _will_ be different, because the bkcvs
thing will always put in the BK key in the "real" message.
I _thought_ that this was exactly what the "--bkcvs" flag was going to
notice, but it seems to not be the case. Or maybe "cvsimport" just doesn't
pass that flag through.. In fact, I just checked, and "cvsps --bkcvs"
_does_ do the right thing, and collapses all of these things to one
"PatchSet".
But I think I see why "git cvsimport" does the wrong thing: since that one
commit has _all_ the deltas associated with the commit, it looks like
this:
PatchSet 2
Date: 2002/02/05 17:40:40
Author: torvalds
Branch: HEAD
Tag: v2_4_0
Log:
Import changeset
BKrev: 3c601918i-Rse1XOIZxu4fPHUrTmmA
Members:
COPYING:1.1->1.2
COPYING:INITIAL->1.1
CREDITS:1.1->1.2
CREDITS:INITIAL->1.1
ChangeSet:1.2->1.3
MAINTAINERS:1.1->1.2
....
and notice how "COPYING" (and all other new files) has two deltas
associated with it, the "INITIAL->1.1" and the "1.1->1.2" one.
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).
> Well, the bkcvs export preserved that ... "feature".
No, the bkcvs thing exports an atomic BK commit as several deltas (with
the same date) not because it's a "feature" of BK, but partly because you
can't express what BK does in CVS, and partly because of what appears to
be purely internal BK implementation details (ie a feature of the SCCS
file).
BK did it right, and we just imported it wrong.
David - is there some way where cvsps could always order these things by
revision? I now realize that this is probably also what causes cvsps to
complain about things like:
..
PatchSet 2 has collisions
..
which means that cvsps actually _saw_ this, but just output the result in
the wrong order as far as "git cvsimport" was concerned.
The preferred solution would be to always just suppress the older revision
when you see multiple ones - it is by definition not interesting (you
cannot actually ever access it even in the original BK tree).
> (Side question - why aren't you doing a direct bk2git import?)
Because I don't have any BK trees left, and because I'm not going to touch
Andrews code. We'd have had a portable BK export format (in fact, I wrote
one as a proof-of-concept thing when we were tryign to convince Tridge
that he really doesn't want to muck inside BK internals), but then shit
happens..
So I'll use the CVS thing.
> > I realize you'd want to do that to
> > avoid connecting millions of times, but maybe it's better to use something
> > like cvsnup to download the whole thing, and then always use a local CVS
> > archive?
>
> ... I don't have a sensible RCS library for perl (the code that I could
> find is just a command line front-end). Fork+exec of some cvs checkout
> command per file is slower than just running a persistent CVS server.
Fair enough, I suspect that without a builtin RCS library it really ends
up being faster than the whole exec thing.
I thought there was a RCS library (I know I got some hits for "rcslib"
for some scripting language and was cursing the fact that it wasn't for
C), but I never really looked closer. I'm not surprised if the "library"
ends up just doing a "system()" thing.
> I've tried other ideas, but they run into problems because some
> idiots^Wpeople occasionally tag only parts of a CVS tree
Yeah, CVS really allows some very very annoying things that only work in a
file-at-a-time model.
Linus
^ permalink raw reply
* [PATCH 2/2] diff-raw: Use 'A' instead of 'N' for added files.
From: Junio C Hamano @ 2005-07-26 0:21 UTC (permalink / raw)
To: Petr Baudis, Catalin Marinas; +Cc: git
In-Reply-To: <7vpst6fmif.fsf_-_@assigned-by-dhcp.cox.net>
This actually changes the diff-raw status letter from N to A
for added files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
ca8c9156f8f980455f64e2cedcf0347328e46029
diff --git a/diff.h b/diff.h
--- a/diff.h
+++ b/diff.h
@@ -83,7 +83,7 @@ extern int diff_queue_is_empty(void);
extern void diff_flush(int output_style, int line_terminator);
/* diff-raw status letters */
-#define DIFF_STATUS_ADDED 'N'
+#define DIFF_STATUS_ADDED 'A'
#define DIFF_STATUS_COPIED 'C'
#define DIFF_STATUS_DELETED 'D'
#define DIFF_STATUS_MODIFIED 'M'
^ permalink raw reply
* [PATCH 1/2] Use symbolic constants for diff-raw status indicators.
From: Junio C Hamano @ 2005-07-26 0:20 UTC (permalink / raw)
To: Petr Baudis, Catalin Marinas; +Cc: git
In-Reply-To: <7vpst6fmif.fsf_-_@assigned-by-dhcp.cox.net>
Both Cogito and StGIT prefer to see 'A' for new files. The
current 'N' is visually harder to distinguish from 'M', which is
used for modified files. Prepare the internals to use symbolic
constants to make the change easier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-helper.c | 3 ++-
diff.c | 58 ++++++++++++++++++++++++++++++++-------------------------
diff.h | 16 ++++++++++++++++
3 files changed, 51 insertions(+), 26 deletions(-)
e7baa4f45f4420a6d2da6a13e8959f8405c3ea19
diff --git a/diff-helper.c b/diff-helper.c
--- a/diff-helper.c
+++ b/diff-helper.c
@@ -94,7 +94,8 @@ int main(int ac, const char **av) {
if (!strchr("MCRNDU", status))
break;
two_paths = score = 0;
- if (status == 'R' || status == 'C')
+ if (status == DIFF_STATUS_RENAMED ||
+ status == DIFF_STATUS_COPIED)
two_paths = 1;
/* pick up score if exists */
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -617,7 +617,7 @@ static void run_diff(struct diff_filepai
other = (strcmp(name, p->two->path) ? p->two->path : NULL);
one = p->one; two = p->two;
switch (p->status) {
- case 'C':
+ case DIFF_STATUS_COPIED:
sprintf(msg_,
"similarity index %d%%\n"
"copy from %s\n"
@@ -626,7 +626,7 @@ static void run_diff(struct diff_filepai
name, other);
xfrm_msg = msg_;
break;
- case 'R':
+ case DIFF_STATUS_RENAMED:
sprintf(msg_,
"similarity index %d%%\n"
"rename from %s\n"
@@ -635,7 +635,7 @@ static void run_diff(struct diff_filepai
name, other);
xfrm_msg = msg_;
break;
- case 'M':
+ case DIFF_STATUS_MODIFIED:
if (p->score) {
sprintf(msg_,
"dissimilarity index %d%%",
@@ -796,10 +796,12 @@ static void diff_flush_raw(struct diff_f
status[1] = 0;
}
switch (p->status) {
- case 'C': case 'R':
+ case DIFF_STATUS_COPIED:
+ case DIFF_STATUS_RENAMED:
two_paths = 1;
break;
- case 'N': case 'D':
+ case DIFF_STATUS_ADDED:
+ case DIFF_STATUS_DELETED:
two_paths = 0;
break;
default:
@@ -928,13 +930,13 @@ static void diff_resolve_rename_copy(voi
p = q->queue[i];
p->status = 0; /* undecided */
if (DIFF_PAIR_UNMERGED(p))
- p->status = 'U';
+ p->status = DIFF_STATUS_UNMERGED;
else if (!DIFF_FILE_VALID(p->one))
- p->status = 'N';
+ p->status = DIFF_STATUS_ADDED;
else if (!DIFF_FILE_VALID(p->two))
- p->status = 'D';
+ p->status = DIFF_STATUS_DELETED;
else if (DIFF_PAIR_TYPE_CHANGED(p))
- p->status = 'T';
+ p->status = DIFF_STATUS_TYPE_CHANGED;
/* from this point on, we are dealing with a pair
* whose both sides are valid and of the same type, i.e.
@@ -942,7 +944,7 @@ static void diff_resolve_rename_copy(voi
*/
else if (DIFF_PAIR_RENAME(p)) {
if (p->source_stays) {
- p->status = 'C';
+ p->status = DIFF_STATUS_COPIED;
continue;
}
/* See if there is some other filepair that
@@ -956,22 +958,22 @@ static void diff_resolve_rename_copy(voi
if (!DIFF_PAIR_RENAME(pp))
continue; /* not a rename/copy */
/* pp is a rename/copy from the same source */
- p->status = 'C';
+ p->status = DIFF_STATUS_COPIED;
break;
}
if (!p->status)
- p->status = 'R';
+ p->status = DIFF_STATUS_RENAMED;
}
else if (memcmp(p->one->sha1, p->two->sha1, 20) ||
p->one->mode != p->two->mode)
- p->status = 'M';
+ p->status = DIFF_STATUS_MODIFIED;
else {
/* This is a "no-change" entry and should not
* happen anymore, but prepare for broken callers.
*/
error("feeding unmodified %s to diffcore",
p->one->path);
- p->status = 'X';
+ p->status = DIFF_STATUS_UNKNOWN;
}
}
diff_debug_queue("resolve-rename-copy done", q);
@@ -989,7 +991,7 @@ void diff_flush(int diff_output_style, i
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
if ((diff_output_style == DIFF_FORMAT_NO_OUTPUT) ||
- (p->status == 'X'))
+ (p->status == DIFF_STATUS_UNKNOWN))
continue;
if (p->status == 0)
die("internal error in diff-resolve-rename-copy");
@@ -1024,15 +1026,17 @@ static void diffcore_apply_filter(const
if (!filter)
return;
- if (strchr(filter, 'A')) {
- /* All-or-none */
+ if (strchr(filter, DIFF_STATUS_FILTER_AON)) {
int found;
for (i = found = 0; !found && i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
- if (((p->status == 'M') &&
- ((p->score && strchr(filter, 'B')) ||
- (!p->score && strchr(filter, 'M')))) ||
- ((p->status != 'M') && strchr(filter, p->status)))
+ if (((p->status == DIFF_STATUS_MODIFIED) &&
+ ((p->score &&
+ strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||
+ (!p->score &&
+ strchr(filter, DIFF_STATUS_MODIFIED)))) ||
+ ((p->status != DIFF_STATUS_MODIFIED) &&
+ strchr(filter, p->status)))
found++;
}
if (found)
@@ -1050,10 +1054,14 @@ static void diffcore_apply_filter(const
/* Only the matching ones */
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
- if (((p->status == 'M') &&
- ((p->score && strchr(filter, 'B')) ||
- (!p->score && strchr(filter, 'M')))) ||
- ((p->status != 'M') && strchr(filter, p->status)))
+
+ if (((p->status == DIFF_STATUS_MODIFIED) &&
+ ((p->score &&
+ strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||
+ (!p->score &&
+ strchr(filter, DIFF_STATUS_MODIFIED)))) ||
+ ((p->status != DIFF_STATUS_MODIFIED) &&
+ strchr(filter, p->status)))
diff_q(&outq, p);
else
diff_free_filepair(p);
diff --git a/diff.h b/diff.h
--- a/diff.h
+++ b/diff.h
@@ -82,4 +82,20 @@ extern int diff_queue_is_empty(void);
extern void diff_flush(int output_style, int line_terminator);
+/* diff-raw status letters */
+#define DIFF_STATUS_ADDED 'N'
+#define DIFF_STATUS_COPIED 'C'
+#define DIFF_STATUS_DELETED 'D'
+#define DIFF_STATUS_MODIFIED 'M'
+#define DIFF_STATUS_RENAMED 'R'
+#define DIFF_STATUS_TYPE_CHANGED 'T'
+#define DIFF_STATUS_UNKNOWN 'X'
+#define DIFF_STATUS_UNMERGED 'U'
+
+/* these are not diff-raw status letters proper, but used by
+ * diffcore-filter insn to specify additional restrictions.
+ */
+#define DIFF_STATUS_FILTER_AON 'A'
+#define DIFF_STATUS_FILTER_BROKEN 'B'
+
#endif /* DIFF_H */
^ permalink raw reply
* Updating diff-raw status letter to 'A' for added files.
From: Junio C Hamano @ 2005-07-26 0:18 UTC (permalink / raw)
To: Catalin Marinas, Petr Baudis; +Cc: git
In-Reply-To: <7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net>
Since both of you seem to be in favor of using 'A' instead of
'N' for added files in the diff-raw output, here are two patches
requesting for test.
[PATCH] Use symbolic constants for diff-raw status indicators.
[PATCH] diff-raw: Use 'A' instead of 'N' for added files.
^ permalink raw reply
* Re: updating the git documentation on http://www.kernel.org/pub/software/scm/git/docs/
From: Junio C Hamano @ 2005-07-25 23:54 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: David Greaves, David Woodhouse, GIT
In-Reply-To: <20050725185751.GA12907@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> 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.
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Matthias Urlichs @ 2005-07-25 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sven Verdoolaege, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507251544300.6074@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
Hi,
Linus Torvalds:
> In particular, they always end up being imported as zero-sized empty
> files, and will be filled in only later if that file is ever touched
> again. In other words, the resulting git tree ends up being bogus.
>
That's a problem with the bkcvs tree. Remember tht Bitkeeper does
exactly the same thing -- the 1.0 version of *any* file is empty, and
content appears only in version 1.1.
Well, the bkcvs export preserved that ... "feature".
(Side question - why aren't you doing a direct bk2git import?)
> Argument "28213 has collisions" isn't numeric in addition (+) at /home/torvalds/bin/git-cvsimport-script line 600, <CVS> line 1.
That's an output from cvsps that is not handled yet.
If you really need it I'll have to investigate.
> Btw, looking at what the perl script _seems_ to do, it does seem to do
> insane things for the local CVS archive case. As far as I can tell from
> the spaghetti that is perl, it uses a CVS server to handle even the local
> file case, which just _can't_ be right.
Sure it is, because ...
> I realize you'd want to do that to
> avoid connecting millions of times, but maybe it's better to use something
> like cvsnup to download the whole thing, and then always use a local CVS
> archive?
... I don't have a sensible RCS library for perl (the code that I could
find is just a command line front-end). Fork+exec of some cvs checkout
command per file is slower than just running a persistent CVS server.
I've tried other ideas, but they run into problems because some
idiots^Wpeople occasionally tag only parts of a CVS tree, or they do it
at different times, and cvsps has to rearrange stuff in a way the CVS
utilities don't understand, so any higher-level access than "grab a
bunch of files by their revision number and stick them into a commit"
don't work in real life.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Please try to limit the amount of "this room doesn't have any bazingas"
until you are told that those rooms are "punched out." Once punched out,
we have a right to complain about atrocities, missing bazingas, and such.
-- N. Meyrowitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-tag-script updates.
From: Junio C Hamano @ 2005-07-25 23:02 UTC (permalink / raw)
To: git
This adds -a (annotate only but not sign) option "A Large Angry
SCM" <gitzilla@gmail.com> sent to the list, after fixing up the
whitespace corruption in the patch, with some of my own fixes.
Namely, changes are:
* A new flag '-a' can be used to create an unsigned tag
object;
* The '-f' flag logic did not do the right thing;
* When creating a signed tag, we did not check for GPG failure
as we should;
* Try to use the key for the tagger identity when signing the
tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-tag-script | 32 ++++++++++++++++++++++++++------
1 files changed, 26 insertions(+), 6 deletions(-)
0fad0fdd4beadb2ff06af8d5a16d509cd8796ee4
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -3,17 +3,30 @@
. git-sh-setup-script || die "Not a git archive"
+usage () {
+ echo >&2 "Usage: git-tag-script [-a | -s] [-f] tagname"
+ exit 1
+}
+
+annotate=
signed=
force=
while case "$#" in 0) break ;; esac
do
case "$1" in
+ -a)
+ annotate=1
+ ;;
-s)
+ annotate=1
signed=1
;;
-f)
force=1
;;
+ -*)
+ usage
+ ;;
*)
break
;;
@@ -22,16 +35,19 @@ do
done
name="$1"
-[ "$name" ] || die "I need a tag-name"
-[ -e "$GIT_DIR/refs/tags/$name" ] &&
- [ "$force" ] || die "tag '$name' already exists"
+[ "$name" ] || usage
+if [ -e "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
+ die "tag '$name' already exists"
+fi
shift
object=$(git-rev-parse --verify --revs-only --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-if [ "$signed" ]; then
+trap 'rm -f .tmp-tag* .tagmsg .editmsg' 0
+
+if [ "$annotate" ]; then
( echo "#"
echo "# Write a tag message"
echo "#" ) > .editmsg
@@ -43,9 +59,13 @@ if [ "$signed" ]; then
( echo -e "object $object\ntype $type\ntag $name\ntagger $tagger\n"; cat .tagmsg ) > .tmp-tag
rm -f .tmp-tag.asc .tagmsg
- gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
+ if [ "$signed" ]; then
+ me=$(expr "$tagger" : '\(.*>\)') &&
+ gpg -bsa -u "$me" .tmp-tag &&
+ cat .tmp-tag.asc >>.tmp-tag ||
+ die "failed to sign the tag with GPG."
+ fi
object=$(git-mktag < .tmp-tag)
- rm -f .tmp-tag .tmp-tag.sig
fi
mkdir -p "$GIT_DIR/refs/tags"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox