* 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
* [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: [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
* 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: 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: 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: 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
* 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
* [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
* 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
* 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: 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: 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: 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: 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: 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: 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: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: 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: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 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 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] Implement git-branch and git-merge-base as built-ins.
From: Junio C Hamano @ 2006-06-08 18:53 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <4488633A.5060409@bitplanet.net>
Kristian Høgsberg <krh@bitplanet.net> writes:
> This patch is more or less a straight port of git-branch from shell
> script to C. Branch deletion uses git-merge-base to check if it is safe
> to delete a branch, so I changed merge-base.c to export this functionality
> as a for_each_merge_base() iterator. As a side effect, git-merge-base is
> now also a built-in command.
First, some lighter-weight comments:
(0) Somehow your diff have two copies of everything. How did
you prepare this message I wonder...?
(1) Sign your work, please.
(2) I would have preferred a patch to do merge-base and another
patch to do branch. That way, we could do merge-base
without doing branch if we wanted to.
But the patch is wrong. Your for-each-merge-base cannot be
called more than once, but delete-branches does.
The merge-base program as implemented currently is written with
the assumption that it is called only once, and leaves its
working state in parsed commit objects all over the place. In
order to make the second and subsequent call to work correctly,
you need to clean the flags up.
As a demonstration, with this function appended to your
merge-base.c and making it a built-in "merge-base-bogo":
int cmd_merge_base_bogo(int argc, const char **argv, char **envp)
{
struct commit *rev1, *rev2;
unsigned char rev1key[20], rev2key[20];
int errors = 0;
setup_git_directory();
git_config(git_default_config);
while (1 < argc && argv[1][0] == '-') {
const char *arg = argv[1];
if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
show_all = 1;
else
usage(merge_base_usage);
argc--; argv++;
}
for (; 3 <= argc; argc -= 2, argv += 2) {
if (get_sha1(argv[1], rev1key) ||
!(rev1 = lookup_commit_reference(rev1key))) {
error("Not a valid object name %s", argv[1]);
errors++;
continue;
}
if (get_sha1(argv[2], rev2key) ||
!(rev2 = lookup_commit_reference(rev2key))) {
error("Not a valid object name %s", argv[2]);
errors++;
continue;
}
for_each_merge_base(rev1, rev2, print_merge_base, NULL);
}
if (1 < argc) {
error("Trailing argument %s not used", argv[1]);
errors++;
}
return !!errors;
}
Here is what happens.
: gitster; ./git merge-base-bogo 66ae0c77 ced9456a
262a6ef76a1dde97ab50d79fa5cd6d3f9f125765
: gitster; ./git merge-base-bogo 89719209 262a6ef7
aa6bf0eb6489d652c5877d65160ed33c857afa74
: gitster; ./git merge-base-bogo 66ae0c77 ced9456a 89719209 262a6ef7
262a6ef76a1dde97ab50d79fa5cd6d3f9f125765
262a6ef76a1dde97ab50d79fa5cd6d3f9f125765
This is because the invocation for the second pair does not
start with a clean slate, and is affected by the leftover states
from the computation for the first pair. If you swap the
arguments, you sometimes get correct result by accident, like this:
: gitster; ./git merge-base-bogo 89719209 262a6ef7 66ae0c77 ced9456a
aa6bf0eb6489d652c5877d65160ed33c857afa74
262a6ef76a1dde97ab50d79fa5cd6d3f9f125765
Incidentally, this is why I haven't done "A...B" revision syntax
extension to mean "^$(git merge-base A B) B".
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Jakub Narebski @ 2006-06-08 18:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060608153508.GB8047@satan.machinehead.org>
Aneesh Kumar K.V wrote:
> On Thu, Jun 08, 2006 at 03:37:47PM +0200, Karl Hasselstr?m wrote:
>> On 2006-06-08 13:41:04 +0200, Johannes Schindelin wrote:
>>
>> My vote goes to --no-local, but only if we also get a --no-no-local
>> flag with the opposite meaning. Otherwise, I'd prefer --global. :-)
>>
>
>
> I guess it makes much sense to rename the command to git-config and say
>
> git config alias.l -> for golbal config
> git config --repo alias.l -> for repo specific config
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).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Jakub Narebski @ 2006-06-08 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <1149775348.23938.236.camel@cashmere.sps.mot.com>
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.
--
Jakub Narebski
Warsaw, Poland
^ 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