* 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
* Re: Importing Mozilla CVS into git
From: Pavel Roskin @ 2006-06-02 4:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, Keith Packard, git
In-Reply-To: <20060602041107.GA5429@spearce.org>
On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:
> 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.
The great thing about git is that it's modular. A single utility can be
replaced and retested in the same environment, without having to rewrite
the rest of the scripts. A dedicated programmer with good C and Python
skills could rewrite git-merge-recursive.py in C in 2 days, I believe.
Add a few days of bug fixing, of course.
Dependency on Cygwin, Perl and Python is too much. Windows is becoming
a legacy system in some circles, and it may run on legacy hardware. Yet
it's irreplaceable as a testing platform for many projects.
I really need to rewrite git-clean in C, since it doesn't handle
embedded newlines properly.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Shawn Pearce @ 2006-06-02 4:44 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Jon Smirl, Keith Packard, git
In-Reply-To: <1149223164.2443.33.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:
>
> > 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.
>
> The great thing about git is that it's modular. A single utility can be
> replaced and retested in the same environment, without having to rewrite
> the rest of the scripts. A dedicated programmer with good C and Python
> skills could rewrite git-merge-recursive.py in C in 2 days, I believe.
> Add a few days of bug fixing, of course.
Heh. Funny you should mention that. I was just thinking a few
minutes ago about working on that exact change...
> Dependency on Cygwin, Perl and Python is too much. Windows is becoming
> a legacy system in some circles, and it may run on legacy hardware. Yet
> it's irreplaceable as a testing platform for many projects.
Its already legacy to me. Heck its 2006 and my work desktop still
says something about 2000 when I login. :-)
--
Shawn.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-02 4:44 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Shawn Pearce, Keith Packard, git
In-Reply-To: <1149223164.2443.33.camel@dv>
On 6/2/06, Pavel Roskin <proski@gnu.org> wrote:
> Dependency on Cygwin, Perl and Python is too much. Windows is becoming
> a legacy system in some circles, and it may run on legacy hardware. Yet
> it's irreplaceable as a testing platform for many projects.
80% of Mozilla commiters are running Windows. Some are OS bilingual
but many are not.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: More information on git for Cygwin x86-64
From: Alex Riesen @ 2006-06-02 6:37 UTC (permalink / raw)
To: Tim O'Callaghan, git
In-Reply-To: <20060601234410.GA3408@Zangband>
On 6/2/06, Tim O'Callaghan <timo@dspsrv.com> wrote:
> 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.
Does setting "NO_MMAP = YesPlease" in config.mak helps you?
The problem this option solves has to do with stupid open
file behaviour in windows.
^ permalink raw reply
* Re: HTTP questions
From: Junio C Hamano @ 2006-06-02 6:38 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060601232437.GD12261@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> - "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?
The way I understand http-push works is that it does not use
packed transfer, so I presume even if we give --thin as a hint
it cannot even take advantage of it. Probably we should stop
passing --thin to http transport (git native one uses it as a
cue that it can generate baseless deltas in the resulting pack).
> - when I clone, http-fetch outputs a whole bunch of
> "error: Could not read ..." messages - is that expected?
The clone over http seems to be severely broken in "next" right
now. The one in "master" seems to be OK. bisecting suggests
the breakage is coming from the tree parser rewrite.
bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Junio C Hamano @ 2006-06-02 6:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060602023545.GA5039@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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.
I find it interesting to be able to say:
$ git log next@{yesterday}..next
I often find myself getting curious to see:
$ git reflog next
Wed May 31 14:23:58 2006 -0700
62b693a... Merge branch 'master' into next
Wed May 31 14:26:39 2006 -0700
422dfaf... Merge branch 'lt/tree-2' into next
Wed May 31 15:14:58 2006 -0700
100c25f... Merge branch 'ff/svnimport' into next
Wed May 31 15:23:54 2006 -0700
a25963b... Merge branch 'jc/fmt-patch' into next
...
The latter is probably not so useful in practice -- I suspect
that I would want to see such a list only while I am interested
in how well reflog works.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Junio C Hamano @ 2006-06-02 6:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606011809401.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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 ;)
Are you sure about it? My recollection is it uses the
merge-base logic, naturally enhanced for multiple heads.
And enhancing it to support more than one int wide bitmap should
not be too difficult, although looking at the output would be
very taxing for human eye, so I do not know if it is worth it.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Johannes Schindelin @ 2006-06-02 7:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Pavel Roskin, Jon Smirl, Keith Packard, git
In-Reply-To: <20060602044404.GB5429@spearce.org>
Hi,
On Fri, 2 Jun 2006, Shawn Pearce wrote:
> Pavel Roskin <proski@gnu.org> wrote:
> > On Fri, 2006-06-02 at 00:11 -0400, Shawn Pearce wrote:
> >
> > > 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.
> >
> > The great thing about git is that it's modular. A single utility can be
> > replaced and retested in the same environment, without having to rewrite
> > the rest of the scripts. A dedicated programmer with good C and Python
> > skills could rewrite git-merge-recursive.py in C in 2 days, I believe.
> > Add a few days of bug fixing, of course.
>
> Heh. Funny you should mention that. I was just thinking a few
> minutes ago about working on that exact change...
I thought about this a couple of weeks ago. I recalled to have read
something about the principle: if there is more than one merge-base
candidate, it starts by merging the merge-base candidates until there is
only one 'virtual' merge-base candidate.
However, looking at the code I fainted. Sure, a lot should be way easier
in C, because the functions are already there, _but_ it seemed too much
work for one afternoon nevertheless (and I did not have more time to
spare).
Ciao,
Dscho
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Jakub Narebski @ 2006-06-02 8:16 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP02F2FF1D978A880AFDDA1DAE900@CEZ.ICE>
Sean wrote:
> 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 ?
>
> Not sure if it needs to be in the FAQ at this point, but i guess it couldn't
> hurt either.
Added. See: http://git.or.cz/gitwiki/GitFaq#reset-hard-leaving-files
Feel free to add examples, correct information, rework it etc.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Martin Waitz @ 2006-06-02 9:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606010918060.5498@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
hoi :)
On Thu, Jun 01, 2006 at 09:21:38AM -0700, Linus Torvalds wrote:
> Those files were _never_ tracked.
You are right, I used the wrong demonstration to show my problem.
I had one problem like this in the linux-kernel and tried to
reproduce them in the git repository but did it wrong...
GIT reset seems to have a problem when a file is tracked and ignored
at the same time.
This fails:
diff --git a/t/t7101-reset.sh b/t/t7101-reset.sh
index a919140..865e0f6 100755
--- a/t/t7101-reset.sh
+++ b/t/t7101-reset.sh
@@ -21,10 +21,12 @@ test_expect_success \
cp ../../COPYING path1/COPYING &&
cp ../../COPYING COPYING &&
cp ../../COPYING path0/COPYING-TOO &&
+ echo COPYING > .gitignore &&
git-add path1/path2/COPYING &&
git-add path1/COPYING &&
git-add COPYING &&
git-add path0/COPYING-TOO &&
+ git-add .gitignore &&
git-commit -m change -a'
test_expect_success \
This hit me as the Linux kernel .gitignore includes ".*" which matches
all the .gitignore files and so they are not removed when you go
back to 2.6.13. But with the new git checks regarding files in
the working dir, git then refuses to pull in newer Linux versions
because it would overwrite ".gitignore".
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: git reset --hard not removing some files
From: Sean @ 2006-06-02 10:08 UTC (permalink / raw)
To: Martin Waitz; +Cc: torvalds, git
In-Reply-To: <20060602093736.GL14325@admingilde.org>
On Fri, 2 Jun 2006 11:37:36 +0200
Martin Waitz <tali@admingilde.org> wrote:
Hi Martin,
> GIT reset seems to have a problem when a file is tracked and ignored
> at the same time.
I tried to reproduce this problem, but couldn't.
> This fails:
>
> diff --git a/t/t7101-reset.sh b/t/t7101-reset.sh
> index a919140..865e0f6 100755
> --- a/t/t7101-reset.sh
> +++ b/t/t7101-reset.sh
> @@ -21,10 +21,12 @@ test_expect_success \
> cp ../../COPYING path1/COPYING &&
> cp ../../COPYING COPYING &&
> cp ../../COPYING path0/COPYING-TOO &&
> + echo COPYING > .gitignore &&
> git-add path1/path2/COPYING &&
> git-add path1/COPYING &&
> git-add COPYING &&
> git-add path0/COPYING-TOO &&
> + git-add .gitignore &&
> git-commit -m change -a'
>
> test_expect_success \
This fails because git-add refuses to mark an ignored file as tracked.
So in your altered test above the COPYING file is never tracked.
git-reset then does the proper thing and refuses to remove it. So it's
still not demonstrating the case you mention below.
> This hit me as the Linux kernel .gitignore includes ".*" which matches
> all the .gitignore files and so they are not removed when you go
> back to 2.6.13. But with the new git checks regarding files in
> the working dir, git then refuses to pull in newer Linux versions
> because it would overwrite ".gitignore".
Strange.. this little test shows that tracked files that are ignored
do get removed when resetting --hard...
$ mkdir tryit ; cd tryit
$ git init-db
defaulting to local storage area
$ touch one ; git add one
$ git commit -a -m"Initial"
Committing initial tree 5fcffbd6e4c5c5b8d81f5e9314b20e338e3ffff5
$ touch .gitignore
$ git add .gitignore
$ git commit -a -m"now we have gitignore"
$ echo '.*' >> .gitignore
$ git commit -a -m'now git ignores all .* files'
$ ls -l .gitignore
-rw-r--r-- 1 sean sean 3 Jun 2 06:01 .gitignore
$ git reset --hard master~2
$ ls -l .gitignore
ls: .gitignore: No such file or directory
Sean
^ permalink raw reply
* Re: [PATCH] A Perforce importer for git.
From: Alex Riesen @ 2006-06-02 13:09 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP117796558F3B42B2C18DBCAE980@CEZ.ICE>
On 5/25/06, Sean <seanlkml@sympatico.ca> wrote:
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> ---
> Documentation/git-p4import.txt | 165 ++++++++++++++++++
> git-p4import.py | 357 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 522 insertions(+), 0 deletions(-)
BTW, can I suggest to import the _currently_ synced state?
The reason is that because of the way how Perforce is done
its working directories (views, aka clients) are often a
horrible mix of occasionally synced files to some random
versions. No one actually uses "p4 sync" for whole project here
where I work, because it is absolutely useless at this level
(updated files have abolutely no relevance at head revision,
which is what you get by syncing without strictly specifying
a revision). So a working state is stitched together from
a lot of "mappings": perforce path to local path -> revision.
That state can be actually worked on (up until you have
to commit something, that is not possible except on head).
That is why I actually can't sync before importing, but have
to use the method Junio described for CVS:
p4 sync files...#revisions
git add new-files...
git commit -a
(simplified. There are problems with case-sensitivity and that
stupid read-only attribute perfoce uses as sync marker).
^ permalink raw reply
* [PATCH] format-patch: resurrect extra headers from config
From: Johannes Schindelin @ 2006-06-02 13:21 UTC (permalink / raw)
To: git, junkio
Once again, if you have
[format]
headers = "Origamization: EvilEmpire\n"
format-patch will add these headers just after the "Subject:" line.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-log.c | 20 ++++++++++++++++++++
log-tree.c | 8 +++++---
revision.h | 1 +
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index ac4822d..6612f4c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -85,6 +85,23 @@ static int istitlechar(char c)
(c >= '0' && c <= '9') || c == '.' || c == '_';
}
+static char *extra_headers = NULL;
+static int extra_headers_size = 0;
+
+static int git_format_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "format.headers")) {
+ int len = strlen(value);
+ extra_headers_size += len + 1;
+ extra_headers = realloc(extra_headers, extra_headers_size);
+ extra_headers[extra_headers_size - len - 1] = 0;
+ strcat(extra_headers, value);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+
static FILE *realstdout = NULL;
static char *output_directory = NULL;
@@ -162,6 +179,9 @@ int cmd_format_patch(int argc, const cha
rev.ignore_merges = 1;
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
+ git_config(git_format_config);
+ rev.extra_headers = extra_headers;
+
/*
* Parse the arguments before setup_revisions(), or something
* like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
diff --git a/log-tree.c b/log-tree.c
index e86e16b..ebb49f2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -51,7 +51,7 @@ void show_log(struct rev_info *opt, stru
int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
const char *extra;
int len;
- char *subject = NULL, *after_subject = NULL;
+ const char *subject = NULL, *extra_headers = opt->extra_headers;
opt->loginfo = NULL;
if (!opt->verbose_header) {
@@ -100,6 +100,7 @@ void show_log(struct rev_info *opt, stru
static char subject_buffer[1024];
static char buffer[1024];
snprintf(subject_buffer, sizeof(subject_buffer) - 1,
+ "%s"
"MIME-Version: 1.0\n"
"Content-Type: multipart/mixed;\n"
" boundary=\"%s%s\"\n"
@@ -110,9 +111,10 @@ void show_log(struct rev_info *opt, stru
"Content-Type: text/plain; "
"charset=UTF-8; format=fixed\n"
"Content-Transfer-Encoding: 8bit\n\n",
+ extra_headers ? extra_headers : "",
mime_boundary_leader, opt->mime_boundary,
mime_boundary_leader, opt->mime_boundary);
- after_subject = subject_buffer;
+ extra_headers = subject_buffer;
snprintf(buffer, sizeof(buffer) - 1,
"--%s%s\n"
@@ -141,7 +143,7 @@ void show_log(struct rev_info *opt, stru
/*
* And then the pretty-printed message itself
*/
- len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject, after_subject);
+ len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject, extra_headers);
if (opt->add_signoff)
len = append_signoff(this_header, sizeof(this_header), len,
diff --git a/revision.h b/revision.h
index 75796bc..7d85b0f 100644
--- a/revision.h
+++ b/revision.h
@@ -61,6 +61,7 @@ struct rev_info {
int nr, total;
const char *mime_boundary;
const char *add_signoff;
+ const char *extra_headers;
/* special limits */
int max_count;
--
1.3.3.g83f2b-dirty
^ permalink raw reply related
* Re: [PATCH] A Perforce importer for git.
From: Sean @ 2006-06-02 13:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0606020609o24ee34b4p7b1bcd013136d49a@mail.gmail.com>
On Fri, 2 Jun 2006 15:09:45 +0200
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> BTW, can I suggest to import the _currently_ synced state?
>
> The reason is that because of the way how Perforce is done
> its working directories (views, aka clients) are often a
> horrible mix of occasionally synced files to some random
> versions. No one actually uses "p4 sync" for whole project here
> where I work, because it is absolutely useless at this level
> (updated files have abolutely no relevance at head revision,
> which is what you get by syncing without strictly specifying
> a revision). So a working state is stitched together from
> a lot of "mappings": perforce path to local path -> revision.
> That state can be actually worked on (up until you have
> to commit something, that is not possible except on head).
Hey Alex,
I'd happily change the script to accommodate your needs if it's at all
reasonable. As you've no doubt gathered, the script is currently very
branch centric. It needs a mapping view from each p4 branch into the
local git directory. Then it does a sync //p4/mapping@{revision} for
each revision along each mapped branch and commits it into git.
Note that it never syncs specifically to head, it explicitly asks for
each revision along the branch and tt doesn't know anything about your
working state, it can only import commits.
Are you looking for the ability to create a single git branch which has
the history of the combined view of your stitched together client mappings
rather than the independent branches held by the server?
Sean
^ 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