* Re: [PATCH 1/2]: amendment
From: Johannes Schindelin @ 2006-06-08 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j3r8uab.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 8 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I completely forgot that with a global config, it makes sense to have
> > aliases even if we are not in a git repository.
> >
> > So, in git.c, handle_alias() the "if (nongit)" makes no sense any longer.
> > If I have to revise the patch anyway, I will include the change, but if
> > you decide to take it, please change that.
> >
> > Ciao,
> > Dscho
> >
> > P.S.: There might be other users (such as git-peek-remote) who want that
> > change, too.
>
> Well, this is pretty late in the 1.4.0 game and honestly I am
> pretty reluctant to merge this in, push 1.4.0 out in 48 hours
> and leave for nearly a week.
Sorry, I timed that rather badly.
> My preference is to cook this in "next" for a while and merge it
> post 1.4.0.
Judging from the flurry of creative flag naming wishes, I think that will
do just fine.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 20:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e69qev$nnl$1@sea.gmane.org>
Hi,
On Thu, 8 Jun 2006, Jakub Narebski wrote:
> Jon Loeliger wrote:
>
> > On Thu, 2006-06-08 at 06:30, Johannes Schindelin wrote:
>
> >> - The --no-local flag [...]
> >
> > Could we have multiple levels, and have names that call out
> > where it applies? Perhaps something like:
> >
> > --repo into $GIT_DIR/.gitconfig <- current default, right?
> > --home into ~/.gitconfig
> > --site into /etc/gitconfig
> > --share into /usr/share/git/config
>
> I like that too, wlthough --home might be named --user, and --share be
> named --predefined or --library.
I am rather disinclined for the --share or --predefined flags, as these
would only make sense for the administrator. And since this code was
partly written by me, it eats small children.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 20:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e69qne$nnl$2@sea.gmane.org>
Hi,
On Thu, 8 Jun 2006, Jakub Narebski wrote:
> And legacy "git repo-config" as equivalent of "git config --repo", perhaps
> implemented via alias mechanism (if there woul be system-wide coniguration
> file, otherwise in skeleton/template).
Why use the alias mechanism? I, for one, never install git. So, this
solution is rather fragile. But there are better ways: the builtin
mechanism for one.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 20:18 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: junkio, git
In-Reply-To: <20060608153236.GA8047@satan.machinehead.org>
Hi,
On Thu, 8 Jun 2006, Aneesh Kumar K.V wrote:
> On Thu, Jun 08, 2006 at 01:31:46PM +0200, Johannes Schindelin wrote:
> >
> > Since there is a global config now, we need a way to access it
> > conveniently. Now you can say
> >
> > git repo-config --no-local alias.l "log --stat -M ORIG_HEAD.."
> >
> > to set the alias globally (it will be stored in ~/.gitconfig).
> >
>
> how about making the above
>
> git config --repo alias.l "log --stat -M ORIG_HEAD.."
IMHO it would be a sane thing to make this default. Most config variables
are repository dependent.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 20:24 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, lukass, git
In-Reply-To: <BAYC1-PASMTP04DDBAA584B31A4B0F31DCAE8B0@CEZ.ICE>
Hi,
On Thu, 8 Jun 2006, Sean wrote:
> On Thu, 08 Jun 2006 09:25:53 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>
> > The wording "--no-local" means you are looking at things
> > relative to a particular repository. I.e. some configuration
> > variables come from repository-local file, and others from
> > somewhere else. But I do not think that somewhere else is
> > "global". We are reading from $HOME, which is different
> > depending on who is interacting with that same repository. So I
> > would probably call the other one "--user" or something if I
> > were force to pick name.
>
> --user or --home makes a lot of sense. Alternatively you could
> just be explicit: --config=~ or --config=/etc/gitconfig where
> /.gitconfig is automatically appended to the path if it ends in
> a directory name.
I think --user makes more sense than --home, since it does not matter
_where_ it is stored, but _when_ it is retreived.
In the same vein, I do not think it is user friendly to expect the user to
remember if it was .gitconfig, .git or .gitrc.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Sean @ 2006-06-08 20:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, lukass, git
In-Reply-To: <Pine.LNX.4.63.0606082222470.28323@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 8 Jun 2006 22:24:31 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I think --user makes more sense than --home, since it does not matter
> _where_ it is stored, but _when_ it is retreived.
--home seems more natural to me for some reason but I don't feel strongly
about it.
> In the same vein, I do not think it is user friendly to expect the user to
> remember if it was .gitconfig, .git or .gitrc.
Sure, was just thinking that this could be used by an administrator to
modify _other_ users' configs.. but probably not worth it.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 20:42 UTC (permalink / raw)
To: Sean; +Cc: junkio, lukass, git
In-Reply-To: <BAYC1-PASMTP102B1021B943F57F9FB1EEAE8B0@CEZ.ICE>
Hi,
On Thu, 8 Jun 2006, Sean wrote:
> On Thu, 8 Jun 2006 22:24:31 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I think --user makes more sense than --home, since it does not matter
> > _where_ it is stored, but _when_ it is retreived.
>
> --home seems more natural to me for some reason but I don't feel strongly
> about it.
I'd like to know how --home tells you when this key is retreived.
> > In the same vein, I do not think it is user friendly to expect the user to
> > remember if it was .gitconfig, .git or .gitrc.
>
> Sure, was just thinking that this could be used by an administrator to
> modify _other_ users' configs.. but probably not worth it.
The admin has no business messing around with the users' configuration.
And if she absolutely wants to be a BOFH, she can fire up any editor, or
copy .gitconfig to /root/.gitconfig, use git-config, and copy it back, or
do what she does all the time: "su <user>". But frankly, we should not
support a bad work flow.
BTW it is the same reason I would rather not see /etc/gitconfig: it
meddles with an existing configuration. If you want to give defaults, you
can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
would be very surprised if the behaviour of git changed from one day to
the other without my changing anything.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Jakub Narebski @ 2006-06-08 20:55 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0606082235020.28405@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> BTW it is the same reason I would rather not see /etc/gitconfig: it
> meddles with an existing configuration. If you want to give defaults, you
> can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
> would be very surprised if the behaviour of git changed from one day to
> the other without my changing anything.
I agree wholeheartily. I guess that the 'skeleton' part has yet to be
written...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Sean @ 2006-06-08 20:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, lukass, git
In-Reply-To: <Pine.LNX.4.63.0606082235020.28405@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 8 Jun 2006 22:42:17 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I'd like to know how --home tells you when this key is retreived.
I honestly don't know. How does --user tell you when this key is retrieved?
> The admin has no business messing around with the users' configuration.
> And if she absolutely wants to be a BOFH, she can fire up any editor, or
> copy .gitconfig to /root/.gitconfig, use git-config, and copy it back, or
> do what she does all the time: "su <user>". But frankly, we should not
> support a bad work flow.
>
> BTW it is the same reason I would rather not see /etc/gitconfig: it
> meddles with an existing configuration. If you want to give defaults, you
> can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
> would be very surprised if the behaviour of git changed from one day to
> the other without my changing anything.
This seems like a rather heavy handed policy for an application to enforce.
To my mind, these types of decisions are best left up to administrators;
obviously we can't guess all the creative ways git will be used beforehand.
Sean
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 21:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6a2rt$n6p$1@sea.gmane.org>
Hi,
On Thu, 8 Jun 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > BTW it is the same reason I would rather not see /etc/gitconfig: it
> > meddles with an existing configuration. If you want to give defaults, you
> > can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
> > would be very surprised if the behaviour of git changed from one day to
> > the other without my changing anything.
>
> I agree wholeheartily. I guess that the 'skeleton' part has yet to be
> written...
I don't know what exactly you mean: the skeleton copying part, or the
default .gitconfig?
As for the skeleton copying part, on the machine I am writing this on,
there is a /etc/skel/ directory, which is automatically copied to the
$HOME of every newly created user.
As for the default .gitconfig (which you could put into /etc/skel/): if
the default behaviour of git is not to your liking, just make a
$HOME/.gitconfig, and once you are satisfied with it, stick a copy into
/etc/skel!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 21:10 UTC (permalink / raw)
To: Sean; +Cc: junkio, lukass, git
In-Reply-To: <BAYC1-PASMTP040660E676E00AD1631524AE8B0@CEZ.ICE>
Hi,
On Thu, 8 Jun 2006, Sean wrote:
> On Thu, 8 Jun 2006 22:42:17 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I'd like to know how --home tells you when this key is retreived.
>
> I honestly don't know. How does --user tell you when this key is
> retrieved?
If I have --user vs. --repo, then I expect the setting to be active for
the user vs. the repository, respectively.
> > The admin has no business messing around with the users' configuration.
> > And if she absolutely wants to be a BOFH, she can fire up any editor, or
> > copy .gitconfig to /root/.gitconfig, use git-config, and copy it back, or
> > do what she does all the time: "su <user>". But frankly, we should not
> > support a bad work flow.
> >
> > BTW it is the same reason I would rather not see /etc/gitconfig: it
> > meddles with an existing configuration. If you want to give defaults, you
> > can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
> > would be very surprised if the behaviour of git changed from one day to
> > the other without my changing anything.
>
> This seems like a rather heavy handed policy for an application to enforce.
> To my mind, these types of decisions are best left up to administrators;
Clearly, you have not met the same administrators as I did.
> obviously we can't guess all the creative ways git will be used beforehand.
That is right, but is it for somebody else to decide the creative way, or
for you?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Jakub Narebski @ 2006-06-08 21:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0606082300390.28654@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 8 Jun 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>> > BTW it is the same reason I would rather not see /etc/gitconfig: it
>> > meddles with an existing configuration. If you want to give defaults,
you
>> > can use a skeleton for $HOME, and templates for $GIT_DIR. As a user, I
>> > would be very surprised if the behaviour of git changed from one day to
>> > the other without my changing anything.
>>
>> I agree wholeheartily. I guess that the 'skeleton' part has yet to be
>> written...
>
> I don't know what exactly you mean: the skeleton copying part, or the
> default .gitconfig?
No, I mean the default skeleton for .gitconfig/.gitrc in git distribution or
git deb/rpm, and install copying it to appropriate drectory (/etc/skel/ if
installed as root, or $HOME if installed as an ordinary user).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Sean @ 2006-06-08 21:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, lukass, git
In-Reply-To: <Pine.LNX.4.63.0606082308010.28722@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 8 Jun 2006 23:10:15 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> If I have --user vs. --repo, then I expect the setting to be active for
> the user vs. the repository, respectively.
*shrug* This seems exactly the same for --home; like I said I don't
care enough to argue about it though.
> Clearly, you have not met the same administrators as I did.
Maybe not.
> > obviously we can't guess all the creative ways git will be used beforehand.
>
> That is right, but is it for somebody else to decide the creative way, or
> for you?
My argument was that we should not build in policies that assume administrators
are incompetent. That we should put the tools in their hands and not restrict
them. That lets them be as creative as they want and not constrained because
we have a preexisting opinion about their abilities or an opinion about the
policies they should follow with regard to their users files etc.
Anyway, i'm bowing out of this discussion because i'm sure you'll decide
a reasonable course of action.
Cheers,
Sean
^ permalink raw reply
* [PATCH] git-rm: fix possible segfault
From: SungHyun Nam @ 2006-06-09 2:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: SungHyun Nam <goweol@gmail.com>
---
builtin-rm.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index ef2f8b5..aeda415 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -83,6 +83,9 @@ int cmd_rm(int argc, const char **argv,
}
die(builtin_rm_usage);
}
+ if (i >= argc)
+ usage(builtin_rm_usage);
+
pathspec = get_pathspec(prefix, argv + i);
seen = NULL;
--
1.4.0.rc1.gfd7e
^ permalink raw reply related
* Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 2:17 UTC (permalink / raw)
To: git
I was able to import Mozilla into SVN without problem, it just occured
to me to then import the SVN repository in git. The import has been
running a few hours now and it is up to the year 2000 (starts in
1998). Since I haven't hit any errors yet it will probably finish ok.
I should have the results in the morning. I wonder how long it will
take to start gitk on a 10GB repository.
Once I get this monster into git, are there tools that will let me
keep it in sync with Mozilla CVS?
SVN renamed numeric branches to this form, unlabeled-3.7.24, so that
may be a problem.
Any advice on how to pack this to make it run faster?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Nicolas Pitre @ 2006-06-09 2:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606081917l11354e49q25f0c4aea40618ea@mail.gmail.com>
On Thu, 8 Jun 2006, Jon Smirl wrote:
> I was able to import Mozilla into SVN without problem, it just occured
> to me to then import the SVN repository in git. The import has been
> running a few hours now and it is up to the year 2000 (starts in
> 1998). Since I haven't hit any errors yet it will probably finish ok.
> I should have the results in the morning. I wonder how long it will
> take to start gitk on a 10GB repository.
Before you do so consider repacking the repository with
git-repack -a -f -d && git-prune-packed
Nicolas
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-09 3:06 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606081917l11354e49q25f0c4aea40618ea@mail.gmail.com>
Jon,
oh, I went back to a cvsimport that I started a couple days ago.
Completed with no problems...
Last commit:
commit 5ecb56b9c4566618fad602a8da656477e4c6447a
Author: wtchang%redhat.com <wtchang%redhat.com>
Date: Fri Jun 2 17:20:37 2006 +0000
Import NSPR 4.6.2 and NSS 3.11.1
mozilla.git$ du -sh .git/
2.0G .git/
It took
43492.19user 53504.77system 40:23:49elapsed 66%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (77334major+3122469478minor)pagefaults 0swaps
> I should have the results in the morning. I wonder how long it will
> take to start gitk on a 10GB repository.
Hopefully not that big :) -- anyway, just do gitk --max-count=1000
> Once I get this monster into git, are there tools that will let me
> keep it in sync with Mozilla CVS?
If you use git-cvsimport, you can safely re-run it on a cronjob to
keep it in sync. Not too sure about the cvs2svn => git-svnimport,
though git-svnimport does support incremental imports.
> SVN renamed numeric branches to this form, unlabeled-3.7.24, so that
> may be a problem.
Ouch,
> Any advice on how to pack this to make it run faster?
git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
martin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Pavel Roskin @ 2006-06-09 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606081917l11354e49q25f0c4aea40618ea@mail.gmail.com>
Hi Jon,
Quoting Jon Smirl <jonsmirl@gmail.com>:
> I was able to import Mozilla into SVN without problem, it just occured
> to me to then import the SVN repository in git.
I feel bad that I didn't suggest it before. That's quite expected. Subversion
was created by CVS developers with the intention of replacing CVS. cvs2svn
was written by the same CVS developers, who paid attention to all CVS quirks.
cvs2svn is quite mature and it has a testsuite, if I remember correctly.
My concern is how well a Subversion repository can be mapped to git considering
that Subversion is branch agnostic. But if it works for Mozilla, this approach
could be recommended for anything big and serious.
> The import has been
> running a few hours now and it is up to the year 2000 (starts in
> 1998). Since I haven't hit any errors yet it will probably finish ok.
> I should have the results in the morning. I wonder how long it will
> take to start gitk on a 10GB repository.
That's the "raison d'etre" of qgit. I don't know if gitk has anything that qgit
doesn't, except bisecting.
> Once I get this monster into git, are there tools that will let me
> keep it in sync with Mozilla CVS?
Ideally, make Mozilla developers use git :-)
> SVN renamed numeric branches to this form, unlabeled-3.7.24, so that
> may be a problem.
I think git-svn is supposed to do the svn->git part, but I'm afraid it will need
some work to do it effectively. Google search for "cvs2svn incremental" brings
some patches. cvsup can be used to synchronize the CVS repository.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 3:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606082006t5c6a5623q4b9cf7b036dad1e5@mail.gmail.com>
On 6/8/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Jon,
>
> oh, I went back to a cvsimport that I started a couple days ago.
> Completed with no problems...
I am using cvsps-2.1-3.fc5, the last time I tried it died in the
middle of the import. I don't remember why it died. Which cvsps are
you using? You're saying that it can handle the whole Mozilla CVS now,
right? I will build a new cvsps from CVS and start it running tonight.
> If you use git-cvsimport, you can safely re-run it on a cronjob to
> keep it in sync. Not too sure about the cvs2svn => git-svnimport,
> though git-svnimport does support incremental imports.
I would much rather get a direct CVS import working so that I can do
incremental updates. I went the SVN route because it was the only
thing I could get working.
> > Any advice on how to pack this to make it run faster?
>
> git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
We are all having problems getting this to run on 32 bit machines with
the 3-4GB process size limitations.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] git-rm: fix possible segfault
From: Junio C Hamano @ 2006-06-09 4:15 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <20060609111044.451c94b1@namsh.wimo.co.kr>
SungHyun Nam <goweol@gmail.com> writes:
> Signed-off-by: SungHyun Nam <goweol@gmail.com>
>
> ---
> builtin-rm.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-rm.c b/builtin-rm.c
> index ef2f8b5..aeda415 100644
> --- a/builtin-rm.c
> +++ b/builtin-rm.c
> @@ -83,6 +83,9 @@ int cmd_rm(int argc, const char **argv,
> }
> die(builtin_rm_usage);
> }
> + if (i >= argc)
> + usage(builtin_rm_usage);
> +
> pathspec = get_pathspec(prefix, argv + i);
>
> seen = NULL;
Thanks. The real problem is it uses pathspec even when no paths
is specified, but "git rm" without any arguments would remove
everything under the sun with the normal pathspec semantics, so
refusing to run when no paths are specified like you did makes
sense.
There is a more grave bug in git-rm (I do not use this command
myself at all, so I did not spot it earlier). I'll push out a
fix soonish.
^ permalink raw reply
* [PATCH] list_untracked_files: remove empty squashed directories
From: Jeff King @ 2006-06-09 5:41 UTC (permalink / raw)
To: Petr Baudis, git
Signed-off-by: Jeff King <peff@peff.net>
---
This patch is for cogito.
Ordinarily, I would say if you have empty directories, you should remove
them. However, if you have a directory in which all files are excluded,
it will still appear in cg-status -w (even though cg-status -S is
empty!).
This, of course, means that actual empty directories will also be
ignored; there's no way around it without putting logic into
git-ls-files to distinguish between the two.
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 839e9f8..3ec32b7 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -443,7 +443,7 @@ list_untracked_files()
fi
fi
local listdirs=
- [ "$squashflag" != "squashdirs" ] || listdirs=--directory
+ [ "$squashflag" != "squashdirs" ] || listdirs="--directory --no-empty-directory"
git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
}
--
1.4.0.rc2
^ permalink raw reply related
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-09 7:17 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606082028k37f6d915m26009e0d5011808b@mail.gmail.com>
Jon Smirl wrote:
>> git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
>
> We are all having problems getting this to run on 32 bit machines with
> the 3-4GB process size limitations.
Is that expected (for 10GB repository if I remember correctly), or is there
some way to avoid this OOM?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [BUG] gitk with few commits
From: Uwe Zeisberger @ 2006-06-09 7:23 UTC (permalink / raw)
To: git
Hello,
I started a new repository, for now there are only two commits. In
gitk the area to display the commits is far from being filled. I can
scroll up all the same.
Then marking commits by clicking on them fails, I have to click where
they are located, when the canvas is scrolled down completely. Then the
canvas is redrawn to show the commits at the top again.
I tried shortly to fix this, but my Tcl/Tk knowledge ...
git version 1.4.0.rc2.ga95e
tcl/tk version 8.4.12-1
(Tk is patched with the patch from D. Richard Hipp Paul Mackerras
provided to me.)
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=30+hours+and+4+days+in+seconds
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 15:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6b798$td3$1@sea.gmane.org>
On Fri, 9 Jun 2006, Jakub Narebski wrote:
> Jon Smirl wrote:
>
> >> git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
> >
> > We are all having problems getting this to run on 32 bit machines with
> > the 3-4GB process size limitations.
>
> Is that expected (for 10GB repository if I remember correctly), or is there
> some way to avoid this OOM?
Well, to some degree, the VM limitations are inevitable with huge packs.
The original idea for packs was to avoid making one huge pack, partly
because it was expected to be really really slow to generate (so
incremental repacking was a much better strategy), but partly simply
because trying to map one huge pack is really hard to do.
For various reasons, we ended up mostly using a single pack most of the
time: it's the most efficient model when the project is reasonably sized,
and it turns out that with the delta re-use, repacking even moderately
large projects like the kernel doesn't actually take all that long.
But the fact that we ended up mostly using a single pack for the kernel,
for example, doesn't mean that the fundamental reasons that git supports
multiple packs would somehow have gone away. At some point, the project
gets large enough that one single pack simply isn't reasonable.
So a single 2GB pack is already very much pushing it. It's really really
hard to map in a 2GB file on a 32-bit platform: your VM is usually
fragmented enough that it simply isn't practical. In fact, I think the
limit for _practical_ usage of single packs is probably somewhere in the
half-gig region, unless you just have 64-bit machines.
And yes, I realize that the "single pack" thing actually ends up having
become a fact for cloning, for example. Originally, cloning would unpack
on the receiving end, and leave the repacking to happen there, but that
obviously sucked. So now when we clone, we always get a single pack. That
can absolutely be a problem.
I don't know what the right solution is. Single packs _are_ very useful,
especially after a clone. So it's possible that we should just make the
pack-reading code be able to map partial packs. But the point is that
there are certainly ways we can fix this - it's not _really_ fundamental.
It's going to complicate it a bit (damn, how I hate 32-bit VM
limitations), but the good news is that the whole git model of "everything
is an individual object" means that it's a very _local_ decision: it will
probably be painful to re-do some of the pack reading code and have a LRU
of pack _fragments_ instead of a LRU of packs, but it's only going to
affect a small part of git, and everything else will never even see it.
So large packs are not really a fundamental problem, but right now we have
some practical issues with them.
(It's not _just_ packs: running out of memory is also because of
git-rev-list --objects being pretty memory hungry. I've improved the
memory usage several times by over 50%, but people keep trying larger
projects. It used to be that I considered the kernel a large history, now
we're talking about things that have ten times the number of objects).
Martin - do you have some place to make that big mozilla repo available?
It would be a good test-case..
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Nicolas Pitre @ 2006-06-09 16:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606090745390.5498@g5.osdl.org>
On Fri, 9 Jun 2006, Linus Torvalds wrote:
>
>
> On Fri, 9 Jun 2006, Jakub Narebski wrote:
> > Jon Smirl wrote:
> >
> > >> git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
> > >
> > > We are all having problems getting this to run on 32 bit machines with
> > > the 3-4GB process size limitations.
> >
> > Is that expected (for 10GB repository if I remember correctly), or is there
> > some way to avoid this OOM?
What was that 10GB related to, exactly? The original CVS repo, or the
unpacked GIT repo?
> So a single 2GB pack is already very much pushing it. It's really really
> hard to map in a 2GB file on a 32-bit platform: your VM is usually
> fragmented enough that it simply isn't practical. In fact, I think the
> limit for _practical_ usage of single packs is probably somewhere in the
> half-gig region, unless you just have 64-bit machines.
Sure, but have we already reached that size?
The historic Linux repo currently repacks itself into a ~175MB pack for
63428 commits.
The current Linux repo is ~103MB with a much shorter history (27153
commits).
Given the above we can estimate the size of the kernel repository after
x commits as follows:
slope = (175 - 103) / (63428 - 27153) = approx 2KB per commit
initial size = 175 - .001985 * 63428 = 49MB
So the initial kernel commit is about 49MB in size which is coherent
with the corresponding compressed tarball. Subsequent commits are 2KB
in size on average. Given that it will take about 233250 commits before
the kernel reaches the half gigabyte pack file, and given the current
commit rate (approx 23700 commits per year), that means we still have
nearly 9 years to go. And at that point 64-bit machines are likely to
be the norm.
So given those numbers I don't think this is really an issue. The Linux
kernel is a rather huge and pretty active project to base comparisons
against. The Mozilla repository might be difficult to import and
repack, but once repacked it should still be pretty usable now even on a
32-bit machine even with a single pack.
Otherwise that should be quite easy to add a batch size argument to
git-repack so git-rev-list and git-pack-objects are called multiple
times with sequential commit
ranges to create a repo with multiple packs.
Nicolas
^ 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