* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Jeff King @ 2009-11-10 12:23 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <1257850011-7544-1-git-send-email-book@cpan.org>
On Tue, Nov 10, 2009 at 11:46:51AM +0100, Philippe Bruhat (BooK) wrote:
> The main Makefile defines PERL_PATH as the perl to use in the shebang
> line of git*.perl commands. This ensures this will be the perl used
> to run the tests (in case another perl appears in $PATH before the one
> defined in $PERL_PATH)
I think this "the perl used to run the tests" needs to be clarified in
the commit message. There are really three ways we use perl in the
tests:
1. To run to the git-* scripts themselves.
2. To run a test snippet of perl as if we were a git-* script.
3. To run random perl helper functions.
We already use PERL_PATH for (1). I don't think there is much point in
worrying about (3). If the perl in your PATH is so broken that it can't
be used for simple helpers, then you should fix your PATH.
Your patch seems to just fix (2), which I think is sane. But I wanted to
note it, because when I read your commit message, I wasn't sure which
you were doing.
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -730,6 +730,8 @@ esac
>
> test -z "$NO_PERL" && test_set_prereq PERL
>
> +test -z "$NO_PERL" && test -z "$PERL_PATH" && export PERL_PATH=/usr/bin/perl
> +
> # test whether the filesystem supports symbolic links
> ln -s x y 2>/dev/null && test -h y 2>/dev/null && test_set_prereq SYMLINKS
> rm -f y
Will this work if I just have PERL_PATH in my config.mak in the root
directory? Should we be adding PERL_PATH to the generated
GIT-BUILD-OPTIONS file in the root, which gets sourced by test-lib?
Something like the following (completely untested) patch?
diff --git a/Makefile b/Makefile
index a10a60c..b9a8145 100644
--- a/Makefile
+++ b/Makefile
@@ -1643,6 +1643,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# and the first level quoting from the shell that runs "echo".
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
+ @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
^ permalink raw reply related
* [PATCH] Define $PERL_PATH in test-lib.sh
From: Philippe Bruhat (BooK) @ 2009-11-10 10:46 UTC (permalink / raw)
To: git; +Cc: Philippe Bruhat (BooK)
The main Makefile defines PERL_PATH as the perl to use in the shebang
line of git*.perl commands. This ensures this will be the perl used
to run the tests (in case another perl appears in $PATH before the one
defined in $PERL_PATH)
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
---
t/t9400-git-cvsserver-server.sh | 2 +-
t/t9401-git-cvsserver-crlf.sh | 2 +-
t/t9700-perl-git.sh | 4 ++--
t/test-lib.sh | 2 ++
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 64f947d..dc710f8 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -20,7 +20,7 @@ then
say 'skipping git-cvsserver tests, cvs not found'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index aca40c1..c9e3dba 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -57,7 +57,7 @@ then
say 'skipping git-cvsserver tests, perl not available'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 4eb7d3f..3354e18 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -11,7 +11,7 @@ if ! test_have_prereq PERL; then
test_done
fi
-perl -MTest::More -e 0 2>/dev/null || {
+$PERL_PATH -MTest::More -e 0 2>/dev/null || {
say "Perl Test::More unavailable, skipping test"
test_done
}
@@ -48,6 +48,6 @@ test_expect_success \
test_external_without_stderr \
'Perl API' \
- perl "$TEST_DIRECTORY"/t9700/test.pl
+ $PERL_PATH "$TEST_DIRECTORY"/t9700/test.pl
test_done
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..54dd4d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -730,6 +730,8 @@ esac
test -z "$NO_PERL" && test_set_prereq PERL
+test -z "$NO_PERL" && test -z "$PERL_PATH" && export PERL_PATH=/usr/bin/perl
+
# test whether the filesystem supports symbolic links
ln -s x y 2>/dev/null && test -h y 2>/dev/null && test_set_prereq SYMLINKS
rm -f y
--
1.6.0.3.517.g759a
^ permalink raw reply related
* Be aware of cold
From: Susanna Barry @ 2009-11-10 11:06 UTC (permalink / raw)
To: git
Just imagine what you can do if you knew what your woman wants.
http://ievet.blackwent.com/
^ permalink raw reply
* [ANNOUNCE] Girocco hosting infrastructure v1.0
From: Petr Baudis @ 2009-11-10 10:40 UTC (permalink / raw)
To: git
Hello!
I would like to announce Girocco-1.0, the first stable release of
a universal Git project hosting infrastructure. You can get it at
http://repo.or.cz/w/girocco.git
You guessed right, Girocco is the software repo.or.cz runs at;
however, compared to the past, it's much cleaned up, cleanly packaged
for easy re-deployment and fully configurable, thanks to sponsorship
of Novartis and Novell. (Apologies for switching repo.or.cz to it and
releasing it one year later than it should've been done.)
Thus, you should be able to easily deploy a local Girocco instance
at your site and configure it to do only what you want. Girocco allows
both full push-based project hosting, or just mirroring and showing
existing projects (either local or remote) - i.e. you can also use it
just to collect scattered repositories of your developers and present
them all at single place. The push-based hosting offers currently two
models, chroot hosting and hooks-based permissions (for trusted
environments) - it should be easy to add other models.
This way, Girocco might present an interesting alternative to
Gitorious for people who prefer mirroring over full project hosting,
prefer then rawer gitweb interface ;-), like the repo.or.cz simple
forking model or want to make use of the GitHub-like flexible
commit notifications mechanism.
(If you are actually going to deploy Girocco somewhere, it's good to
tell me so that I can take it into account to e.g. provide upgrade paths
for future Girocco changes.)
If you are used to repo.or.cz, what's new in Girocco at the user's
end?
* Friendlier homepage.
* Friendlier project/user management interface.
* Friendlier mirror cloning process (you can see the progress in your
browser).
* Support for automatic Git mirroring of SVN repositories.
* Support for new-commit notifications, both for push and mirror
project modes:
* Get a notification to specified mail address(es)
* Get a notification by receiving a POST HTTP request with
GitHub-compatible JSON payload
* Have repo.or.cz send commit notifications to the CIA
service [http://cia.vc/]
* Much easier to contribute a change to Girocco if you are missing
any feature on repo.or.cz!
Well, have fun!
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH 6/8] builtin-fetch: add --prune option
From: Björn Gustavsson @ 2009-11-10 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpjag3as.fsf@alter.siamese.dyndns.org>
2009/11/10 Junio C Hamano <gitster@pobox.com>:
>> Yuck...
>>
>> builtin-fetch.c: In function 'prune_refs':
>> builtin-fetch.c:500: error: implicit declaration of function 'get_stale_heads'
>> builtin-fetch.c:500: error: initialization makes pointer from integer without a cast
>> builtin-fetch.c:501: error: 'dry_run' undeclared (first use in this function)
>> builtin-fetch.c:501: error: (Each undeclared identifier is reported only once
>> builtin-fetch.c:501: error: for each function it appears in.)
>> make: *** [builtin-fetch.o] Error 1
>
> Ah, I know. You forgot the first one from Jay's series.
>
Off-by-one error when I ran format-patch. Sorry for that.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH 6/8] builtin-fetch: add --prune option
From: Björn Gustavsson @ 2009-11-10 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx8mg3mw.fsf@alter.siamese.dyndns.org>
2009/11/10 Junio C Hamano <gitster@pobox.com>:
> Björn Gustavsson <bgustavsson@gmail.com> writes:
>
>> From: Jay Soffian <jaysoffian@gmail.com>
>
> Thanks for being careful; it would be even better if you preserve the
> author date by copying Date: from the original.
Thanks for the tip! Will do that next time.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Git P4 Submit issue
From: Arnaud Bailly @ 2009-11-10 8:22 UTC (permalink / raw)
To: git
Hello,
I have been using git-p4 happily to draw revisions from P4 to git repository. I
now want to do the converse operation. What I did is the following
p4 client mad-builder
# edit builder client view to have a local checkout
export P4CLIENT=mad-builder
# clone bare repository to work on it
git clone mad mad.p4
cd mad.p4
git p4 submit
fatal: Not a valid object name HEAD~57
Command failed: git cat-file commit HEAD~57
I do not really understand what's going there excepts that obviously some object
is referenced that does not exist.
Thank you for your help
Arnaud
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-10 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <28c656e20911091047r353e9451hd856b99541fbd5ff@mail.gmail.com>
B Smith-Mannschott <bsmith.occs <at> gmail.com> writes:
> You don't have to wait to comitting to your own branches, but do make
> sure to run your usual builds and tests before pushing or asking
> another to pull changes from you.
Perhaps, I was not clear in my questions.
I do not want to build and test to complete before I get back to my stashed
or commited changes. I.e. I need to have 2 working trees (perhaps different, but
from the same repository): one for build/test and one for another task.
Dmitry
^ permalink raw reply
* Re: [PATCH 6/8] builtin-fetch: add --prune option
From: Junio C Hamano @ 2009-11-10 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Gustavsson, git
In-Reply-To: <7vfx8mg3mw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Björn Gustavsson <bgustavsson@gmail.com> writes:
>
>> From: Jay Soffian <jaysoffian@gmail.com>
>
> Thanks for being careful; it would be even better if you preserve the
> author date by copying Date: from the original.
>
>> Teach fetch to cull stale remote tracking branches after fetching via --prune.
>>
>> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
>> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
>
> Yuck...
>
> builtin-fetch.c: In function 'prune_refs':
> builtin-fetch.c:500: error: implicit declaration of function 'get_stale_heads'
> builtin-fetch.c:500: error: initialization makes pointer from integer without a cast
> builtin-fetch.c:501: error: 'dry_run' undeclared (first use in this function)
> builtin-fetch.c:501: error: (Each undeclared identifier is reported only once
> builtin-fetch.c:501: error: for each function it appears in.)
> make: *** [builtin-fetch.o] Error 1
Ah, I know. You forgot the first one from Jay's series.
^ permalink raw reply
* Re: [PATCH 6/8] builtin-fetch: add --prune option
From: Junio C Hamano @ 2009-11-10 8:55 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, Junio C Hamano
In-Reply-To: <4AF92133.6070005@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> From: Jay Soffian <jaysoffian@gmail.com>
Thanks for being careful; it would be even better if you preserve the
author date by copying Date: from the original.
> Teach fetch to cull stale remote tracking branches after fetching via --prune.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Yuck...
builtin-fetch.c: In function 'prune_refs':
builtin-fetch.c:500: error: implicit declaration of function 'get_stale_heads'
builtin-fetch.c:500: error: initialization makes pointer from integer without a cast
builtin-fetch.c:501: error: 'dry_run' undeclared (first use in this function)
builtin-fetch.c:501: error: (Each undeclared identifier is reported only once
builtin-fetch.c:501: error: for each function it appears in.)
make: *** [builtin-fetch.o] Error 1
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-10 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <20091109210631.GJ27126@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov <at> gmail.com> writes:
> With many other VCS, a typical policy is that you do not commit your
> changes unless you have finished and tested them. But it means that
> your changes are not committed and stored only in the work tree for
> a long time. Moreover, when you eventually decide that they are good
> enough to commit, you will produce a huge patch, which will be difficult
> to review or to bisect history later.
oh, yes. but this is just a policy. You can make your changes on your
branch and commit them (for example, for review). Later someone just
need to integrate it on original branch. The same as with Git,
isn't it? The problem is just a price to branch.
BTW, once I started to talk about review, we can see that most
"benefits" of DVCS go away... Just because you still need some
central storage to save the record of this review that should
be available for SQA later...
> So, you can always commit your changes as your progress to your goal and
> review amend them later before publishing. This means that you can have
> as many work-in-progress branches as you wish, and you do not need a
> separate work tree for each of them -- everything can be stored in the
> repository, and you can go to another computer, issue 'git fetch' and
> continue your work at the exact point where you left it. So, it is very
> flexible.
As for me, I would not to have more than 4-5 such deferred changes in the same
repository. Otherwise, I will be entangled finally :-)
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-10 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <20091109183404.GI27126@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov <at> gmail.com> writes:
> Yes, but then I do not see any reason to do any time consuming building
> and testing in the working tree. I create a snapshot of the interesting
> version using 'git archive' and then run build&test on it... In this
> way, I can make sure that the archive I deliver is tested properly. If
> you do your testing in the working tree, sometimes uncommitted or some
> other files that are left over from previous builds may affect result.
> So, if it takes considerable time anyhow, why do not do clean build and
> test? And if you worry about compilation time, you can use ccache.
It is not clear for me. Yes, I have to get some fixed version to reproduce
the bug reported by someone. Then I need to fix it and commit the change
back (on the head). Also, it is obvious to reproduce the issue and
test the fix on the tip. Can do this with 'git archive'?
BTW, doesn't 'git archive' sync to some version that I probably already
have in other clone? ;-)
^ permalink raw reply
* Re: [PATCH v2 0/4] perf bench: Common option for specifying style formatting
From: Hitoshi Mitake @ 2009-11-10 8:23 UTC (permalink / raw)
To: mingo; +Cc: git, linux-kernel, a.p.zijlstra, paulus
In-Reply-To: <20091110080135.GA32322@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v2 0/4] perf bench: Common option for specifying style formatting
Date: Tue, 10 Nov 2009 09:01:35 +0100
>
> * Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:
>
> > And I have a question.
> > In tools/perf/command-list.txt, there is the word "mainporcelain".
> > What does this mean?
>
> tools/perf/ inherited the command-list.txt code from the Git project:
>
> git://git.kernel.org/pub/scm/git/git.git
>
> in Git talk, 'porcelain' is the pretty stuff humans use. 'plumbing' is
> the lowlevel stuff humans dont get to see.
>
> 'mainporcelain' are the major commands you get listed when you type
> 'perf' (or 'git').
Thanks, I got it!
>
> ( i've Cc:-ed the Git list as i never saw any real formal definition for
> this anywhere, maybe i got this wrong :-)
>
> > Of course I searched this word on my dictionary, but cannot got an answer.
> > I'm preparing the initial document for perf-bench.
> > Can I add perf-bench with mainporcelain to command-list.txt?
>
> yeah, i'd suggest to do that - that will make 'perf bench' show up in
> 'perf' output.
I'll describe perf bench as mainporcelain command, thanks.
^ permalink raw reply
* [PATCH 8/8] Re-implement 'git remote update' using 'git fetch'
From: Björn Gustavsson @ 2009-11-10 8:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In order not to duplicate functionality, re-implement 'git remote
update' in terms of 'git fetch'.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
The --prune option will be passed on, as 'git fetch' now
supports it.
builtin-remote.c | 88 +++++++++++++++++------------------------------------
1 files changed, 28 insertions(+), 60 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 56cd5af..fb0d66d 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -1173,88 +1173,56 @@ static int prune_remote(const char *remote, int dry_run)
return result;
}
-static int get_one_remote_for_update(struct remote *remote, void *priv)
+static int get_remote_default(const char *key, const char *value, void *priv)
{
- struct string_list *list = priv;
- if (!remote->skip_default_update)
- string_list_append(remote->name, list);
- return 0;
-}
-
-static struct remote_group {
- const char *name;
- struct string_list *list;
-} remote_group;
-
-static int get_remote_group(const char *key, const char *value, void *num_hits)
-{
- if (!prefixcmp(key, "remotes.") &&
- !strcmp(key + 8, remote_group.name)) {
- /* split list by white space */
- int space = strcspn(value, " \t\n");
- while (*value) {
- if (space > 1) {
- string_list_append(xstrndup(value, space),
- remote_group.list);
- ++*((int *)num_hits);
- }
- value += space + (value[space] != '\0');
- space = strcspn(value, " \t\n");
- }
+ if (strcmp(key, "remotes.default") == 0) {
+ int *found = priv;
+ *found = 1;
}
-
return 0;
}
static int update(int argc, const char **argv)
{
- int i, result = 0, prune = 0;
- struct string_list list = { NULL, 0, 0, 0 };
- static const char *default_argv[] = { NULL, "default", NULL };
+ int i, prune = 0;
struct option options[] = {
OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
+ const char **fetch_argv;
+ int fetch_argc = 0;
+ int default_defined = 0;
+
+ fetch_argv = xmalloc(sizeof(char *) * (argc+5));
argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
PARSE_OPT_KEEP_ARGV0);
- if (argc < 2) {
- argc = 2;
- argv = default_argv;
- }
- remote_group.list = &list;
- for (i = 1; i < argc; i++) {
- int groups_found = 0;
- remote_group.name = argv[i];
- result = git_config(get_remote_group, &groups_found);
- if (!groups_found && (i != 1 || strcmp(argv[1], "default"))) {
- struct remote *remote;
- if (!remote_is_configured(argv[i]))
- die("No such remote or remote group: %s",
- argv[i]);
- remote = remote_get(argv[i]);
- string_list_append(remote->name, remote_group.list);
- }
- }
+ fetch_argv[fetch_argc++] = "fetch";
- if (!result && !list.nr && argc == 2 && !strcmp(argv[1], "default"))
- result = for_each_remote(get_one_remote_for_update, &list);
+ if (prune)
+ fetch_argv[fetch_argc++] = "--prune";
+ if (verbose)
+ fetch_argv[fetch_argc++] = "-v";
+ if (argc < 2) {
+ fetch_argv[fetch_argc++] = "default";
+ } else {
+ fetch_argv[fetch_argc++] = "--multiple";
+ for (i = 1; i < argc; i++)
+ fetch_argv[fetch_argc++] = argv[i];
+ }
- for (i = 0; i < list.nr; i++) {
- int err = fetch_remote(list.items[i].string);
- result |= err;
- if (!err && prune)
- result |= prune_remote(list.items[i].string, 0);
+ if (strcmp(fetch_argv[fetch_argc-1], "default") == 0) {
+ git_config(get_remote_default, &default_defined);
+ if (!default_defined)
+ fetch_argv[fetch_argc-1] = "--all";
}
- /* all names were strdup()ed or strndup()ed */
- list.strdup_strings = 1;
- string_list_clear(&list, 0);
+ fetch_argv[fetch_argc] = NULL;
- return result;
+ return run_command_v_opt(fetch_argv, RUN_GIT_CMD);
}
static int get_one_entry(struct remote *remote, void *priv)
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 7/8] builtin-fetch: add --dry-run option
From: Björn Gustavsson @ 2009-11-10 8:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Jay Soffian <jaysoffian@gmail.com>
Teach fetch --dry-run as users of "git remote prune" switching to "git fetch
--prune" may expect it. Unfortunately OPT__DRY_RUN() cannot be used as fetch
already uses "-n" for something else.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
I have removed the changes to builtin_remote.c and
the test case and also removed mentioning of those
changes in the commit message.
Documentation/fetch-options.txt | 5 +++++
builtin-fetch.c | 14 ++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 500637a..ab6419f 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -12,6 +12,11 @@
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
by the specified number of commits.
+ifndef::git-pull[]
+--dry-run::
+ Show what would be done, without making any changes.
+endif::git-pull[]
+
-f::
--force::
When 'git-fetch' is used with `<rbranch>:<lbranch>`
diff --git a/builtin-fetch.c b/builtin-fetch.c
index fd31072..8082d36 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -26,7 +26,7 @@ enum {
TAGS_SET = 2
};
-static int all, append, force, keep, multiple, prune, update_head_ok, verbosity;
+static int all, append, dry_run, force, keep, multiple, prune, update_head_ok, verbosity;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
@@ -51,6 +51,8 @@ static struct option builtin_fetch_options[] = {
"do not fetch all tags (--no-tags)", TAGS_UNSET),
OPT_BOOLEAN('p', "prune", &prune,
"prune tracking branches no longer on remote"),
+ OPT_BOOLEAN(0, "dry-run", &dry_run,
+ "dry run"),
OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"),
OPT_BOOLEAN('u', "update-head-ok", &update_head_ok,
"allow updating of HEAD ref"),
@@ -187,6 +189,8 @@ static int s_update_ref(const char *action,
char *rla = getenv("GIT_REFLOG_ACTION");
static struct ref_lock *lock;
+ if (dry_run)
+ return 0;
if (!rla)
rla = default_rla.buf;
snprintf(msg, sizeof(msg), "%s: %s", rla, action);
@@ -312,7 +316,7 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
char note[1024];
const char *what, *kind;
struct ref *rm;
- char *url, *filename = git_path("FETCH_HEAD");
+ char *url, *filename = dry_run ? "/dev/null" : git_path("FETCH_HEAD");
fp = fopen(filename, "a");
if (!fp)
@@ -658,7 +662,7 @@ static int do_fetch(struct transport *transport,
die("Don't know how to fetch from %s", transport->url);
/* if not appending, truncate FETCH_HEAD */
- if (!append) {
+ if (!append && !dry_run) {
char *filename = git_path("FETCH_HEAD");
FILE *fp = fopen(filename, "w");
if (!fp)
@@ -766,9 +770,11 @@ static int add_remote_or_group(const char *name, struct string_list *list)
static int fetch_multiple(struct string_list *list)
{
int i, result = 0;
- const char *argv[] = { "fetch", NULL, NULL, NULL, NULL, NULL };
+ const char *argv[] = { "fetch", NULL, NULL, NULL, NULL, NULL, NULL };
int argc = 1;
+ if (dry_run)
+ argv[argc++] = "--dry-run";
if (prune)
argv[argc++] = "--prune";
if (verbosity >= 2)
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 6/8] builtin-fetch: add --prune option
From: Björn Gustavsson @ 2009-11-10 8:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Jay Soffian <jaysoffian@gmail.com>
Teach fetch to cull stale remote tracking branches after fetching via --prune.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/fetch-options.txt | 4 ++++
builtin-fetch.c | 32 ++++++++++++++++++++++++++++++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 8b0cf58..500637a 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -28,6 +28,10 @@ ifndef::git-pull[]
--multiple::
Allow several <repository> and <group> arguments to be
specified. No <refspec>s may be specified.
+
+--prune::
+ After fetching, remove any remote tracking branches which
+ no longer exist on the remote.
endif::git-pull[]
ifdef::git-pull[]
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 945dfd8..fd31072 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -26,7 +26,7 @@ enum {
TAGS_SET = 2
};
-static int all, append, force, keep, multiple, update_head_ok, verbosity;
+static int all, append, force, keep, multiple, prune, update_head_ok, verbosity;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
@@ -49,6 +49,8 @@ static struct option builtin_fetch_options[] = {
"fetch all tags and associated objects", TAGS_SET),
OPT_SET_INT('n', NULL, &tags,
"do not fetch all tags (--no-tags)", TAGS_UNSET),
+ OPT_BOOLEAN('p', "prune", &prune,
+ "prune tracking branches no longer on remote"),
OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"),
OPT_BOOLEAN('u', "update-head-ok", &update_head_ok,
"allow updating of HEAD ref"),
@@ -492,6 +494,28 @@ static int fetch_refs(struct transport *transport, struct ref *ref_map)
return ret;
}
+static int prune_refs(struct transport *transport, struct ref *ref_map)
+{
+ int result = 0;
+ struct ref *ref, *stale_refs = get_stale_heads(transport->remote, ref_map);
+ const char *dangling_msg = dry_run
+ ? " (%s will become dangling)\n"
+ : " (%s has become dangling)\n";
+
+ for (ref = stale_refs; ref; ref = ref->next) {
+ if (!dry_run)
+ result |= delete_ref(ref->name, NULL, 0);
+ if (verbosity >= 0) {
+ fprintf(stderr, " x %-*s %-*s -> %s\n",
+ SUMMARY_WIDTH, "[deleted]",
+ REFCOL_WIDTH, "(none)", prettify_refname(ref->name));
+ warn_dangling_symref(stderr, dangling_msg, ref->name);
+ }
+ }
+ free_refs(stale_refs);
+ return result;
+}
+
static int add_existing(const char *refname, const unsigned char *sha1,
int flag, void *cbdata)
{
@@ -657,6 +681,8 @@ static int do_fetch(struct transport *transport,
free_refs(ref_map);
return 1;
}
+ if (prune)
+ prune_refs(transport, ref_map);
free_refs(ref_map);
/* if neither --no-tags nor --tags was specified, do automated tag
@@ -740,9 +766,11 @@ static int add_remote_or_group(const char *name, struct string_list *list)
static int fetch_multiple(struct string_list *list)
{
int i, result = 0;
- const char *argv[] = { "fetch", NULL, NULL, NULL, NULL };
+ const char *argv[] = { "fetch", NULL, NULL, NULL, NULL, NULL };
int argc = 1;
+ if (prune)
+ argv[argc++] = "--prune";
if (verbosity >= 2)
argv[argc++] = "-v";
if (verbosity >= 1)
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 5/8] teach warn_dangling_symref to take a FILE argument
From: Björn Gustavsson @ 2009-11-10 8:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Jay Soffian <jaysoffian@gmail.com>
Different callers of warn_dangling_symref() may want to control whether its
output goes to stdout or stderr so let it take a FILE argument.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
builtin-remote.c | 2 +-
refs.c | 7 ++++---
refs.h | 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index b48267b..56cd5af 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -1166,7 +1166,7 @@ static int prune_remote(const char *remote, int dry_run)
printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
abbrev_ref(refname, "refs/remotes/"));
- warn_dangling_symref(dangling_msg, refname);
+ warn_dangling_symref(stdout, dangling_msg, refname);
}
free_remote_ref_states(&states);
diff --git a/refs.c b/refs.c
index 808f56b..3e73a0a 100644
--- a/refs.c
+++ b/refs.c
@@ -286,6 +286,7 @@ static struct ref_list *get_ref_dir(const char *base, struct ref_list *list)
}
struct warn_if_dangling_data {
+ FILE *fp;
const char *refname;
const char *msg_fmt;
};
@@ -304,13 +305,13 @@ static int warn_if_dangling_symref(const char *refname, const unsigned char *sha
if (!resolves_to || strcmp(resolves_to, d->refname))
return 0;
- printf(d->msg_fmt, refname);
+ fprintf(d->fp, d->msg_fmt, refname);
return 0;
}
-void warn_dangling_symref(const char *msg_fmt, const char *refname)
+void warn_dangling_symref(FILE *fp, const char *msg_fmt, const char *refname)
{
- struct warn_if_dangling_data data = { refname, msg_fmt };
+ struct warn_if_dangling_data data = { fp, refname, msg_fmt };
for_each_rawref(warn_if_dangling_symref, &data);
}
diff --git a/refs.h b/refs.h
index 777b5b7..e141991 100644
--- a/refs.h
+++ b/refs.h
@@ -29,7 +29,7 @@ extern int for_each_replace_ref(each_ref_fn, void *);
/* can be used to learn about broken ref and symref */
extern int for_each_rawref(each_ref_fn, void *);
-extern void warn_dangling_symref(const char *msg_fmt, const char *refname);
+extern void warn_dangling_symref(FILE *fp, const char *msg_fmt, const char *refname);
/*
* Extra refs will be listed by for_each_ref() before any actual refs
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 0/8] Fetch improvements and re-implementation of remote update
From: Björn Gustavsson @ 2009-11-10 8:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
To avoid having a commit where 'git remote update --prune' is broken
(except for cleanliness reasons, it would cause problems if someone
wants to bisect a breakage in that functionality), I have made
a slight change to one of Jay's patches and put my patch that
re-implements 'git remote update' last in the series.
Following this email, there will be series of patches starting
with number 5 and ending in number 8.
It can be applied directly on top of my fourth patch I sent out
yesterday ("Add missing test for 'git remote update --prune'").
The fifth patch in that series should be discarded.
Björn Gustavsson (1):
Re-implement 'git remote update' using 'git fetch'
Jay Soffian (3):
teach warn_dangling_symref to take a FILE argument
builtin-fetch: add --prune option
builtin-fetch: add --dry-run option
Documentation/fetch-options.txt | 9 ++++
builtin-fetch.c | 42 ++++++++++++++++--
builtin-remote.c | 90 ++++++++++++--------------------------
refs.c | 7 ++-
refs.h | 2 +-
5 files changed, 81 insertions(+), 69 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/4] perf bench: Common option for specifying style formatting
From: Ingo Molnar @ 2009-11-10 8:01 UTC (permalink / raw)
To: Hitoshi Mitake, git; +Cc: linux-kernel, a.p.zijlstra, paulus
In-Reply-To: <20091110.165102.386189748263321818.mitake@dcl.info.waseda.ac.jp>
* Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:
> And I have a question.
> In tools/perf/command-list.txt, there is the word "mainporcelain".
> What does this mean?
tools/perf/ inherited the command-list.txt code from the Git project:
git://git.kernel.org/pub/scm/git/git.git
in Git talk, 'porcelain' is the pretty stuff humans use. 'plumbing' is
the lowlevel stuff humans dont get to see.
'mainporcelain' are the major commands you get listed when you type
'perf' (or 'git').
( i've Cc:-ed the Git list as i never saw any real formal definition for
this anywhere, maybe i got this wrong :-)
> Of course I searched this word on my dictionary, but cannot got an answer.
> I'm preparing the initial document for perf-bench.
> Can I add perf-bench with mainporcelain to command-list.txt?
yeah, i'd suggest to do that - that will make 'perf bench' show up in
'perf' output.
Ingo
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Peter Zijlstra @ 2009-11-10 7:32 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, Junio C Hamano
In-Reply-To: <20091110040847.GC29454@elte.hu>
On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
> (moved from lkml to the Git list)
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > > Mailer:
> > > git-send-email 1.6.5.2
> >
> > Please teach your git-send-email thing to use --no-chain-reply-to.
>
> about half of every patch series that gets sent to me on lkml is
> unreadable in my email client due to the default threading that
> git-send-email does. It looks like this:
>
> 28685 r T Nov 05 Hitoshi Mitake ( 31) [PATCH v5 0/7] Adding general performance benchmarki
> 28686 T Nov 05 Hitoshi Mitake ( 31) +->[PATCH v5 1/7] Adding new directory and header fo
> 28687 T Nov 05 Hitoshi Mitake ( 368) | +->[PATCH v5 2/7] sched-messaging.c: benchmark for
> 28688 T Nov 05 Hitoshi Mitake ( 148) | | +->[PATCH v5 3/7] sched-pipe.c: benchmark for pi
> 28689 T Nov 05 Hitoshi Mitake ( 149) | | | +->[PATCH v5 4/7] builtin-bench.c: General fra
> 28690 T Nov 05 Hitoshi Mitake ( 24) | | | | +->[PATCH v5 5/7] Modifying builtin.h for ne
> 28691 T Nov 05 Hitoshi Mitake ( 25) | | | | | +->[PATCH v5 6/7] Modyfing perf.c for subc
> 28692 T Nov 05 Hitoshi Mitake ( 30) | | | | | | +->[PATCH v5 7/7] Modyfing Makefile to b
Do what I do and flame the sender and have them repost.
I simply won't even attempt to read crap send like that.
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Ingo Molnar @ 2009-11-10 7:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Zijlstra, git
In-Reply-To: <7v4op3gd6f.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> [Footnote]
>
> *1* To spell it out... The people who are in the "hate chain-reply-to
> very much" camp would have already done their own configuration to get
> the behaviour they want by now, so changing the default would not help
> them much, while potentially hurting "love chain-reply-to" people who
> have been content because they got what they wanted without setting
> any configuration.
Stupid question: i researched the Git mailing list archive (and read the
link you provided) and found no arguments (at all) in favor of the
nested chaining. Are you aware of any?
And i dont 'hate' it - i am just the one suffering from it as a
maintainer. _I_ can certainly fix my scripts as you suggest above, but
that is not my problem: my problem are the many people sending
first-time Git based patch series to me (and there's quite a few of
them) always, in every single case, get it wrong.
The ones not using Git (using Quilt for example) and sending me series
get it right in pretty much every case.
So i can see it when developers start using Git to submit patches - in
each and every case - the discussion threading is all messed up ;-)
These people dont 'do their own configuration' - they are mostly newbies
or developrs new to Git workflows. And the first reaction they get from
their upstream maintainer counterpart is some grumbling about the
threading. Not good, me thinks ;-)
Ingo
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Junio C Hamano @ 2009-11-10 6:05 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jay Soffian, Peter Zijlstra, git
In-Reply-To: <20091110052211.GK7897@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> +1 for putting it into a .1.6.x stable branch too. (Unless there's a
> case where the recursive threading is actually useful and is being
> relied on.)
As I wrote in the LKML message when that patch was made (please see my
other message for the URL to the archive), my assessment of this issue is
that it would have been the right thing to do if we were doing this now
without any existing users, but nobody really cares deeply enough either
way to warrant fast tracking the schedule we promised back in August.
It would take a bit stronger nudging than "unless there is a case against
changing the default because it is being relied on", as I know that people
who rely on would not speak up for a long time. We already saw that it
took 6 month between Feb 2009 to Aug 2009 for people who wanted to change
the default to notice and complain that the change they were promised did
not happen ;-).
Some people will complain when we switch the default to no-chain-reply-to
in the 1.7.0 release. I am willing to take flak from them and defend the
change.
But I am not convinced that this deserves to be fast-tracked to the 1.6.x
series. We gave them until 1.7.0 and I have no good answer to "why didn't
you wait as you promised?" I'd rather avoid telling them that "that is
how kernel people wanted it, and sorry, their wish trumps yours." if I
can.
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Junio C Hamano @ 2009-11-10 5:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Peter Zijlstra, git, Junio C Hamano
In-Reply-To: <20091110040847.GC29454@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> (moved from lkml to the Git list)
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
>> > Mailer:
>> > git-send-email 1.6.5.2
>>
>> Please teach your git-send-email thing to use --no-chain-reply-to.
> ...
> So ... the question would be ... could git-send-email flip its default
> please, via the patch below? Am i missing something subtle about why
> this default was chosen?
I do not think there was any conscious decision made when the
chain-reply-to was added. It was done and it got stuck.
I think the _only_ argument anybody _could_ make (and I won't be making
it, as I'd rather wish we had no-chain-reply-to the default from day one)
against the change of default is that it is a change [*1*].
Lkml already had two rather heated discussion in the past,
After the first round, I said we'd change the default to no-chain-reply-to
in release 1.6.3 unless somebody makes a convincing argument why the
default should not change, back around the time we were preparing for
1.6.2 (February 2009).
http://thread.gmane.org/gmane.comp.version-control.git/109790
Nobody complained.
Then I forgot to make such a declaration in the release notes to 1.6.3,
and no such declaration appeard in later release notes, either.
But nobody complained (nor reminded me).
The second round of the discussion was in August 2009. This time I did
something to prevent me from forgetting in the future.
http://thread.gmane.org/gmane.linux.kernel/879975/focus=880938
This patch is queued in 'next', scheduled to graduate to 'master' for the
1.7.0 release.
[Footnote]
*1* To spell it out... The people who are in the "hate chain-reply-to
very much" camp would have already done their own configuration to get the
behaviour they want by now, so changing the default would not help them
much, while potentially hurting "love chain-reply-to" people who have been
content because they got what they wanted without setting any
configuration.
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Ingo Molnar @ 2009-11-10 5:22 UTC (permalink / raw)
To: Jay Soffian; +Cc: Peter Zijlstra, git, Junio C Hamano
In-Reply-To: <76718490911092112v4d1e7761ue98def756ed0d93b@mail.gmail.com>
* Jay Soffian <jaysoffian@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > So ... the question would be ... could git-send-email flip its default
>
> This is already in next for 1.7.0. See 41fe87f.
>
> >From Junio's What's Cooking messages:
>
> * jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
> (merged to 'next' on 2009-08-22 at 5106de8)
Ah, awesome!
+1 for putting it into a .1.6.x stable branch too. (Unless there's a
case where the recursive threading is actually useful and is being
relied on.)
Ingo
^ permalink raw reply
* Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default
From: Jay Soffian @ 2009-11-10 5:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Peter Zijlstra, git, Junio C Hamano
In-Reply-To: <20091110040847.GC29454@elte.hu>
On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar <mingo@elte.hu> wrote:
> So ... the question would be ... could git-send-email flip its default
This is already in next for 1.7.0. See 41fe87f.
>From Junio's What's Cooking messages:
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
> Am i missing something subtle about why this default was chosen?
I'm not sure it was chosen so much as it was just the way the cookie crumbled.
j.
^ 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