* 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
* Re: Importing Mozilla CVS into git
From: Shawn Pearce @ 2006-06-02 2:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606011936i725e8eb2h8c2357f3688da43e@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> 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.
Yes. Look at git-cvsserver (ships standard as part of GIT).
It should also be faster than the original CVS server. :-)
--
Shawn.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-02 3:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606011936i725e8eb2h8c2357f3688da43e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
On Thu, 2006-06-01 at 22:36 -0400, Jon Smirl wrote:
> 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.
It's possible, but I would not encourage people to use this for anything
other than passive monitoring of the code; CVS semantics are really too
weak to express the capabilities of the git repository, so changes made
through CVS will lose information.
Git runs fine on Windows these days; asking people to use reasonable
tools to contribute to the project doesn't seem crazy to me.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 3:47 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149219593.5521.34.camel@neko.keithp.com>
On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> Git runs fine on Windows these days; asking people to use reasonable
> tools to contribute to the project doesn't seem crazy to me.
WIndows, Mac, Solaris and Linux will cover most Firefox developers.
Is git to go on those platforms? Is WIndows native or cygwin?
There are a few more people on weird platforms that will need a solution.
Are perl and shell script still a requirement?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-02 3:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606012047h727a25f1vb367c880f8933c4e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:
> On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> > Git runs fine on Windows these days; asking people to use reasonable
> > tools to contribute to the project doesn't seem crazy to me.
>
> WIndows, Mac, Solaris and Linux will cover most Firefox developers.
> Is git to go on those platforms? Is WIndows native or cygwin?
I think the windows stuff may still be cygwin, but Mac and Solaris work
fine with the git, of course. It's just simple posix code, after all
> There are a few more people on weird platforms that will need a solution.
> Are perl and shell script still a requirement?
Yeah, quite a bit of both of those still. Less over time as people
figure out that C code is generally easier to fix than a nasty
combination of C code, shell scripts and perl line noise.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 4:00 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149220518.5521.43.camel@neko.keithp.com>
On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:
> > On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> > > Git runs fine on Windows these days; asking people to use reasonable
> > > tools to contribute to the project doesn't seem crazy to me.
> >
> > WIndows, Mac, Solaris and Linux will cover most Firefox developers.
> > Is git to go on those platforms? Is WIndows native or cygwin?
>
> I think the windows stuff may still be cygwin, but Mac and Solaris work
> fine with the git, of course. It's just simple posix code, after all
It is going to have to be native Windows to move some of the
developers over. They are true blue MS types that won't touch anything
close to Unix so cygwin is out.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Shawn Pearce @ 2006-06-02 4:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606012100s7ace4721le6fbfbcaadfb6c43@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> >On Thu, 2006-06-01 at 23:47 -0400, Jon Smirl wrote:
> >> On 6/1/06, Keith Packard <keithp@keithp.com> wrote:
> >> > Git runs fine on Windows these days; asking people to use reasonable
> >> > tools to contribute to the project doesn't seem crazy to me.
> >>
> >> WIndows, Mac, Solaris and Linux will cover most Firefox developers.
> >> Is git to go on those platforms? Is WIndows native or cygwin?
> >
> >I think the windows stuff may still be cygwin, but Mac and Solaris work
> >fine with the git, of course. It's just simple posix code, after all
>
> It is going to have to be native Windows to move some of the
> developers over. They are true blue MS types that won't touch anything
> close to Unix so cygwin is out.
Then GIT on Windows might be out.
GIT today requires not only a decent UNIX shell but also, GNU tools,
Perl and Python. Porting to Solaris has recently had some more
effort put into it to remove some of the GNU tool dependencies but
perhaps one of the most important features (git-merge-recursive)
is a Python script.
I'm running GIT at work on a Windows/Cygwin installation which is
really quite bare bones. I think I have about 15 Cygwin packages
installed total and GIT is running fine in that environment.
It can't send patches by email but the corporate firewalls wouldn't
permit that anyway...
Perhaps you can tell the true blue MS types that Cygwin is a native
Windows application. After all it uses the Win32 API. :-)
--
Shawn.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Martin Langhoff @ 2006-06-02 4:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606011521n106f8f24s6c7053ce51e3791e@mail.gmail.com>
Jon,
> 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.
Fetchin it now, I'll definitely have a play. Have you tried with a
recent git-cvsimport? In the last 2 weeks it's seen a lot of
performance & scalability improvements as we were importing the
gentoo-x86 tree.
Grab the latest 'master' branch from Junio and give the import a go.
cheers,
martin
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Martin Langhoff @ 2006-06-02 4:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606012100s7ace4721le6fbfbcaadfb6c43@mail.gmail.com>
On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> It is going to have to be native Windows to move some of the
> developers over. They are true blue MS types that won't touch anything
> close to Unix so cygwin is out.
As others have pointed out, you have git-cvsserver which emulates a
CVS server on top of GIT, so it can be used with (almost any) CVS
client. They will be 2nd class citizens however...
cheers,
martin
^ 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