* Re: [PATCH] gc --aggressive: make it really aggressive
From: Johannes Schindelin @ 2007-12-06 15:55 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Linus Torvalds, Daniel Berlin, David Miller, ismail, gcc, git,
gitster
In-Reply-To: <20071206142254.GD5959@artemis.madism.org>
Hi,
On Thu, 6 Dec 2007, Pierre Habouzit wrote:
> On Thu, Dec 06, 2007 at 12:03:38PM +0000, Johannes Schindelin wrote:
> >
> > The default was not to change the window or depth at all. As
> > suggested by Jon Smirl, Linus Torvalds and others, default to
> >
> > --window=250 --depth=250
>
> well, this will explode on many quite reasonnably sized systems. This
> should also use a memory-limit that could be auto-guessed from the
> system total physical memory (50% of the actual memory could be a good
> idea e.g.).
>
> On very large repositories, using that on the e.g. linux kernel, swaps
> like hell on a machine with 1Go of ram, and almost nothing running on it
> (less than 200Mo of ram actually used)
Yes.
However, I think that --aggressive should be aggressive, and if you decide
to run it on a machine which lacks the muscle to be aggressive, well, you
should have known better.
The upside: if you run this on a strong machine and clone it to a weak
machine, you'll still have the benefit of a small pack (and you should
mark it as .keep, too, to keep the benefit...)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add option --path to allow to run tests with real systems. You must install git before running this test.
From: Johannes Schindelin @ 2007-12-06 15:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0712060732r70d07135lf6a01ae2410a0ada@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1492 bytes --]
Hi,
On Thu, 6 Dec 2007, Nguyen Thai Ngoc Duy wrote:
> On Dec 6, 2007 10:23 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Thu, 6 Dec 2007, Nguyễn Thái Ngọc Duy wrote:
> >
> > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> > > ---
> > > On Thu, Dec 06, 2007 at 10:15:05AM +0700, Nguyen Thai Ngoc Duy wrote:
> > > > On Dec 6, 2007 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > > > > This is wrong, isn't it? $path may point at the freshly built but not
> > > > > installed git executable, but it reports --exec-path the location that
> > > > > git-foo and friends are to be _eventually_ installed, not the location
> > > > > they are sitting after built, being tested, waiting to be installed.
> > > > >
> > > > Yes, forgot to mention you must do "make install" first :)
> > > >
> > >
> > > Perhaps a check to remind people to 'make install' like this?
> >
> > Well, the whole point of "make test" is to be sure that it works before
> > installing it.
> >
> > How about something completely different?
>
> I still think testing another round after installing is good. But
> that's not my aim. So Ack on your patch (at least the idea because I
> have not used it yet).
No, I think that testing after installing is way too late.
BTW there was no sign-off on my patch (as well as no commit message),
because it does not work on symbolic-link-challenged systems. So it was
purely meant as inspiration.
Ciao,
Dscho
^ permalink raw reply
* Re: builtin command's prefix question
From: Johannes Schindelin @ 2007-12-06 15:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <fcaeb9bf0712060726r383c3a36j798a439b9dbb0cae@mail.gmail.com>
Hi,
On Thu, 6 Dec 2007, Nguyen Thai Ngoc Duy wrote:
> On Dec 6, 2007 6:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > However, if we define setup() to behave this way when GIT_DIR is not
> > defined and GIT_WORK_TREE is:
> >
> > (1) internally pretend as if GIT_DIR was specified to be the
> > directory where the command was started from (iow, do getcwd()
> > once upon startup);
> >
> > (2) chdir to GIT_WORK_TREE (which means "callers of setup() always
> > run from the top of the work tree");
> >
> > (3) set prefix to NULL;
>
> (1) is fine by me, even if it goes up to find a gitdir. But (3), no,
> prefix should be set as relative path from worktree top directory to
> user current directory, not NULL.
If you expect "git <command> <filespec>" to work correctly from GIT_DIR,
you will _have_ to set the prefix to NULL.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Harvey Harrison @ 2007-12-06 15:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Daniel Berlin, David Miller, ismail, gcc, git,
gitster
In-Reply-To: <Pine.LNX.4.64.0712061201580.27959@racer.site>
Wow
/usr/bin/time git repack -a -d -f --window=250 --depth=250
23266.37user 581.04system 7:41:25elapsed 86%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (419835major+123275804minor)pagefaults 0swaps
-r--r--r-- 1 hharrison hharrison 29091872 2007-12-06 07:26
pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.idx
-r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26
pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack
That extra delta depth really does make a difference. Just over a
300MB pack in the end, for all gcc branches/tags as of last night.
Cheers,
Harvey
^ permalink raw reply
* Re: builtin command's prefix question
From: Nguyen Thai Ngoc Duy @ 2007-12-06 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlk88n648.fsf@gitster.siamese.dyndns.org>
On Dec 6, 2007 5:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The intention is:
>
> * If GIT_DIR is set but not GIT_WORK_TREE (nor core.worktree in
> config), you are either inside project.git/ directory of bare
> repository or at the toplevel of worktree-full directory. This has
> been the traditional behaviour before GIT_WORK_TREE and we shouldn't
> break the existing setups that assume this behaviour. So in that
> sense, with this combination:
>
> - If the repository is bare, the value of the prefix should not
> matter; the command that wants to look at prefix by definition
> wants to run from a subdirectory but there is no notion of
> "the user directory being a subdirectory of the top of the work
> tree" in a bare repository;
>
> - If the repository is not bare, the user directory _MUST_ be at the
> top of the work tree, as that is what the traditional behaviour is.
> Anything else would break existing setups.
>
> IOW, if you use GIT_DIR and still want to run from a subdirectory
> of the worktree, you must have either GIT_WORK_TREE or
> core.worktree to tell where the top of the worktree is, and if you
> don't, then you must be at the top.
>
> So the right thing to do in this case is not going anywhere and using
> prefix=NULL.
You are right. It is quite obvious from the code. No idea why I had
that in my mind.
> * I would say it is a misconfiguration if GIT_DIR is not set and
> GIT_WORK_TREE is, as the sole purpose of GIT_WORK_TREE is so that you
> can work from a subdirectory when you set GIT_DIR. I may be missing
> an obvious use case that this is useful, but I do not think of any.
> Dscho may be able to correct me on this, as he fixed up the original
> work tree series that was even messier quite a bit during the last
> round.
On Dec 6, 2007 6:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> However, if we define setup() to behave this way when GIT_DIR is not
> defined and GIT_WORK_TREE is:
>
> (1) internally pretend as if GIT_DIR was specified to be the
> directory where the command was started from (iow, do getcwd()
> once upon startup);
>
> (2) chdir to GIT_WORK_TREE (which means "callers of setup() always
> run from the top of the work tree");
>
> (3) set prefix to NULL;
(1) is fine by me, even if it goes up to find a gitdir. But (3), no,
prefix should be set as relative path from worktree top directory to
user current directory, not NULL.
> ...
> While I still think the combination is simply crazy and does not make
> any sense, if enough users on the list agrees that it makes sense, I
> wouldn't mind setup() did (1) to (3) mentioned above. The alternative
> is simply to declare GIT_WOR+1 on whatever way that makes worktree less complicated. so your alternative ++K_TREE without GIT_DIR is a nonsense and
> either error error out or ignore GIT_WORK_TREE, which might be easier to
> explain to people.
I don't use either way you mentioned. So no comment here. But again,
no (3) please.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add option --path to allow to run tests with real systems. You must install git before running this test.
From: Johannes Schindelin @ 2007-12-06 15:23 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20071206134817.GA8523@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1669 bytes --]
Hi,
On Thu, 6 Dec 2007, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> On Thu, Dec 06, 2007 at 10:15:05AM +0700, Nguyen Thai Ngoc Duy wrote:
> > On Dec 6, 2007 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > > This is wrong, isn't it? $path may point at the freshly built but not
> > > installed git executable, but it reports --exec-path the location that
> > > git-foo and friends are to be _eventually_ installed, not the location
> > > they are sitting after built, being tested, waiting to be installed.
> > >
> > Yes, forgot to mention you must do "make install" first :)
> >
>
> Perhaps a check to remind people to 'make install' like this?
Well, the whole point of "make test" is to be sure that it works before
installing it.
How about something completely different?
-- snipsnap --
t/test-lib.sh | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 90b6844..ee87b83 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -296,7 +296,18 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in trash subdirectory.
-PATH=$(pwd)/..:$PATH
+
+# Test libexec, while we are at it
+
+test -d test-bin || mkdir test-bin || error "t/test-bin/ could not be created"
+for file in ../git ../git-sh-setup ../test-*
+do
+ target=test-bin/"$(basename "$filename")"
+ test -x "$file" && test ! -x "$target" &&
+ ln -s ../"$file" test-bin/
+done
+
+PATH=$(pwd)/test-bin:$PATH
GIT_EXEC_PATH=$(pwd)/..
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
GIT_CONFIG=.git/config
^ permalink raw reply related
* [BUG/RFC git-gui] password for push/pull in case of git+ssh://repo
From: Ivo Alxneit @ 2007-12-06 14:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]
when i use git-gui (0.9.0) to push/pull to/from a git+ssh://repo i have
to supply my password to ssh. i get the password prompt from ssh on the
controlling shell. as i often use several shells and git-gui might run
in the background it is rather bothering to find the correct shell where
ssh expects the password. could this be changed (in a safe way) in
git-gui e.g. like pinentry pops up a window when gpg is used to sign
emails?
p.s. please cc me. i have not subscribed to the list
thanks
--
Dr. Ivo Alxneit
Laboratory for Solar Technology phone: +41 56 310 4092
Paul Scherrer Institute fax: +41 56 310 2688
CH-5232 Villigen http://solar.web.psi.ch
Switzerland gnupg key: 0x515E30C7
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] hg-to-git: do not include the branch name as the first line of commit msg
From: Baz @ 2007-12-06 14:36 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, Mark Drago, git
In-Reply-To: <1196949043.5388.18.camel@galileo>
On Dec 6, 2007 1:50 PM, Stelian Pop <stelian@popies.net> wrote:
>
> Le lundi 03 décembre 2007 à 17:20 -0800, Junio C Hamano a écrit :
>
> > > (fdcomment, filecomment) = tempfile.mkstemp()
> > > - csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag:' % cset).read().strip()
> > > + csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
> > > os.write(fdcomment, csetcomment)
> > > os.close(fdcomment)
> >
> > Isn't this one of the ugliest lines in the whole git.git project, I have
> > to wonder?
>
> It probably is, and I take full resposibility for the original
> version :). Incremental development woes.
>
> > I also wonder missing colon after "date" is a bug from the original
> > version, and assuming that it is,
>
> It is indeed a bug.
>
> > how about doing something less error
> > prone like this?
> >
> > def included(line):
> > keywords = ('changeset', 'parent', 'user', 'date', 'files',
> > 'description', 'tag', 'branch')
> > for kw in keywords:
> > if line.startswith(kw + ':'):
> > return 0
> > return 1
> >
> > hglog = os.popen('hg log -r %d -v' % cset).read();
> > csetcomment = '\n'.join(filter(included, hglog.split('\n'))).strip()
>
> Seems great to me.
>
> > If you are excluding _all_ of the <word>: header lines, the "included"
> > function may have to become cleverer but much simpler by doing something
> > like:
> >
> > import re
> > header_re = re.compile(r'^\w+:')
> > def included(line):
> > return not header_re.match(line)
>
> I'm afraid something like this will be much more prone to false
> positives.
>
> Maybe an even better alternative, given the way mercurial outputs the
> changeset information, is to search for the '^description:' tag and take
> all the text that follows.
Would it not be better to use hg log --template to output only the
information needed?
eg
date = os.popen('hg log -r %d --template "{date|isodate}"' %
cset).read().strip()
... or even just create a template to pull in everything needed in a
single popen.
-Baz
>
> --
> Stelian Pop <stelian@popies.net>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Pierre Habouzit @ 2007-12-06 14:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Daniel Berlin, David Miller, ismail, gcc, git,
gitster
In-Reply-To: <Pine.LNX.4.64.0712061201580.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Thu, Dec 06, 2007 at 12:03:38PM +0000, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
well, this will explode on many quite reasonnably sized systems. This
should also use a memory-limit that could be auto-guessed from the
system total physical memory (50% of the actual memory could be a good
idea e.g.).
On very large repositories, using that on the e.g. linux kernel, swaps
like hell on a machine with 1Go of ram, and almost nothing running on it
(less than 200Mo of ram actually used)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git and GCC
From: Nicolas Pitre @ 2007-12-06 14:18 UTC (permalink / raw)
To: Jeff King
Cc: Jon Smirl, Daniel Berlin, Harvey Harrison, David Miller, ismail,
gcc, git
In-Reply-To: <20071206071503.GA19504@coredump.intra.peff.net>
On Thu, 6 Dec 2007, Jeff King wrote:
> On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
>
> > The key to converting repositories of this size is RAM. 4GB minimum,
> > more would be better. git-repack is not multi-threaded. There were a
> > few attempts at making it multi-threaded but none were too successful.
> > If I remember right, with loads of RAM, a repack on a 450MB repository
> > was taking about five hours on a 2.8Ghz Core2. But this is something
> > you only have to do once for the import. Later repacks will reuse the
> > original deltas.
>
> Actually, Nicolas put quite a bit of work into multi-threading the
> repack process; the results have been in master for some time, and will
> be in the soon-to-be-released v1.5.4.
>
> The downside is that the threading partitions the object space, so the
> resulting size is not necessarily as small (but I don't know that
> anybody has done testing on large repos to find out how large the
> difference is).
Quick guesstimate is in the 1% ballpark.
Nicolas
^ permalink raw reply
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Nicolas Pitre @ 2007-12-06 14:15 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Linus Torvalds, Daniel Berlin, David Miller,
ismail, gcc, git, gitster
In-Reply-To: <20071206134243.GA17037@thunk.org>
On Thu, 6 Dec 2007, Theodore Tso wrote:
> Linus later pointed out that what we *really* should do is at some
> point was to change repack -f to potentially retry to find a better
> delta, but to reuse the existing delta if it was no worse. That
> automatically does the right thing in the case where you had
> previously done a repack with --window=<large n> --depth=<large n>,
> but then later try using "gc --agressive", which ends up doing a worse
> job and throwing away the information from the previous repack with
> large window and depth sizes. Unfortunately no one ever got around to
> implementing that.
I did start looking at it, but there are subtle issues to consider, such
as making sure not to create delta loops. Currently this is avoided by
never involving already reused deltas in new delta chains, except for
edge base objects.
IOW, this requires some head scratching which I didn't have the time for
so far.
Nicolas
^ permalink raw reply
* Re: fetch_refs_via_pack() discards status?
From: Daniel Barkalow @ 2007-12-06 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <7vwsrsonqm.fsf@gitster.siamese.dyndns.org>
On Wed, 5 Dec 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Tue, 4 Dec 2007, Junio C Hamano wrote:
> >
> >> The code calls fetch_pack() to get the list of refs it fetched, and
> >> discards refs and always returns 0 to signal success.
> >>
> >> But builtin-fetch-pack.c::fetch_pack() has error cases. The function
> >> returns NULL if error is detected (shallow-support side seems to choose
> >> to die but I suspect that is easily fixable to error out as well).
> >>
> >> Shouldn't fetch_refs_via_pack() propagate that error to the caller?
> >
> > I think that's right. I think I got as far as having the error status from
> > fetch_pack() actually returned correctly, and then failed to look at it.
> > I'd personally avoid testing a pointer to freed memory, but that's
> > obviously not actually wrong.
> >
> > -Daniel
>
> Hmph, is that an Ack that the patchlet is actually a bugfix?
Yes.
Acked-By: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] hg-to-git: do not include the branch name as the first line of commit msg
From: Stelian Pop @ 2007-12-06 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Drago, git
In-Reply-To: <7vsl2jcl32.fsf@gitster.siamese.dyndns.org>
Le lundi 03 décembre 2007 à 17:20 -0800, Junio C Hamano a écrit :
> > (fdcomment, filecomment) = tempfile.mkstemp()
> > - csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag:' % cset).read().strip()
> > + csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
> > os.write(fdcomment, csetcomment)
> > os.close(fdcomment)
>
> Isn't this one of the ugliest lines in the whole git.git project, I have
> to wonder?
It probably is, and I take full resposibility for the original
version :). Incremental development woes.
> I also wonder missing colon after "date" is a bug from the original
> version, and assuming that it is,
It is indeed a bug.
> how about doing something less error
> prone like this?
>
> def included(line):
> keywords = ('changeset', 'parent', 'user', 'date', 'files',
> 'description', 'tag', 'branch')
> for kw in keywords:
> if line.startswith(kw + ':'):
> return 0
> return 1
>
> hglog = os.popen('hg log -r %d -v' % cset).read();
> csetcomment = '\n'.join(filter(included, hglog.split('\n'))).strip()
Seems great to me.
> If you are excluding _all_ of the <word>: header lines, the "included"
> function may have to become cleverer but much simpler by doing something
> like:
>
> import re
> header_re = re.compile(r'^\w+:')
> def included(line):
> return not header_re.match(line)
I'm afraid something like this will be much more prone to false
positives.
Maybe an even better alternative, given the way mercurial outputs the
changeset information, is to search for the '^description:' tag and take
all the text that follows.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: Git and GCC
From: Nicolas Pitre @ 2007-12-06 14:01 UTC (permalink / raw)
To: Harvey Harrison
Cc: Linus Torvalds, Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <1196927361.13109.1.camel@brick>
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> > git repack -a -d --depth=250 --window=250
> >
>
> Since I have the whole gcc repo locally I'll give this a shot overnight
> just to see what can be done at the extreme end or things.
Don't forget to add -f as well.
Nicolas
^ permalink raw reply
* [PATCH] Add option --path to allow to run tests with real systems. You must install git before running this test.
From: Nguyễn Thái Ngọc Duy @ 2007-12-06 13:48 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7v3auhq6mv.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Thu, Dec 06, 2007 at 10:15:05AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Dec 6, 2007 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > This is wrong, isn't it? $path may point at the freshly built but not
> > installed git executable, but it reports --exec-path the location that
> > git-foo and friends are to be _eventually_ installed, not the location
> > they are sitting after built, being tested, waiting to be installed.
> >
> Yes, forgot to mention you must do "make install" first :)
>
Perhaps a check to remind people to 'make install' like this?
t/lib-git-svn.sh | 2 +-
t/t0000-basic.sh | 6 +++---
t/t0040-parse-options.sh | 16 ++++++++--------
t/t4200-rerere.sh | 8 ++++----
t/t5301-sliding-window.sh | 2 +-
t/t5302-pack-index.sh | 4 ++--
t/test-lib.sh | 19 +++++++++++++++----
7 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 8d4a447..fd60ebc 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -46,7 +46,7 @@ rawsvnrepo="$svnrepo"
svnrepo="file://$svnrepo"
poke() {
- test-chmtime +1 "$1"
+ $GIT_TEST_PATH/test-chmtime +1 "$1"
}
SVN_HTTPD_MODULE_PATH=${SVN_HTTPD_MODULE_PATH-'/usr/lib/apache2/modules'}
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 4e49d59..f809163 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -289,12 +289,12 @@ test_expect_success 'absolute path works as expected' '
mkdir third &&
dir="$(cd .git; pwd -P)" &&
dir2=third/../second/other/.git &&
- test "$dir" = "$(test-absolute-path $dir2)" &&
+ test "$dir" = "$($GIT_TEST_PATH/test-absolute-path $dir2)" &&
file="$dir"/index &&
- test "$file" = "$(test-absolute-path $dir2/index)" &&
+ test "$file" = "$($GIT_TEST_PATH/test-absolute-path $dir2/index)" &&
ln -s ../first/file .git/syml &&
sym="$(cd first; pwd -P)"/file &&
- test "$sym" = "$(test-absolute-path $dir2/syml)"
+ test "$sym" = "$($GIT_TEST_PATH/test-absolute-path $dir2/syml)"
'
test_done
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 462fdf2..ca1cc9f 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -23,7 +23,7 @@ string options
EOF
test_expect_success 'test help' '
- ! test-parse-options -h > output 2> output.err &&
+ ! $GIT_TEST_PATH/test-parse-options -h > output 2> output.err &&
test ! -s output &&
git diff expect.err output.err
'
@@ -35,7 +35,7 @@ string: 123
EOF
test_expect_success 'short options' '
- test-parse-options -s123 -b -i 1729 -b > output 2> output.err &&
+ $GIT_TEST_PATH/test-parse-options -s123 -b -i 1729 -b > output 2> output.err &&
git diff expect output &&
test ! -s output.err
'
@@ -46,7 +46,7 @@ string: 321
EOF
test_expect_success 'long options' '
- test-parse-options --boolean --integer 1729 --boolean --string2=321 \
+ $GIT_TEST_PATH/test-parse-options --boolean --integer 1729 --boolean --string2=321 \
> output 2> output.err &&
test ! -s output.err &&
git diff expect output
@@ -62,7 +62,7 @@ arg 02: --boolean
EOF
test_expect_success 'intermingled arguments' '
- test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
+ $GIT_TEST_PATH/test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
> output 2> output.err &&
test ! -s output.err &&
git diff expect output
@@ -75,19 +75,19 @@ string: (not set)
EOF
test_expect_success 'unambiguously abbreviated option' '
- test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+ $GIT_TEST_PATH/test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
test_expect_success 'unambiguously abbreviated option with "="' '
- test-parse-options --int=2 > output 2> output.err &&
+ $GIT_TEST_PATH/test-parse-options --int=2 > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
test_expect_failure 'ambiguously abbreviated option' '
- test-parse-options --strin 123;
+ $GIT_TEST_PATH/test-parse-options --strin 123;
test $? != 129
'
@@ -98,7 +98,7 @@ string: 123
EOF
test_expect_success 'non ambiguous option (after two options it abbreviates)' '
- test-parse-options --st 123 > output 2> output.err &&
+ $GIT_TEST_PATH/test-parse-options --st 123 > output 2> output.err &&
test ! -s output.err &&
git diff expect output
'
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index cfcdb69..ddbae1d 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -149,16 +149,16 @@ just_over_15_days_ago=$((-1-15*86400))
almost_60_days_ago=$((60-60*86400))
just_over_60_days_ago=$((-1-60*86400))
-test-chmtime =$almost_60_days_ago $rr/preimage
-test-chmtime =$almost_15_days_ago $rr2/preimage
+$GIT_TEST_PATH/test-chmtime =$almost_60_days_ago $rr/preimage
+$GIT_TEST_PATH/test-chmtime =$almost_15_days_ago $rr2/preimage
test_expect_success 'garbage collection (part1)' 'git rerere gc'
test_expect_success 'young records still live' \
"test -f $rr/preimage && test -f $rr2/preimage"
-test-chmtime =$just_over_60_days_ago $rr/preimage
-test-chmtime =$just_over_15_days_ago $rr2/preimage
+$GIT_TEST_PATH/test-chmtime =$just_over_60_days_ago $rr/preimage
+$GIT_TEST_PATH/test-chmtime =$just_over_15_days_ago $rr2/preimage
test_expect_success 'garbage collection (part2)' 'git rerere gc'
diff --git a/t/t5301-sliding-window.sh b/t/t5301-sliding-window.sh
index 073ac0c..8327051 100755
--- a/t/t5301-sliding-window.sh
+++ b/t/t5301-sliding-window.sh
@@ -12,7 +12,7 @@ test_expect_success \
for i in a b c
do
echo $i >$i &&
- test-genrandom "$i" 32768 >>$i &&
+ $GIT_TEST_PATH/test-genrandom "$i" 32768 >>$i &&
git update-index --add $i || return 1
done &&
echo d >d && cat c >>d && git update-index --add d &&
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 2a2878b..0ae9cd8 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -15,11 +15,11 @@ test_expect_success \
do
i=`printf '%03i' $i`
echo $i >file_$i &&
- test-genrandom "$i" 8192 >>file_$i &&
+ $GIT_TEST_PATH/test-genrandom "$i" 8192 >>file_$i &&
git update-index --add file_$i &&
i=`expr $i + 1` || return 1
done &&
- { echo 101 && test-genrandom 100 8192; } >file_101 &&
+ { echo 101 && $GIT_TEST_PATH/test-genrandom 100 8192; } >file_101 &&
git update-index --add file_101 &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 90b6844..97c0f4d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -84,6 +84,8 @@ do
--no-python)
# noop now...
shift ;;
+ --path=*)
+ path="${1#*=}"; shift ;;
*)
break ;;
esac
@@ -296,11 +298,20 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in trash subdirectory.
-PATH=$(pwd)/..:$PATH
-GIT_EXEC_PATH=$(pwd)/..
+if [ -n "$path" ]; then
+ [ -x "$path/git" ] || error "git not found in $path"
+ [ "$($path/git --version)" = "$(../git --version)" ] ||
+ error "Version mismatch. Did you forget to 'make install'?"
+ PATH="$path":$PATH
+ GIT_EXEC_PATH="$($path/git --exec-path)"
+else
+ PATH=$(pwd)/..:$PATH
+ GIT_EXEC_PATH=$(pwd)/..
+fi
+GIT_TEST_PATH=$(pwd)/..
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
GIT_CONFIG=.git/config
-export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG GIT_TEST_PATH
GITPERLLIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
export GITPERLLIB
@@ -308,7 +319,7 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
-if ! test -x ../test-chmtime; then
+if ! test -x $GIT_TEST_PATH/test-chmtime; then
echo >&2 'You need to build test-chmtime:'
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
exit 1
--
1.5.3.6.2040.gfc2f-dirty
^ permalink raw reply related
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Theodore Tso @ 2007-12-06 13:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Daniel Berlin, David Miller, ismail, gcc, git,
gitster
In-Reply-To: <Pine.LNX.4.64.0712061201580.27959@racer.site>
On Thu, Dec 06, 2007 at 12:03:38PM +0000, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
I'd also suggest adding a comment in the man pages that this should
only be done rarely, and that it can potentially take a *long* time
(i.e., overnight) for big repositories, and in general it's not worth
the effort to use --aggressive.
Apologies to Linus and to the gcc folks, since I was the one who
originally coded up gc --aggressive, and at the time my intent was
"rarely does it make sense, and it may take a long time". The reason
why I didn't make the default --window and --depth larger is because
at the time the biggest repo I had easy access to was the Linux
kernel's, and there you rapidly hit diminishing returns at much
smaller numbers, so there was no real point in using --window=250
--depth=250.
Linus later pointed out that what we *really* should do is at some
point was to change repack -f to potentially retry to find a better
delta, but to reuse the existing delta if it was no worse. That
automatically does the right thing in the case where you had
previously done a repack with --window=<large n> --depth=<large n>,
but then later try using "gc --agressive", which ends up doing a worse
job and throwing away the information from the previous repack with
large window and depth sizes. Unfortunately no one ever got around to
implementing that.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits
From: Mark Drago @ 2007-12-06 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: stelian, git
In-Reply-To: <7veje11v7f.fsf@gitster.siamese.dyndns.org>
On Dec 5, 2007 2:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Mark Drago <markdrago@gmail.com> writes:
> >
> >> This patch will detect that there are no changes to commit (using git-status),
> >> and will not perform the commit, but will instead combine the log messages of
> >> that (non-)commit with the next commit.
> >
> > I think a better approach would be to implement --no-tree-change-is-ok
> > option to git-commit, strictly for use by foreign scm interface scripts
> > like yours. It does not usually make sense to record a commit that has
> > the exact same tree as its sole parent commit and that is why git-commit
> > prevents you from making that mistake, but when data from foreign scm is
> > involved, it is a different story. We are equipped to represent such a
> > (perhaps insane, perhaps by mistake, or perhaps done on purpose) change
> > and it is better to represent it bypassing the safety valve for native
> > use.
>
> So I did "git commit --allow-empty". With that, perhaps the following
> will fix the issue?
>
> I won't be commiting this myself until I hear a positive Ack.
I gave this a test and it works perfectly well. Commit away.
Thanks,
Mark.
> ---
> contrib/hg-to-git/hg-to-git.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
> index 7a1c3e4..9befb92 100755
> --- a/contrib/hg-to-git/hg-to-git.py
> +++ b/contrib/hg-to-git/hg-to-git.py
> @@ -211,7 +211,7 @@ for cset in range(int(tip) + 1):
> os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
>
> # commit
> - os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
> + os.system(getgitenv(user, date) + 'git commit --allow-empty -a -F %s' % filecomment)
> os.unlink(filecomment)
>
> # tag
>
^ permalink raw reply
* [PATCH amended] for-each-ref: Fix quoting style constants.
From: Johannes Sixt @ 2007-12-06 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Sixt
In-Reply-To: <1196943106-4559-1-git-send-email-johannes.sixt@telecom.at>
for-each-ref can accept only one quoting style. For this reason it uses
OPT_BIT for the quoting style switches so that it is easy to check for
more than one bit being set. However, not all symbolic constants were
actually single bit values. In particular:
$ git for-each-ref --python
error: more than one quoting style ?
This fixes it.
While we are here, let's also remove the space before the question mark.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
This fixes the test cases so that the headlines tell what the
tests cases actually test.
Don't know what I was smoking when I submitted the first version.
-- Hannes
builtin-for-each-ref.c | 6 +++---
t/t6300-for-each-ref.sh | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index daf3a08..f36a43c 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -13,8 +13,8 @@
#define QUOTE_NONE 0
#define QUOTE_SHELL 1
#define QUOTE_PERL 2
-#define QUOTE_PYTHON 3
-#define QUOTE_TCL 4
+#define QUOTE_PYTHON 4
+#define QUOTE_TCL 8
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
@@ -861,7 +861,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
usage_with_options(for_each_ref_usage, opts);
}
if (HAS_MULTI_BITS(quote_style)) {
- error("more than one quoting style ?");
+ error("more than one quoting style?");
usage_with_options(for_each_ref_usage, opts);
}
if (verify_format(format))
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index c722635..8a23aaf 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -169,5 +169,44 @@ test_expect_success 'Verify descending sort' '
git diff expected actual
'
+cat >expected <<\EOF
+'refs/heads/master'
+'refs/tags/testtag'
+EOF
+
+test_expect_success 'Quoting style: shell' '
+ git for-each-ref --shell --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+test_expect_success 'Quoting style: perl' '
+ git for-each-ref --perl --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+test_expect_success 'Quoting style: python' '
+ git for-each-ref --python --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+cat >expected <<\EOF
+"refs/heads/master"
+"refs/tags/testtag"
+EOF
+
+test_expect_success 'Quoting style: tcl' '
+ git for-each-ref --tcl --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+for i in "--perl --shell" "-s --python" "--python --tcl" "--tcl --perl"; do
+ test_expect_success "more than one quoting style: $i" "
+ git for-each-ref $i 2>&1 | (read line &&
+ case \$line in
+ \"error: more than one quoting style\"*) : happy;;
+ *) false
+ esac)
+ "
+done
test_done
--
1.5.3.7.1079.gecca
^ permalink raw reply related
* Re: [PATCH] for-each-ref: Fix quoting style constants.
From: Johannes Schindelin @ 2007-12-06 12:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <1196943106-4559-1-git-send-email-johannes.sixt@telecom.at>
Hi,
On Thu, 6 Dec 2007, Johannes Sixt wrote:
> $ git for-each-ref --python
> error: more than one quoting style ?
>
> While we are here, let's also remove the space before the question mark.
Doesn't python need that piece of whitespace? *ducks*
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Mirroring svn
From: Harvey Harrison @ 2007-12-06 12:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0712061214340.27959@racer.site>
On Thu, 2007-12-06 at 12:15 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> > On Thu, 2007-12-06 at 01:43 -0500, Jeff King wrote:
> > > On Wed, Dec 05, 2007 at 10:22:33PM -0800, Harvey Harrison wrote:
> > >
> > > > // fetching someone else's remote branches is not a standard thing to do
> > > > // so we'll need to edit our .git/config file
> > > > // you should have a section that looks like:
> > > > [remote "gcc.gnu.org"]
> > > > url = git://git.infradead.org/gcc.git
> > > > fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> > > > // infradead's mirror puts the gcc svn branches in its own namespace
> > > > // refs/remotes/gcc.gnu.org/*
> > > > // change our fetch line accordingly
> > > > [remote "gcc.gnu.org"]
> > > > url = git://git.infradead.org/gcc.git
> > > > fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> > >
> > > FWIW, if you are writing a shell recipe for other people to cut and
> > > paste, you can say this as:
> > >
> > > git config remote.gcc.gnu.org.fetch \
> > > '+refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*'
> >
> > I thought about that, but I like to encourage people to actually look at
> > the config file, it's pretty easy to understand.
>
> I agree that people should be encouraged to edit their .git/config. But a
> recipe is something easy-to-follow IMHO, so I would write this as a shell
> script (with #-comments, not //-comments).
I'll probably turn it into such eventually, this was more of a
hand-holding exercise for people who would like to try git in gcc-land.
Harvey
^ permalink raw reply
* Re: [RFC] Mirroring svn
From: Johannes Schindelin @ 2007-12-06 12:15 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Jeff King, git
In-Reply-To: <1196923525.10408.103.camel@brick>
Hi,
On Wed, 5 Dec 2007, Harvey Harrison wrote:
> On Thu, 2007-12-06 at 01:43 -0500, Jeff King wrote:
> > On Wed, Dec 05, 2007 at 10:22:33PM -0800, Harvey Harrison wrote:
> >
> > > // fetching someone else's remote branches is not a standard thing to do
> > > // so we'll need to edit our .git/config file
> > > // you should have a section that looks like:
> > > [remote "gcc.gnu.org"]
> > > url = git://git.infradead.org/gcc.git
> > > fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> > > // infradead's mirror puts the gcc svn branches in its own namespace
> > > // refs/remotes/gcc.gnu.org/*
> > > // change our fetch line accordingly
> > > [remote "gcc.gnu.org"]
> > > url = git://git.infradead.org/gcc.git
> > > fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> >
> > FWIW, if you are writing a shell recipe for other people to cut and
> > paste, you can say this as:
> >
> > git config remote.gcc.gnu.org.fetch \
> > '+refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*'
>
> I thought about that, but I like to encourage people to actually look at
> the config file, it's pretty easy to understand.
I agree that people should be encouraged to edit their .git/config. But a
recipe is something easy-to-follow IMHO, so I would write this as a shell
script (with #-comments, not //-comments).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] Use regex for :/ matching
From: Johannes Schindelin @ 2007-12-06 12:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071206063945.GB18698@coredump.intra.peff.net>
Hi,
On Thu, 6 Dec 2007, Jeff King wrote:
> On Wed, Dec 05, 2007 at 10:33:49PM -0800, Junio C Hamano wrote:
>
> > Making what was string match to regex using the same syntax is a
> > regression, isn't it? I do not use :/ very often myself, so I
> > personally would not mind but people who are used to using :/ may get
> > upset about the change. I do not feel strongly enough for changing it
> > to regex to declare such a change unilaterally.
>
> Yes, it is a regression, which is why my initial patch was labeled RFC.
> Nobody commented on that aspect, [...]
I did. I sent a link to my own version of that patch, thereby displaying
my agreement with the intent.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] for-each-ref: Fix quoting style constants.
From: Johannes Sixt @ 2007-12-06 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Sixt
for-each-ref can accept only one quoting style. For this reason it uses
OPT_BIT for the quoting style switches so that it is easy to check for
more than one bit being set. However, not all symbolic constants were
actually single bit values. In particular:
$ git for-each-ref --python
error: more than one quoting style ?
This fixes it.
While we are here, let's also remove the space before the question mark.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-for-each-ref.c | 6 +++---
t/t6300-for-each-ref.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index daf3a08..f36a43c 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -13,8 +13,8 @@
#define QUOTE_NONE 0
#define QUOTE_SHELL 1
#define QUOTE_PERL 2
-#define QUOTE_PYTHON 3
-#define QUOTE_TCL 4
+#define QUOTE_PYTHON 4
+#define QUOTE_TCL 8
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
@@ -861,7 +861,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
usage_with_options(for_each_ref_usage, opts);
}
if (HAS_MULTI_BITS(quote_style)) {
- error("more than one quoting style ?");
+ error("more than one quoting style?");
usage_with_options(for_each_ref_usage, opts);
}
if (verify_format(format))
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index c722635..c5d0721 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -169,5 +169,49 @@ test_expect_success 'Verify descending sort' '
git diff expected actual
'
+cat >expected <<\EOF
+'refs/heads/master'
+'refs/tags/testtag'
+EOF
+
+test_expect_success 'Quoting style: shell' '
+ git for-each-ref --shell --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+test_expect_success 'Quoting style: perl' '
+ git for-each-ref --perl --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+test_expect_success 'Quoting style: python' '
+ git for-each-ref --python --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+test_expect_success 'Quoting style: tcl' '
+ git for-each-ref --python --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+cat >expected <<\EOF
+"refs/heads/master"
+"refs/tags/testtag"
+EOF
+
+test_expect_success 'Quoting style: shell' '
+ git for-each-ref --tcl --format="%(refname)" >actual &&
+ git diff expected actual
+'
+
+for i in "--perl --shell" "-s --python" "--python --tcl" "--tcl --perl"; do
+ test_expect_success "more than one quoting style: $i" "
+ git for-each-ref $i 2>&1 | (read line &&
+ case \$line in
+ \"error: more than one quoting style\"*) : happy;;
+ *) false
+ esac)
+ "
+done
test_done
--
1.5.3.7.1079.gecca
^ permalink raw reply related
* [PATCH] gc --aggressive: make it really aggressive
From: Johannes Schindelin @ 2007-12-06 12:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Berlin, David Miller, ismail, gcc, git, gitster
In-Reply-To: <alpine.LFD.0.9999.0712052132450.13796@woody.linux-foundation.org>
The default was not to change the window or depth at all. As suggested
by Jon Smirl, Linus Torvalds and others, default to
--window=250 --depth=250
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 5 Dec 2007, Linus Torvalds wrote:
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb
> > thing to pack files sometimes regardless of whether you
> > converted from an SVN repo or not.
>
> Absolutely. git --aggressive is mostly dumb. It's really only
> useful for the case of "I know I have a *really* bad pack, and I
> want to throw away all the bad packing decisions I have done".
>
> [...]
>
> So the equivalent of "git gc --aggressive" - but done *properly*
> - is to do (overnight) something like
>
> git repack -a -d --depth=250 --window=250
How about this, then?
builtin-gc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 799c263..c6806d3 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -23,7 +23,7 @@ static const char * const builtin_gc_usage[] = {
};
static int pack_refs = 1;
-static int aggressive_window = -1;
+static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 20;
@@ -192,6 +192,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (aggressive) {
append_option(argv_repack, "-f", MAX_ADD);
+ append_option(argv_repack, "--depth=250", MAX_ADD);
if (aggressive_window > 0) {
sprintf(buf, "--window=%d", aggressive_window);
append_option(argv_repack, buf, MAX_ADD);
--
1.5.3.7.2157.g9598e
^ permalink raw reply related
* Re: Git and GCC
From: Ismail Dönmez @ 2007-12-06 12:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Miller, dberlin, gcc, git
In-Reply-To: <Pine.LNX.4.64.0712061150590.27959@racer.site>
Thursday 06 December 2007 13:57:06 Johannes Schindelin yazmıştı:
[...]
> So I fully expect an issue like Daniel's to be resolved in a matter of
> minutes on the git list, if the OP gives us a chance. If we are not even
> Cc'ed, you are completely right, she or he probably does not want the
> issue to be resolved.
Lets be fair about this, Ollie Wild already sent a mail about git-svn disk
usage and there is no concrete solution yet, though it seems the bottleneck
is known.
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ 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