* Re: What's in git.git (part #2)
From: Jakub Narebski @ 2006-06-01 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wu9i608.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> It's been a while since the last feature release,...
>
> So apparently somehow part #1 (the regular "master has these",
> "next in addition has these" message I occasionally do) is not
> liked by the mailing list. I wonder what's in it that makes it
> dropped on the floor...
I had same problem (message not appearing on list), and as far as
I was able to analyse it was because message accidentally (via unclean
copy'n'paste) had some unusual characters.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Florian Forster @ 2006-06-01 9:36 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060601092238.GB9333@hand.yhbt.net>
[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]
Hi,
On Thu, Jun 01, 2006 at 02:22:39AM -0700, Eric Wong wrote:
> Nope, I haven't seen that nor Florian's patch (assuming it was sent to
> the ml). Ah, I just saw (part #2) pop up.
sorry, I'm new to the git development and didn't know that patches
should be sent to the ML. I've attached that patch I sent to Junio to
this mail.
Florian Forster <octo@verplant.org> writes:
> The regexes detecting merges (while still relying on the commit
> messages, though) have been improved to catch saner (and hopefully
> more) messages. The old regex was so generic that it often matched
> something else and missed the actual merge-message.
The assumption here is that merges are between branches or between a
branch and the trunk. The regexes therefore match things like
(parenthesis showing what is being used as the branch name if it
matches).
- `branch/(name)'
- `(trunk)'
- `(name) branch'
Prior to the patch `git-svnimport' would match the message
``Merging from branch/foo to branch/bar''
and return `from' as the branch name.
Regards,
Florian Forster
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
[-- Attachment #1.2: 0001-git-svnimport-Improved-detection-of-merges.txt --]
[-- Type: text/plain, Size: 1607 bytes --]
From nobody Mon Sep 17 00:00:00 2001
From: Florian Forster <octo@verplant.org>
Date: Wed, 31 May 2006 12:28:41 +0200
Subject: [PATCH] git-svnimport: Improved detection of merges.
The regexes detecting merges (while still relying on the commit messages,
though) have been improved to catch saner (and hopefully more) messages. The
old regex was so generic that it often matched something else and missed the
actual merge-message.
Also, the regex given with the `-M' commandline-option is checked first:
Explicitely given regexes should be considered better than the builtin ones,
and should therefore be given a chance to match a message first.
---
git-svnimport.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
1075d5b0cd92dbb8dc77838b2da2d8190904b351
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 61f559f..38ac732 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -63,10 +63,17 @@ my $svn_dir = $ARGV[1];
our @mergerx = ();
if ($opt_m) {
- @mergerx = ( qr/\W(?:from|of|merge|merging|merged) (\w+)/i );
+ my $branch_esc = quotemeta ($branch_name);
+ my $trunk_esc = quotemeta ($trunk_name);
+ @mergerx =
+ (
+ qr!\b(?:merg(?:ed?|ing))\b.*?\b((?:(?<=$branch_esc/)[\w\.\-]+)|(?:$trunk_esc))\b!i,
+ qr!\b(?:from|of)\W+((?:(?<=$branch_esc/)[\w\.\-]+)|(?:$trunk_esc))\b!i,
+ qr!\b(?:from|of)\W+(?:the )?([\w\.\-]+)[-\s]branch\b!i
+ );
}
if ($opt_M) {
- push (@mergerx, qr/$opt_M/);
+ unshift (@mergerx, qr/$opt_M/);
}
# Absolutize filename now, since we will have chdir'ed by the time we
--
1.3.3
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Junio C Hamano @ 2006-06-01 9:58 UTC (permalink / raw)
To: Florian Forster; +Cc: git
In-Reply-To: <20060601093603.GY2315@verplant.org>
Florian Forster <octo@verplant.org> writes:
> On Thu, Jun 01, 2006 at 02:22:39AM -0700, Eric Wong wrote:
>> Nope, I haven't seen that nor Florian's patch (assuming it was sent to
>> the ml). Ah, I just saw (part #2) pop up.
>
> sorry, I'm new to the git development and didn't know that patches
> should be sent to the ML. I've attached that patch I sent to Junio to
> this mail.
Thanks for a resend.
The patch is already queued in "next", so svn people might want
to take a peek there.
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Sean @ 2006-06-01 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
On Thu, 01 Jun 2006 02:19:45 -0700
Junio C Hamano <junkio@cox.net> wrote:
> - p4 importer (Sean Estabrooks) -- are people interested?
Junio,
There just won't be anywhere near the call for this as there is
for the cvs and svn importers. Even so, a few people have expressed
interest and it has been used by the Sourcemage folks with some success.
Would you consider carrying this in contrib just so it has a home?
Sean
^ permalink raw reply
* [PATCH] cg-commit -p tries to remove a non-existent file
From: Dennis Stosberg @ 2006-06-01 15:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This produces an error message when the user aborts the commit:
$ cg init -m "Initial commit"
$ echo "some text" >file
$ cg add file
$ EDITOR=/bin/false cg commit -p
Log message unchanged or not specified
Abort or commit? [ac] a
rm: cannot remove `/tmp/gitci.zdAHil/patch2.diff': No such file or \
directory
Commit message not modified, commit aborted
---
cg-commit | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-commit b/cg-commit
index 4ec2b33..c636b1a 100755
--- a/cg-commit
+++ b/cg-commit
@@ -442,7 +442,7 @@ cp "$LOGMSG" "$LOGMSG2"
if tty -s; then
if [ "$editor" ] && ! editor $commitalways commit c; then
rm "$LOGMSG" "$LOGMSG2"
- [ "$review" ] && rm "$PATCH" "$PATCH2"
+ [ "$review" ] && rm "$PATCH"
echo "Commit message not modified, commit aborted" >&2
if [ "$merging" ]; then
cat >&2 <<__END__
--
1.3.3+git20060531-dest1
^ permalink raw reply related
* git reset --hard not removing some files
From: Martin Waitz @ 2006-06-01 16:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
hoi :)
I have the following problem:
nbg1l001:~/src/git > git branch
* master
next
origin
nbg1l001:~/src/git > git checkout -b test
nbg1l001:~/src/git > git status
# On branch refs/heads/test
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git reset --hard v1.3.3
nbg1l001:~/src/git > git status
# On branch refs/heads/test
#
# Untracked files:
# (use "git add" to add to commit)
#
# git-quiltimport
# git-upload-tar
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git reset --hard master
nbg1l001:~/src/git > git status
# On branch refs/heads/test
nothing to commit
zsh: exit 1 git status
nbg1l001:~/src/git > git --version
git version 1.3.3.g0825d
However, the complete test suite and especially t7101-reset.sh succeed.
Any ideas?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Sean @ 2006-06-01 16:13 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060601160052.GK14325@admingilde.org>
On Thu, 1 Jun 2006 18:00:52 +0200
Martin Waitz <tali@admingilde.org> wrote:
Removed your prompt just to make it a bit more readable:
> $ git branch
> * master
> next
> origin
>
> $ git checkout -b test
>
> $ git status
> # On branch refs/heads/test
> nothing to commit
The generated files "git-quiltimport" and "git-upload-tar" exist at
this point. They are both untracked files and aren't listed because
they have entries in the .gitignore file.
> $ git reset --hard v1.3.3
>
> $ git status
> # On branch refs/heads/test
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # git-quiltimport
> # git-upload-tar
> nothing to commit
Resetting to version 1.3.3 gets you an old version of the .gitignore
file which doesn't ignore these two untracked files. Reset --hard
doesn't remove them because it only deals with tracked files. Thus,
they show up in your status report.
> $ git reset --hard master
> $ git status
> # On branch refs/heads/test
> nothing to commit
Returning to the current version gets you an updated .gitignore and the
two files are no longer listed even though they still exist.
> $ git --version
> git version 1.3.3.g0825d
This is the expected behavior regardless of version.
Sean
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Linus Torvalds @ 2006-06-01 16:21 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060601160052.GK14325@admingilde.org>
On Thu, 1 Jun 2006, Martin Waitz wrote:
>
> I have the following problem:
It's not a problem, it's a feature.
> nbg1l001:~/src/git > git branch
> * master
> next
> origin
> nbg1l001:~/src/git > git checkout -b test
> nbg1l001:~/src/git > git status
> # On branch refs/heads/test
> nothing to commit
> zsh: exit 1 git status
> nbg1l001:~/src/git > git reset --hard v1.3.3
> nbg1l001:~/src/git > git status
> # On branch refs/heads/test
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # git-quiltimport
> # git-upload-tar
Those files were _never_ tracked.
What happened is that when you switched to an earlier version, you _also_
switched the ".gitignore" file to the earlier version, and that older
.gitignore file doesn't have those two (newer) binaries listed as being
ignored.
And "git reset" won't be deleting files it doesn't track (it had _better_
not touch them), even more so when it has been told to ignore them, so it
makes total sense to _not_ delete them when doing that reset.
Linus
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Jakub Narebski @ 2006-06-01 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP04B113F61282BAE465D7F0AE900@CEZ.ICE>
Sean wrote:
> On Thu, 1 Jun 2006 18:00:52 +0200
> Martin Waitz <tali@admingilde.org> wrote:
>
>> $ git reset --hard v1.3.3
>>
>> $ git status
>> # On branch refs/heads/test
>> #
>> # Untracked files:
>> # (use "git add" to add to commit)
>> #
>> # git-quiltimport
>> # git-upload-tar
>> nothing to commit
>
> Resetting to version 1.3.3 gets you an old version of the .gitignore
> file which doesn't ignore these two untracked files. Reset --hard
> doesn't remove them because it only deals with tracked files. Thus,
> they show up in your status report.
Do you think it is _frequently_ asked question, worth adding
to http://git.or.cz/gitwiki/GitFaq ?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Sean @ 2006-06-01 19:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5n7lv$3tl$1@sea.gmane.org>
On Thu, 01 Jun 2006 19:21:19 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> Do you think it is _frequently_ asked question, worth adding
> to http://git.or.cz/gitwiki/GitFaq ?
Hi Jakub,
Not sure if it needs to be in the FAQ at this point, but i guess it couldn't
hurt either. The man page actually mentions that --hard deals with tracked
files. An extra example or a more explicit notice about untracked files
might be helpful though.
Sean
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Greg KH @ 2006-06-01 19:23 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1fyj4qkm2.fsf@ebiederm.dsl.xmission.com>
On Sat, May 20, 2006 at 06:36:53PM -0600, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Fri, May 19, 2006 at 08:42:38PM -0600, Eric W. Biederman wrote:
> >
> >> If it is one patch per file but with mbox headers, it is relatively
> >> simple to teach git-mailinfo to parse things in a slightly more intelligent
> >> way. I played with that but I didn't have any patches that helped with.
> >
> > Hm, I'll try playing with that.
> >
> > If you want, just grab my quilt trees from kernel.org and play with
> > them, they should all be in mbox format for the individual patches (with
> > some exceptions as noted above, just kick me about them to get me to fix
> > them...)
>
> So I just grabbed the gregkh-2.6 set of patches and with an unmodified
> git-mailinfo I only have problems with the following patches:
> gregkh/gkh-version.patch
> gregkh/sysfs-test.patch
> gregkh/gregkh-usb-minors.patch
> gregkh/gregkh-debugfs_example.patch
> gregkh/gpl_future-test.patch
> usb/usb-gotemp.patch
>
> None of which actually have from headers.
Oops, sorry for the delay. I've now fixed up these patches (the ones in
the gregkh/ directory are not ever going to be sent upstream, that's
why they were missing headers, same for the gotemp driver.)
thanks,
greg k-h
^ permalink raw reply
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Yann Dirson @ 2006-06-01 21:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT list, cvsps
In-Reply-To: <20060527163555.GM1164@nowhere.earth>
On Sat, May 27, 2006 at 06:35:55PM +0200, Yann Dirson wrote:
> > OTOH, the cvsps output you are showing us seems to be in the right
> > order... patchset 20 should go on top of patchset 3... is cvsimport
> > truly mishandling this?
>
> That's the problem. I had just copypasted the logs for handling at
> home, and then I discovered in the cvsps log that the timestamp for
> patchset 2 is the same as the one for patchset 1, which is obviously
> wrong. I'll look at the cvs repo next week to understand whether that
> comes from the RCS file, or whether it is cvsps misunderstanding
> something.
The problem indeed stems from the RCS files themselves. It thus comes
from a bug-or-feature of cvs 1.12.12. This week I have found a number
of files with such an history in various repos in use at work.
I finally realize I was trying to reproduce the problem at home using
1.12.9, where the issue does not appear to exist. The following
script does show the problem with 1.12.13.
As you see, a phantom commit is added prior to the resurecting commit
on the branch, and it has the same timestamp as the its dead base
revision on the trunk.
In the logs I had from real repositories with 1.12.12, the "lines"
attribute for the phantom revision was a mirror of the revision
following it, reflecting no reality at all (would have been "+0 -1"
here). There is no mention of such a bugfix in the cvs NEWS file, but
who knows.
I found no mention of such a feature in the 1.12.9-13 entries in the
CVS NEWS file, so I doubt that is an intended behaviour - I'll report
a bug on cvs.
However, cvsps should surely be made aware of this behaviour, even if
it is a bug, since being there for at least 2 cvs releases is enough
to have infected many repositories...
==== script
#!/bin/sh
set -e
# setup repo and working area
cvs -d $PWD/root init
mkdir root/test
cvs -d $PWD/root co test
cd test
# trunk
touch file1 file2
cvs add file1 file2
cvs ci -m "add files"
sleep 2
rm file1
cvs rm file1
cvs ci -m "rm file1"
sleep 2
cvs tag A
# branch based on trunk
cvs tag -b A_HEAD
cvs up -r A_HEAD -P
echo "stuff and more stuff" >file1
cvs add file1
cvs ci -m "work"
sleep 2
cvsps --norc -x -A
==== cvs log file1
----------------------------
revision 1.2
date: 2006-06-01 23:12:21 +0200; author: dwitch; state: dead; lines: +0 -0; commitid: GyCIctKzKqKVwlzr;
branches: 1.2.2;
rm file1
----------------------------
revision 1.1
date: 2006-06-01 23:12:17 +0200; author: dwitch; state: Exp; commitid: j1zLyPu2Bw6Uwlzr;
add files
----------------------------
revision 1.2.2.2
date: 2006-06-01 23:12:23 +0200; author: dwitch; state: Exp; lines: +1 -0; commitid: D3Fd6f9Wz8cWwlzr;
work
----------------------------
revision 1.2.2.1
date: 2006-06-01 23:12:21 +0200; author: dwitch; state: dead; lines: +0 -0; commitid: D3Fd6f9Wz8cWwlzr;
file file1 was added on branch A_HEAD on 2006-06-01 21:12:23 +0000
====
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-01 22:21 UTC (permalink / raw)
To: git
I've been working on importing the Mozilla CVS into git for the last
few days. I've fixed up parsecvs so that it can parse the entire
repository without errors. Now I'm running into problems because there
are over 300 branches.
I just run into a problem with git show-branch. Mozilla CVS has a lot
more than 29 refs, is this something that can be expanded?
Is anyone interested in helping out with this? My knowledge of git and
CVS is limited. Mozilla CVS is about 3GB and it is available via
rsync. I can post the parsecvs changes if wanted.
rsync -az cvs-mirror.mozilla.org::mozilla ~/mozilla/cvs-mirror
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Ryan Anderson @ 2006-06-01 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
On Thu, Jun 01, 2006 at 02:19:45AM -0700, Junio C Hamano wrote:
> Things that we might want to have in 1.4.0 but not even in "next"
> yet include:
>
> - p4 importer (Sean Estabrooks) -- are people interested?
I think adding more importers is a good thing. There's no sense in
having people reinvent the wheel.
Which reminds me, I need to polish and send off my BitKeeper importer.
(It's slow and dumb, but works.)
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-01 23:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On Thu, 2006-06-01 at 18:21 -0400, Jon Smirl wrote:
> Is anyone interested in helping out with this? My knowledge of git and
> CVS is limited. Mozilla CVS is about 3GB and it is available via
> rsync. I can post the parsecvs changes if wanted.
Yes, please post parsecvs changes; I've been able to import several
repositories of this size without problems (given sufficient memory).
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* HTTP questions
From: Nick Hengeveld @ 2006-06-01 23:24 UTC (permalink / raw)
To: git
While testing recent http-fetch changes with a current checkout of next,
I noticed a couple of things:
- "git push" seems to pass --thin by default to http-push, which
subsequently barfs because that's not a valid http-push option.
Should it be? Should it be silently ignored? Should git-push not
default to --thin when pushing with HTTP transport?
- when I clone, http-fetch outputs a whole bunch of
"error: Could not read ..." messages - is that expected?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* More information on git for Cygwin x86-64
From: Tim O'Callaghan @ 2006-06-01 23:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
After some investigation, it looks like the problem is to do with the
index.lock file. I think it may have something to do with with the
rename function in index.c.
As far as i can tell index.lock should not exist after any git
call. An atexit() call is registered remove it when it is created, so
this should ensure it gets removed. Unfortunately that is not what
happens in this case.
A quick check with an unlink() before the rename in index.c, worked
for the first failure in t0000-basic, but not the next one.
The only relevant reference I could find in the list archives is:
http://www.gelato.unsw.edu.au/archives/git/0510/10188.html
The attached patch has two fixes. The first is a check to see if
cygwin is installed, and if so, to ensure that the script uses cygwin
Unix style find, rather than the win2k find.
The second adds a test_warning_ function to the test library. Not sure
how useful th may be to everyone else, but it works for me. This
checks to see if the index.lock still exists, and adds a simple
'warning' category to the tests.
Tim.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 2233 bytes --]
diff --git a/t/README b/t/README
index ac5a3ac..d278702 100644
--- a/t/README
+++ b/t/README
@@ -52,7 +52,7 @@ (or -i) command line argument to the tes
--immediate::
This causes the test to immediately exit upon the first
- failed test.
+ failed test or warning.
Naming Tests
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 05f6e79..e24cab0 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -80,6 +80,7 @@ fi
test_failure=0
test_count=0
+warning_count=0
trap 'echo >&5 "FATAL: Unexpected exit with code $?"; exit 1' exit
@@ -101,6 +102,17 @@ test_failure_ () {
test "$immediate" = "" || { trap - exit; exit 1; }
}
+test_warning_ () {
+ if [ -e ".git/index.lock" ]
+ then
+ say "Warn $warning_count: file .git/index.lock exists"
+ warning_count=$(expr "$warning_count" + 1)
+ fi
+ if [ "$immediate" != "" -a $warning_count -gt 0 ]
+ then
+ trap - exit; exit 1;
+ fi
+}
test_debug () {
test "$debug" = "" || eval "$1"
@@ -123,6 +135,7 @@ test_expect_failure () {
else
test_failure_ "$@"
fi
+ test_warning_
}
test_expect_success () {
@@ -136,6 +149,7 @@ test_expect_success () {
else
test_failure_ "$@"
fi
+ test_warning_
}
test_expect_code () {
@@ -149,6 +163,7 @@ test_expect_code () {
else
test_failure_ "$@"
fi
+ test_warning_
}
# Most tests can use the created repository, but some amy need to create more.
@@ -178,13 +193,12 @@ test_done () {
# The Makefile provided will clean this test area so
# we will leave things as they are.
- say "passed all $test_count test(s)"
+ say "passed all $test_count test(s) with $warning_count warning(s)"
exit 0 ;;
*)
- say "failed $test_failure among $test_count test(s)"
+ say "failed $test_failure among $test_count test(s) with $warning_count warning(s)"
exit 1 ;;
-
esac
}
@@ -210,6 +224,13 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
+# make sure the cygwin find is used instead of the win2k find.
+if [ $(uname -o 2>/dev/null || echo not) = "Cygwin" ]
+then
+ alias find="/bin/find"
+fi
+
+
# Test repository
test=trash
rm -fr "$test"
^ permalink raw reply related
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-01 23:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com>
On Thu, 1 Jun 2006, Jon Smirl wrote:
>
> I've been working on importing the Mozilla CVS into git for the last
> few days. I've fixed up parsecvs so that it can parse the entire
> repository without errors. Now I'm running into problems because there
> are over 300 branches.
>
> I just run into a problem with git show-branch. Mozilla CVS has a lot
> more than 29 refs, is this something that can be expanded?
Hmm.. Any reason you care about "show-branch --all" in particular?
The algorithm used for show-branch really doesn't scale well, it needs one
bit per commit per branch, and I didn't realize anybody could ever really
care.
Linus
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-06-02 0:24 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20060601192318.GC3329@kroah.com>
Greg KH <greg@kroah.com> writes:
>>
>> So I just grabbed the gregkh-2.6 set of patches and with an unmodified
>> git-mailinfo I only have problems with the following patches:
>> gregkh/gkh-version.patch
>> gregkh/sysfs-test.patch
>> gregkh/gregkh-usb-minors.patch
>> gregkh/gregkh-debugfs_example.patch
>> gregkh/gpl_future-test.patch
>> usb/usb-gotemp.patch
>>
>> None of which actually have from headers.
>
> Oops, sorry for the delay. I've now fixed up these patches (the ones in
> the gregkh/ directory are not ever going to be sent upstream, that's
> why they were missing headers, same for the gotemp driver.)
No problem. I'm mostly on vacation at the moment.
Things like usb/usb-gotemp.path have been sucked into the -mm
tree. So sometimes these things after being published do wind up down stream...
Eric
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 0:55 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149204044.27695.38.camel@neko.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
With the attached patch you can parse the entire Mozilla tree. The
tree has over 100,000 files in it and about 300 branches.
I ran this overnight and it failed with out of memory on a 1GB machine
with 1GB swap. If failed in the branch processing, the parse phase
succeeded.
How much memory does something like this need?
If you want to quickly check out the branch processing problems use
rsync to pull down just a copy of repository files.
I am getting 1000s of warnings like these and I haven't figured out why yet.
Warning: ../mozilla/mozilla/build/mac/build_scripts/Attic/MozillaCheckoutList.txt,v:
unnamed branch from master
Warning: ../mozilla/mozilla/build/unix/run-mozilla.sh,v: unnamed
branch from master
Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master of 99855
Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master
Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master99855
Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master
Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.cp,v:
unnamed branch from master
Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.h,v:
unnamed branch from master
Warning: ../mozilla/mozilla/cmd/macfe/central/Attic/msv2dsk.cp,v:
unnamed branch from master
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1618 bytes --]
diff --git a/gram.y b/gram.y
index 502991e..4566628 100644
--- a/gram.y
+++ b/gram.y
@@ -18,6 +18,7 @@
*/
#include "cvs.h"
+#define YYDEBUG 1
void yyerror (char *msg);
@@ -72,6 +73,7 @@ header : HEAD NUMBER SEMI
| symbollist
{ this_file->symbols = $1; }
| LOCKS SEMI lock_type SEMI
+ | LOCKS NAME COLON NUMBER SEMI lock_type SEMI
| COMMENT DATA SEMI
| EXPAND DATA SEMI
;
@@ -91,6 +93,21 @@ symbol : NAME COLON NUMBER
$$->name = $1;
$$->number = $3;
}
+ | NUMBER COLON NUMBER
+ {
+ char buffer[200];
+ int i, j;
+
+ j = 0;
+ for (i = 0; i < $1.c; i++) {
+ if (i != 0)
+ j += sprintf(&buffer[j], ".");
+ j += sprintf(&buffer[j], "%d", $1.n[i]);
+ }
+ $$ = calloc (1, sizeof (cvs_symbol));
+ $$->name = atom(buffer);
+ $$->number = $3;
+ }
;
revisions : revision revisions
{ $1->next = $2; $$ = $1; }
diff --git a/lex.l b/lex.l
index f25b8a5..956eed7 100644
--- a/lex.l
+++ b/lex.l
@@ -52,7 +52,7 @@ #define YY_INPUT(buf,result,max_size) {
BEGIN(INITIAL);
return TEXT_DATA;
}
-<CONTENT>[-a-zA-Z_0-9+][-a-zA-Z_0-9+/]* {
+<CONTENT>[-a-zA-Z_+][-a-zA-Z_0-9+/.%]* {
yylval.s = atom (yytext);
return NAME;
}
diff --git a/parsecvs.c b/parsecvs.c
index df083c6..e9b8056 100644
--- a/parsecvs.c
+++ b/parsecvs.c
@@ -27,7 +27,9 @@ #endif
cvs_file *this_file;
-rev_execution_mode rev_mode = ExecuteGit;
+//rev_execution_mode rev_mode = ExecuteGit;
+//rev_execution_mode rev_mode = ExecuteGraph;
+rev_execution_mode rev_mode = ExecuteSplits;
int elide = 0;
int difffiles = 1;
^ permalink raw reply related
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 0:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606011643290.5498@g5.osdl.org>
On 6/1/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 1 Jun 2006, Jon Smirl wrote:
> >
> > I've been working on importing the Mozilla CVS into git for the last
> > few days. I've fixed up parsecvs so that it can parse the entire
> > repository without errors. Now I'm running into problems because there
> > are over 300 branches.
> >
> > I just run into a problem with git show-branch. Mozilla CVS has a lot
> > more than 29 refs, is this something that can be expanded?
>
> Hmm.. Any reason you care about "show-branch --all" in particular?
>
> The algorithm used for show-branch really doesn't scale well, it needs one
> bit per commit per branch, and I didn't realize anybody could ever really
> care.
I was trying to use it to figure out what was wrong with the branch
processing in parsecvs. It doesn't have to be fixed. show-branch --all
fails with same 29 tag limit.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-02 1:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606011759t7c828a50gc4a6b45d92d2b344@mail.gmail.com>
On Thu, 1 Jun 2006, Jon Smirl wrote:
>
> I was trying to use it to figure out what was wrong with the branch
> processing in parsecvs. It doesn't have to be fixed. show-branch --all
> fails with same 29 tag limit.
You're much better off using "gitk --all" if you want to see the result,
the "show-branch" this is really broken. It is using the old algorithm
that we used to use for "git-rev-tree", and got rid of about a year ago
there in favour of git-rev-list ;)
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-02 2:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]
On Thu, 2006-06-01 at 20:55 -0400, Jon Smirl wrote:
> With the attached patch you can parse the entire Mozilla tree. The
> tree has over 100,000 files in it and about 300 branches.
that's good news.
> I ran this overnight and it failed with out of memory on a 1GB machine
> with 1GB swap. If failed in the branch processing, the parse phase
> succeeded.
yeah, parsecvs has some internal storage inefficiencies which need to be
addressed. In particular, every commit has a pointer to the related
revision of every file in the commit. Much like git used to store every
filename in the commit object and was changed to share common directory
contents, parsecvs should be fixed to do the same.
> How much memory does something like this need?
It's basically 4 * nrev * nfile bytes on a 32-bit machine, multiply by 2
for a 64-bit machine.
> If you want to quickly check out the branch processing problems use
> rsync to pull down just a copy of repository files.
>
> I am getting 1000s of warnings like these and I haven't figured out why yet.
>
> Warning: ../mozilla/mozilla/build/mac/build_scripts/Attic/MozillaCheckoutList.txt,v:
> unnamed branch from master
> Warning: ../mozilla/mozilla/build/unix/run-mozilla.sh,v: unnamed
> branch from master
> Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master of 99855
> Warning: ../mozilla/mozilla/Makefile.in,v: unnamed branch from master
> Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master99855
> Warning: ../mozilla/mozilla/allmakefiles.sh,v: unnamed branch from master
> Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.cp,v:
> unnamed branch from master
> Warning: ../mozilla/mozilla/cmd/macfe/MailNews/AddressBook/Attic/UAddressBookUtilities.h,v:
> unnamed branch from master
> Warning: ../mozilla/mozilla/cmd/macfe/central/Attic/msv2dsk.cp,v:
> unnamed branch from master
yeah, these happen when vendor branches go awry. I'll pull the
repository and take a look. X.org had similar 'issues' as the current
CVS repo was built by merging mesa, XFree86 and X.org together in a
rather haphazard fashion.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Shawn Pearce @ 2006-06-02 2:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> - reflog from Shawn. Do people find this useful? I've enabled
> reflog on "next" branch in my development repository to see
> how useful it would be for myself a few days ago, and also in
> a linux-2.6 repository I use for testing (I do not hack on
> kernel myself).
I find it useful to track what I've sent to you just in case I
screw up some ref somewhere. I like knowing that if I perform a
bad update-ref call (which I'm prone to do sometimes) that I can
recover quickly as the log exists.
Not having that prior ref value was about the only area of `possible
data loss' that I've every really noticed with GIT. Well, that and
only having one repository holding all of your important files and
you rm -rf the dang directory by accident one day... but that's
just foolishness on the user's part. :-)
> - using ~/.gitrc to give a fall-back default when
> $GIT_DIR/config does not have values.
>
> - command aliases and possibly default arguments via the
> configuration file.
I'm certainly interested in these two - and I don't think I'm alone
when I say that. :-)
--
Shawn.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 2:36 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149214075.5521.31.camel@neko.keithp.com>
On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> yeah, these happen when vendor branches go awry. I'll pull the
> repository and take a look. X.org had similar 'issues' as the current
> CVS repo was built by merging mesa, XFree86 and X.org together in a
> rather haphazard fashion.
Let me know what you find. Converting this without rewriting parsecvs
looks to be beyond the capacity of my home machine. I'm sure you have
access to giant machines at Intel.
Did I see that you can use CVS client tools to manipulate a git
repository? Mozilla has a lot of users on other OSes besides Linux. It
would be nice to change the core server over to git and leave these
other users running their existing tools.
--
Jon Smirl
jonsmirl@gmail.com
^ 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