* [PATCH] fix shell command line in example
From: Joey Hess @ 2011-12-23 16:41 UTC (permalink / raw)
To: git
The comma was probably intended to be a semicolon so that the
two commands can be run by cut-n-paste.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
Documentation/git-pull.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 0f18ec8..628695d 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -194,7 +194,7 @@ EXAMPLES
current branch:
+
------------------------------------------------
-$ git pull, git pull origin
+$ git pull; git pull origin
------------------------------------------------
+
Normally the branch merged in is the HEAD of the remote repository,
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] fix shell command line in example
From: Thomas Rast @ 2011-12-23 16:56 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20111223164128.GA21918@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> The comma was probably intended to be a semicolon so that the
> two commands can be run by cut-n-paste.
[...]
> ------------------------------------------------
> -$ git pull, git pull origin
> +$ git pull; git pull origin
> ------------------------------------------------
Would it ever make sense to run the two in sequence?
But upon closer reading, it seems to be a pretty terrible example
anyway. It reads:
* Update the remote-tracking branches for the repository
you cloned from, then merge one of them into your
current branch:
+
------------------------------------------------
$ git pull, git pull origin
------------------------------------------------
+
Normally the branch merged in is the HEAD of the remote repository,
but the choice is determined by the branch.<name>.remote and
branch.<name>.merge options; see linkgit:git-config[1] for details.
But that "normally" is no longer true: with default configs, the user
would only ever have branches with tracking already set up. So
*normally*, 'git pull' will merge the @{upstream}.
'git pull origin' is even worse: with tracking configured, it goes out
of its way to verify that the specified remote (origin) is actually what
HEAD tracks[*]. So 'git pull origin' with default configs means "please
pull, but double-check me on the choice of remote". Do we want to give
that to a user as the second example?
So I'm thinking it should just read
* Update the upstream origin of the current branch, then merge the
tracked branch into the current one:
+
--------------------------------------------------
$ git pull
--------------------------------------------------
modulo avoiding confusion around upstream/tracking.
[*] a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) has a long explanation on the subject.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Remove Git's support for smoke testing
From: Ævar Arnfjörð Bjarmason @ 2011-12-23 17:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
I'm no longer running the Git smoke testing service at
smoke.git.nix.is due to Smolder being a fragile piece of software not
having time to follow through on making it easy for third parties to
run and submit their own smoke tests.
So remove the support in Git for sending smoke tests to
smoke.git.nix.is, it's still easy to modify the test suite to submit
smokes somewhere else.
This reverts the following commits:
Revert "t/README: Add SMOKE_{COMMENT,TAGS}= to smoke_report target" -- e38efac87d
Revert "t/README: Document the Smoke testing" -- d15e9ebc5c
Revert "t/Makefile: Create test-results dir for smoke target" -- 617344d77b
Revert "tests: Infrastructure for Git smoke testing" -- b6b84d1b74
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/Makefile | 40 +--------------------------------
t/README | 73 ------------------------------------------------------------
t/harness | 21 -----------------
3 files changed, 1 insertions(+), 133 deletions(-)
delete mode 100755 t/harness
diff --git a/t/Makefile b/t/Makefile
index 9046ec9..52a23ff 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -73,42 +73,4 @@ gitweb-test:
valgrind:
$(MAKE) GIT_TEST_OPTS="$(GIT_TEST_OPTS) --valgrind"
-# Smoke testing targets
--include ../GIT-VERSION-FILE
-uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo unknown')
-uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo unknown')
-
-test-results:
- mkdir -p test-results
-
-test-results/git-smoke.tar.gz: test-results
- $(PERL_PATH) ./harness \
- --archive="test-results/git-smoke.tar.gz" \
- $(T)
-
-smoke: test-results/git-smoke.tar.gz
-
-SMOKE_UPLOAD_FLAGS =
-ifdef SMOKE_USERNAME
- SMOKE_UPLOAD_FLAGS += -F username="$(SMOKE_USERNAME)" -F password="$(SMOKE_PASSWORD)"
-endif
-ifdef SMOKE_COMMENT
- SMOKE_UPLOAD_FLAGS += -F comments="$(SMOKE_COMMENT)"
-endif
-ifdef SMOKE_TAGS
- SMOKE_UPLOAD_FLAGS += -F tags="$(SMOKE_TAGS)"
-endif
-
-smoke_report: smoke
- curl \
- -H "Expect: " \
- -F project=Git \
- -F architecture="$(uname_M)" \
- -F platform="$(uname_S)" \
- -F revision="$(GIT_VERSION)" \
- -F report_file=@test-results/git-smoke.tar.gz \
- $(SMOKE_UPLOAD_FLAGS) \
- http://smoke.git.nix.is/app/projects/process_add_report/1 \
- | grep -v ^Redirecting
-
-.PHONY: pre-clean $(T) aggregate-results clean valgrind smoke smoke_report
+.PHONY: pre-clean $(T) aggregate-results clean valgrind
diff --git a/t/README b/t/README
index c85abaf..681e8b4 100644
--- a/t/README
+++ b/t/README
@@ -658,76 +658,3 @@ Then, at the top-level:
That'll generate a detailed cover report in the "cover_db_html"
directory, which you can then copy to a webserver, or inspect locally
in a browser.
-
-Smoke testing
--------------
-
-The Git test suite has support for smoke testing. Smoke testing is
-when you submit the results of a test run to a central server for
-analysis and aggregation.
-
-Running a smoke tester is an easy and valuable way of contributing to
-Git development, particularly if you have access to an uncommon OS on
-obscure hardware.
-
-After building Git you can generate a smoke report like this in the
-"t" directory:
-
- make clean smoke
-
-You can also pass arguments via the environment. This should make it
-faster:
-
- GIT_TEST_OPTS='--root=/dev/shm' TEST_JOBS=10 make clean smoke
-
-The "smoke" target will run the Git test suite with Perl's
-"TAP::Harness" module, and package up the results in a .tar.gz archive
-with "TAP::Harness::Archive". The former is included with Perl v5.10.1
-or later, but you'll need to install the latter from the CPAN. See the
-"Test coverage" section above for how you might do that.
-
-Once the "smoke" target finishes you'll see a message like this:
-
- TAP Archive created at <path to git>/t/test-results/git-smoke.tar.gz
-
-To upload the smoke report you need to have curl(1) installed, then
-do:
-
- make smoke_report
-
-To upload the report anonymously. Hopefully that'll return something
-like "Reported #7 added.".
-
-If you're going to be uploading reports frequently please request a
-user account by E-Mailing gitsmoke@v.nix.is. Once you have a username
-and password you'll be able to do:
-
- SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> make smoke_report
-
-You can also add an additional comment to attach to the report, and/or
-a comma separated list of tags:
-
- SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> \
- SMOKE_COMMENT=<comment> SMOKE_TAGS=<tags> \
- make smoke_report
-
-Once the report is uploaded it'll be made available at
-http://smoke.git.nix.is, here's an overview of Recent Smoke Reports
-for Git:
-
- http://smoke.git.nix.is/app/projects/smoke_reports/1
-
-The reports will also be mirrored to GitHub every few hours:
-
- http://github.com/gitsmoke/smoke-reports
-
-The Smolder SQLite database is also mirrored and made available for
-download:
-
- http://github.com/gitsmoke/smoke-database
-
-Note that the database includes hashed (with crypt()) user passwords
-and E-Mail addresses. Don't use a valuable password for the smoke
-service if you have an account, or an E-Mail address you don't want to
-be publicly known. The user accounts are just meant to be convenient
-labels, they're not meant to be secure.
diff --git a/t/harness b/t/harness
deleted file mode 100755
index f5c02f4..0000000
--- a/t/harness
+++ /dev/null
@@ -1,21 +0,0 @@
-#!/usr/bin/perl
-use strict;
-use warnings;
-use Getopt::Long ();
-use TAP::Harness::Archive;
-
-Getopt::Long::Parser->new(
- config => [ qw/ pass_through / ],
-)->getoptions(
- 'jobs:1' => \(my $jobs = $ENV{TEST_JOBS}),
- 'archive=s' => \my $archive,
-) or die "$0: Couldn't getoptions()";
-
-TAP::Harness::Archive->new({
- jobs => $jobs,
- archive => $archive,
- ($ENV{GIT_TEST_OPTS}
- ? (test_args => [ split /\s+/, $ENV{GIT_TEST_OPTS} ])
- : ()),
- extra_properties => {},
-})->runtests(@ARGV);
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] fix shell command line in example
From: Joey Hess @ 2011-12-23 17:33 UTC (permalink / raw)
To: git
In-Reply-To: <8739cbi5v3.fsf@thomas.inf.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
Thomas Rast wrote:
> * Update the upstream origin of the current branch, then merge the
> tracked branch into the current one:
> +
> --------------------------------------------------
> $ git pull
> --------------------------------------------------
>
> modulo avoiding confusion around upstream/tracking.
I support having a simple "git pull" example; I think it's the first
thing users should be reaching for, followed perhaps by "git pull foo bar"
when they have multiple remotes.
Still, an example of pulling all tracking branches from a remote and
merging in the right one for the currently checked out branch would be
good to have, that's also a common need when using git without a
centralized origin. AFAICS, there's no way to do all that in a single
git pull command? My feeling was that this sort of scenario was what
the example was trying to do (rather badly).
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Dirk Süsserott @ 2011-12-23 18:54 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Git Mailing List
In-Reply-To: <874nwslayi.fsf@fox.patthoyts.tk>
Am 22.12.2011 19:26 schrieb Pat Thoyts:
> Dirk Süsserott <newsletter@dirk.my1.cc> writes:
>
>> Hi!
>>
>> Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
>>
>> I often use cmdline and gitk at the same time, switch branches, stash,
>> rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
>> highlighted commit is focused again and my HEAD is far off the screen.
>>
>> Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
>> fingertip?
>>
>> TIA
>> Dirk
>
> Hit the Home key. The binding for that takes you to the first commit.
> End to the last (oldest) commit.
Hi Pat,
thank you, but I almost always run gitk with the '--all' parameter.
Actually, I have a function in my .bashrc for this:
# calls gitk from the top-level directory:
function gkup()
{
(cd "./$(git rev-parse --show-cdup)"; gitk --all "$@" &)
}
That's because gitk behaves odd (at least to me) when not run from the
top-level directory. E.g. the "touching paths" box won't find files in
the top dir if you don't prefix them with a slash. It's all relative to
the directory gitk was started in. To get predictable behavior, I wrote
this function and garnished it with '--all'.
Thus, my current HEAD is not always on the top of the history but
somewhere in between. However, typing "HEAD" (or "head" in the SHA1
field works for me.
Cheers
Dirk
^ permalink raw reply
* Re: "Nested quantifiers" error in gitweb with "++" in the filename
From: Jehan Bing @ 2011-12-23 19:37 UTC (permalink / raw)
To: git
In-Reply-To: <CANgJU+VA9s9t0c8D0P_DesbSDQRBQ6v913KixKQAuiy8jZsdzQ@mail.gmail.com>
On 2011-12-23 08:02, demerphq wrote:
> On 22 December 2011 21:37, Jehan Bing<jehan@orb.com> wrote:
>> Hi,
>>
>> I'm getting an error when trying to look at a blob when the filename has
>> "++" in it:
>>
>> http://.../blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++.txt
>
> This error comes because the filename is being used a pattern without
> being protected by a quotemeta.
>
> Interestingly, a later version of perl would not have this problem as
> ++ is a legal quantifier as of 5.10, nevertheless it probably wouldnt
> do what you expected.
>
Interestingly, a later version of perl would not have this problem as,
after investigating the problem further, it's actually a bug in CGI.pm
which has since been fixed ;)
My distribution comes with an old version of CGI.pm (3.15 from perl
5.8.8). After updating to the latest, the problem went away.
^ permalink raw reply
* [RFC PATCH] Allow cloning branches selectively
From: Carlos Martín Nieto @ 2011-12-23 20:13 UTC (permalink / raw)
To: git
Sometimes it's useful to clone only a subset of branches from a remote
we're cloning. Teach clone the --fetch option to select which branches
should get fetched.
Each --fetch sets up a fetch refspec for that branch. Previously this
was only possible by initializing a repo and manually setting up the
config.
---
This is still a WIP, as clone will still always fetch and checkout the
remote's HEAD, which leaves you with a detached HEAD if you didn't
want that branch, which is clearly a bug.
Otherwise it works as expected. A better name for this feature would
also be nice, as in git you don't clone branches but repos. Maybe
something like "selectively fetch branches on clone"? If there isn't
an outcry against this I'll add --fetch to the manpage as well.
cmn
builtin/clone.c | 82 ++++++++++++++++++++++++++++++++++------------
t/t5702-clone-options.sh | 22 +++++++++++--
2 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 86db954..f14ca2a 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -48,6 +48,17 @@ static int option_verbosity;
static int option_progress;
static struct string_list option_config;
static struct string_list option_reference;
+static struct string_list option_fetch;
+static const char **refspecs;
+static int refspecs_nr;
+static int refspecs_alloc;
+
+static void add_refspec(const char *ref)
+{
+ refspecs_nr++;
+ ALLOC_GROW(refspecs, refspecs_nr, refspecs_alloc);
+ refspecs[refspecs_nr-1] = ref;
+}
static int opt_parse_reference(const struct option *opt, const char *arg, int unset)
{
@@ -88,6 +99,8 @@ static struct option builtin_clone_options[] = {
"use <name> instead of 'origin' to track upstream"),
OPT_STRING('b', "branch", &option_branch, "branch",
"checkout <branch> instead of the remote's HEAD"),
+ OPT_STRING_LIST(0, "fetch", &option_fetch, "refspec",
+ "fetch <refspec> instead of all the branches"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -421,13 +434,16 @@ static void remove_junk_on_signal(int signo)
}
static struct ref *wanted_peer_refs(const struct ref *refs,
- struct refspec *refspec)
+ struct refspec *refspec, int refspec_nr)
{
struct ref *head = copy_ref(find_ref_by_name(refs, "HEAD"));
struct ref *local_refs = head;
struct ref **tail = head ? &head->next : &local_refs;
+ int i;
+
+ for (i = 0; i < refspec_nr; i++)
+ get_fetch_map(refs, &refspec[i], &tail, 0);
- get_fetch_map(refs, refspec, &tail, 0);
if (!option_mirror)
get_fetch_map(refs, tag_refspec, &tail, 0);
@@ -482,7 +498,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
int err = 0;
struct refspec *refspec;
- const char *fetch_pattern;
junk_pid = getpid();
@@ -508,6 +523,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_no_checkout = 1;
}
+ if (option_mirror && refspecs)
+ die(_("--mirror and --fetch options are incompatible"));
+
if (!option_origin)
option_origin = "origin";
@@ -594,30 +612,55 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
if (option_bare) {
- if (option_mirror)
+ git_config_set("core.bare", "true");
+ if (option_mirror) {
src_ref_prefix = "refs/";
- strbuf_addstr(&branch_top, src_ref_prefix);
+ strbuf_addf(&key, "remote.%s.mirror", option_origin);
+ git_config_set(key.buf, "true");
+ strbuf_reset(&key);
+ }
- git_config_set("core.bare", "true");
+ strbuf_addstr(&branch_top, src_ref_prefix);
} else {
strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
}
- strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+ strbuf_reset(&key);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+
+ /* If the user didn't override it, use the default values */
+ if (option_fetch.nr == 0) {
+ strbuf_reset(&value);
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix,
+ branch_top.buf);
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(&key, "remote.%s.fetch", option_origin);
git_config_set_multivar(key.buf, value.buf, "^$", 0);
- strbuf_reset(&key);
+ add_refspec(strbuf_detach(&value, NULL));
+ } else {
+ int i;
+ for (i = 0; i < option_fetch.nr; i++) {
+ const char *ref = option_fetch.items[i].string;
+ if (!valid_fetch_refspec(ref))
+ die(_("Not a valid fetch refspec: %s"), ref);
+
+ /* If we only got a branch name, make it a proper refspec */
+ if (!strchr(ref, ':')) {
+ strbuf_reset(&value);
+ strbuf_addf(&value, "refs/heads/%s:%s%s",
+ ref, branch_top.buf, ref);
+ ref = value.buf;
+ }
- if (option_mirror) {
- strbuf_addf(&key, "remote.%s.mirror", option_origin);
- git_config_set(key.buf, "true");
- strbuf_reset(&key);
+ printf("Adding refpsec %s\n", ref);
+ git_config_set_multivar(key.buf, value.buf, "^$", 0);
+ add_refspec(strbuf_detach(&value, NULL));
}
+
+ strbuf_reset(&value);
+ strbuf_reset(&key);
}
+ strbuf_reset(&key);
strbuf_addf(&key, "remote.%s.url", option_origin);
git_config_set(key.buf, repo);
strbuf_reset(&key);
@@ -625,14 +668,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_reference.nr)
setup_reference();
- fetch_pattern = value.buf;
- refspec = parse_fetch_refspec(1, &fetch_pattern);
-
- strbuf_reset(&value);
+ refspec = parse_fetch_refspec(refspecs_nr, refspecs);
if (is_local) {
refs = clone_local(path, git_dir);
- mapped_refs = wanted_peer_refs(refs, refspec);
+ mapped_refs = wanted_peer_refs(refs, refspec, refspecs_nr);
} else {
struct remote *remote = remote_get(option_origin);
transport = transport_get(remote, remote->url[0]);
@@ -654,7 +694,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = transport_get_remote_refs(transport);
if (refs) {
- mapped_refs = wanted_peer_refs(refs, refspec);
+ mapped_refs = wanted_peer_refs(refs, refspec, refspecs_nr);
transport_fetch_refs(transport, mapped_refs);
}
}
diff --git a/t/t5702-clone-options.sh b/t/t5702-clone-options.sh
index 02cb024..53d914f 100755
--- a/t/t5702-clone-options.sh
+++ b/t/t5702-clone-options.sh
@@ -8,15 +8,17 @@ test_expect_success 'setup' '
mkdir parent &&
(cd parent && git init &&
echo one >file && git add file &&
- git commit -m one)
+ git commit -m one &&
+ git branch other)
'
test_expect_success 'clone -o' '
git clone -o foo parent clone-o &&
- (cd clone-o && git rev-parse --verify refs/remotes/foo/master)
-
+ (cd clone-o &&
+ git rev-parse --verify refs/remotes/foo/master &&
+ git rev-parse --verify refs/remotes/foo/other)
'
test_expect_success 'redirected clone' '
@@ -33,4 +35,18 @@ test_expect_success 'redirected clone -v' '
'
+test_expect_success 'select one branch to fetch' '
+ git clone --progress --fetch=master "file://$(pwd)/parent" clone-select-one &&
+ (cd clone-sel &&
+ git rev-parse --verify refs/remotes/origin/master &&
+ test_must_fail git rev-parse --verify refs/remotes/origin/other)
+'
+
+test_expect_success 'select several branches to fetch' '
+ git clone --progress --fetch=master --fetch=other "file://$(pwd)/parent" clone-select-many &&
+ (cd clone-sel2 &&
+ git rev-parse --verify refs/remotes/origin/master &&
+ git rev-parse --verify refs/remotes/origin/other)
+'
+
test_done
--
1.7.8.352.g876a6f
^ permalink raw reply related
* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-23 20:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF422D3.2050802@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> IMO the solution to not translate plumbing messages is to omit the
> initialization of the gettext machinery.
That's clever, and might be a good approach. I didn't think things through
nor looked at the existing codepaths where we do that (and I won't be
looking at them over the holiday weekend).
> Anyway, here is a patch that modifies vreportf() in an i18n friendly way
> (I think). It is not necessarily meant for inclusion.
The test-part of the patch seems to match more or less what I tentatively
queued after I sent the "convert at vreportf() level" patch and then
discarded. You seem to have missed vwritef(), by the way.
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Junio C Hamano @ 2011-12-23 20:58 UTC (permalink / raw)
To: Jeff King; +Cc: nathan.panike, git
In-Reply-To: <20111223103511.GA10029@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here's how I would have done it. Not involving %w at all, but applying
> equally to all placeholders.
Hmm, just curious why you rejected the %w() approach, as enhancing %w
sounded to me like a better approach at the design level, but that was a
knee-jerk reaction without inspecting the codepaths involved myself hence
not knowing the potential amount of work required.
> - userformat_want_item should also respect the same magic (it already
> duplicates some of the "-/+/ " magic. It might be nice to factor
> that part out).
I recall this was a bit of a bear when I looked at the area last time.
^ permalink raw reply
* Re: [RFC PATCH] Allow cloning branches selectively
From: Junio C Hamano @ 2011-12-23 21:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1324671199-7074-1-git-send-email-cmn@elego.de>
Carlos Martín Nieto <cmn@elego.de> writes:
> Sometimes it's useful to clone only a subset of branches from a remote
> we're cloning. Teach clone the --fetch option to select which branches
> should get fetched.
This is just a knee-jerk reaction without reading the patch text (which I
won't be doing over the holiday weekend anyway), but is the workflow of
the primarly intended audience to clone "a subset of branches" or "a
single branch"?
I have a slight suspicion that this started out as "I often want to create
a clone to _track_ a single branch, but because I am mucking with the code
related to cloning anyway, I might as well allow more than one to be
fetched, even though I do not have any need for that, somebody might find
it useful". And that is why it is important to answer the first question.
If the primary motivation is for a single branch, I suspect supporting
only a single branch and advertising the feature as "tracking only one
branch" might make it much easier to understand to the end users.
Upon "git clone --track cn/single-clone $there x.git", you would do
something like:
it=cn/single-clone &&
git init x.git &&
cd x.git &&
# configure "git fetch origin" to only get branch $it
git config remote.origin.url "$there" &&
git config remote.origin.fetch refs/heads/$it:refs/remotes/origin/$it &&
# declare that the primary branch at origin is $it as far as we are concerned
git symbolic-ref -m clone refs/remotes/origin/HEAD refs/remotes/origin/$it &&
# Git aware prompt reminds us that this repository is to track branch $it
git symbolic-ref -m clone HEAD refs/heads/$it &&
# And Go!
git fetch origin &&
git reset --hard remotes/origin/$it &&
git config branch.$it.remote origin &&
git config branch.$it.merge $it
Of course you _could_ support more than one pretty easily, but the point
is that it is unclear how you explain to the end user what the feature
does and what it is for in easily understoodd terms, once you start doing
so. It will no longer be "this new clone is to track that branch", but
something else, and I do not know what that something else is.
And depending on what that "something else" is, which branch should be
checked out and what refs/remotes/origin/HEAD should name as the primary
branch of the remote would be different.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Ævar Arnfjörð Bjarmason @ 2011-12-23 22:37 UTC (permalink / raw)
To: Thomas Rast
Cc: René Scharfe, Eric Herman, git, Junio C Hamano,
Fredrik Kuivinen
In-Reply-To: <5328add8b32f83b4cdbd2e66283f77c125ec127a.1322830368.git.trast@student.ethz.ch>
On Fri, Dec 2, 2011 at 14:07, Thomas Rast <trast@student.ethz.ch> wrote:
> I conjecture that this is caused by contention on
> read_sha1_mutex. [...] So disable threading entirely when not
> scanning the worktree
Why does git-grep even need to keep a mutex to call read_sha1_file()?
It's inherently a read-only operation isn't it? If the lock is needed
because data is being shared between threads in sha1_file.c shouldn't
we tackle that instead of completely disabling threading?
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Thomas Rast @ 2011-12-23 22:49 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: René Scharfe, Eric Herman, git, Junio C Hamano,
Fredrik Kuivinen
In-Reply-To: <CACBZZX6hboo4wu3fOs+CHnxsdmedxw72GFMVttQzmHzpcZbqoQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Fri, Dec 2, 2011 at 14:07, Thomas Rast <trast@student.ethz.ch> wrote:
>
>> I conjecture that this is caused by contention on
>> read_sha1_mutex. [...] So disable threading entirely when not
>> scanning the worktree
>
> Why does git-grep even need to keep a mutex to call read_sha1_file()?
> It's inherently a read-only operation isn't it? If the lock is needed
> because data is being shared between threads in sha1_file.c shouldn't
> we tackle that instead of completely disabling threading?
The problem is that all sorts of data is shared. See
http://thread.gmane.org/gmane.comp.version-control.git/186618
But I need to go through it again, there are some races and double locks
in the posted version.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Jeff King @ 2011-12-23 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: nathan.panike, git
In-Reply-To: <7v1urvc8fb.fsf@alter.siamese.dyndns.org>
On Fri, Dec 23, 2011 at 12:58:00PM -0800, Junio C Hamano wrote:
> > Here's how I would have done it. Not involving %w at all, but applying
> > equally to all placeholders.
>
> Hmm, just curious why you rejected the %w() approach, as enhancing %w
> sounded to me like a better approach at the design level, but that was a
> knee-jerk reaction without inspecting the codepaths involved myself hence
> not knowing the potential amount of work required.
Not so much rejecting as I took a quick look at how I would have done
what your original patch did, and it was simple enough that I took it
all the way to working and decided to post it. I left it up to you to
decide whether using %w would be more sensible. I just wanted to present
another alternative for discussion.
-Peff
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Jeff King @ 2011-12-23 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: nathan.panike, git
In-Reply-To: <20111223230228.GA1718@sigill.intra.peff.net>
On Fri, Dec 23, 2011 at 06:02:28PM -0500, Jeff King wrote:
> On Fri, Dec 23, 2011 at 12:58:00PM -0800, Junio C Hamano wrote:
>
> > > Here's how I would have done it. Not involving %w at all, but applying
> > > equally to all placeholders.
> >
> > Hmm, just curious why you rejected the %w() approach, as enhancing %w
> > sounded to me like a better approach at the design level, but that was a
> > knee-jerk reaction without inspecting the codepaths involved myself hence
> > not knowing the potential amount of work required.
>
> Not so much rejecting as I took a quick look at how I would have done
> what your original patch did, and it was simple enough that I took it
> all the way to working and decided to post it. I left it up to you to
> decide whether using %w would be more sensible. I just wanted to present
> another alternative for discussion.
Eh, I misread the "From" header. All of the "you" there is "Nathan".
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Ævar Arnfjörð Bjarmason @ 2011-12-24 1:39 UTC (permalink / raw)
To: Thomas Rast
Cc: René Scharfe, Eric Herman, git, Junio C Hamano,
Fredrik Kuivinen
In-Reply-To: <87mxaihpiq.fsf@thomas.inf.ethz.ch>
2011/12/23 Thomas Rast <trast@student.ethz.ch>:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Fri, Dec 2, 2011 at 14:07, Thomas Rast <trast@student.ethz.ch> wrote:
>>
>>> I conjecture that this is caused by contention on
>>> read_sha1_mutex. [...] So disable threading entirely when not
>>> scanning the worktree
>>
>> Why does git-grep even need to keep a mutex to call read_sha1_file()?
>> It's inherently a read-only operation isn't it? If the lock is needed
>> because data is being shared between threads in sha1_file.c shouldn't
>> we tackle that instead of completely disabling threading?
>
> The problem is that all sorts of data is shared. See
>
> http://thread.gmane.org/gmane.comp.version-control.git/186618
>
> But I need to go through it again, there are some races and double locks
> in the posted version.
I mentioned this on IRC, but I thought I'd bring it up here too.
Is the expensive part of git-grep all the setup work, or the actual
traversal and searching? I'm guessing it's the latter.
In that case an easy way to do git-grep in parallel would be to simply
spawn multiple sub-processes, e.g. if we had 1000 files and 4 cores:
1. Split the 1000 into 4 parts 250 each.
2. Spawn 4 processes as: git grep <pattern> -- <250 files>
3. Aggregate all of the results in the parent process
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Martin von Zweigbergk @ 2011-12-24 4:22 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Pat Thoyts, Git Mailing List
In-Reply-To: <4EF4CE80.8090502@dirk.my1.cc>
2011/12/23 Dirk Süsserott <newsletter@dirk.my1.cc>:
>
> That's because gitk behaves odd (at least to me) when not run from the
> top-level directory. E.g. the "touching paths" box won't find files in
> the top dir if you don't prefix them with a slash.
This should be fixed in c332f44 (gitk: Fix file highlight when run in
subdirectory, 2011-04-04), which is in the current master and thus, I
believe, to be released in Git 1.7.9.
Martin
^ permalink raw reply
* Re: [RFC PATCH] Allow cloning branches selectively
From: Nguyen Thai Ngoc Duy @ 2011-12-24 4:31 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1324671199-7074-1-git-send-email-cmn@elego.de>
On Sat, Dec 24, 2011 at 3:13 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> Sometimes it's useful to clone only a subset of branches from a remote
> we're cloning. Teach clone the --fetch option to select which branches
> should get fetched.
What about tags? Are all tags fetched or only ones part of the
selected branches?
--
Duy
^ permalink raw reply
* Wrong code on master
From: Jonathan Duncan @ 2011-12-24 5:09 UTC (permalink / raw)
To: git
I have a developer that committed code that should have been on a branch. I have created a branch now and locally my master branch is good to go. However, when I try to push it conflicts, of course, because the repo still wants me to pull the changes and merge them to my master.
The new code from the other developer will eventually be used, but we were not ready for it to be on "master" yet. I need to push my own code out before that other code gets used.
Will I really have to pull and merge the code to master and then revert? I have been googling all day, trying to figure out the best way to do this and in the process I fear I have made a mess of my repo. I have been using git long enough to be dangerous to myself.
Any thoughts? Got a good article I can read?
Thanks,
Jonathan
^ permalink raw reply
* Re: Wrong code on master
From: Frans Klaver @ 2011-12-24 5:49 UTC (permalink / raw)
To: git, Jonathan Duncan
In-Reply-To: <36BFCDA4-8249-4965-877F-FFC9EA65C7EE@memoryties.com>
On Sat, 24 Dec 2011 06:09:06 +0100, Jonathan Duncan
<jonathan@memoryties.com> wrote:
> I have a developer that committed code that should have been on a
> branch. I have created a branch now and locally my master branch is
> good to go. However, when I try to push it conflicts, of course,
> because the repo still wants me to pull the changes and merge them to my
> master.
>
> The new code from the other developer will eventually be used, but we
> were not ready for it to be on "master" yet. I need to push my own code
> out before that other code gets used.
>
> Will I really have to pull and merge the code to master and then
> revert? I have been googling all day, trying to figure out the best way
> to do this and in the process I fear I have made a mess of my repo. I
> have been using git long enough to be dangerous to myself.
Well, the proper way is to revert the commits. That won't result in all
other developers having to deal with a force-updated branch. If you can
deal with it you can always
$ git push origin +branch
but I wouldn't consider that a nice thing to do.
^ permalink raw reply
* Re: Wrong code on master
From: Jonathan Duncan @ 2011-12-24 6:37 UTC (permalink / raw)
To: Frans Klaver; +Cc: git
In-Reply-To: <op.v6zbsrvi0aolir@keputer>
On 23 Dec 2011, at 22:49, Frans Klaver wrote:
> Well, the proper way is to revert the commits. That won't result in all other developers having to deal with a force-updated branch. If you can deal with it you can always
>
> $ git push origin +branch
>
> but I wouldn't consider that a nice thing to do.
Good information, thank you. I think I will mark this as a good learning experience for me. I will make it a point to inform all my team members to work from branches until we are ready for merging to the master branch.
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Jeff King @ 2011-12-24 7:07 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Thomas Rast, René Scharfe, Eric Herman, git, Junio C Hamano,
Fredrik Kuivinen
In-Reply-To: <CACBZZX67WhcdhXdqOm8gZHW7C3YMbV2KzeytwjHwsnF=8-M_+w@mail.gmail.com>
On Sat, Dec 24, 2011 at 02:39:11AM +0100, Ævar Arnfjörð Bjarmason wrote:
> Is the expensive part of git-grep all the setup work, or the actual
> traversal and searching? I'm guessing it's the latter.
>
> In that case an easy way to do git-grep in parallel would be to simply
> spawn multiple sub-processes, e.g. if we had 1000 files and 4 cores:
>
> 1. Split the 1000 into 4 parts 250 each.
> 2. Spawn 4 processes as: git grep <pattern> -- <250 files>
> 3. Aggregate all of the results in the parent process
That's an interesting idea. The expense of the traversal and searching
depends on two things:
- how complex is your regex?
- are you reading from objects (which need zlib inflated) or disk?
But you should be able to approximate it by compiling with NO_PTHREADS
and doing (assuming you have GNU xargs):
# grep in working tree
git ls-files | xargs -P 8 git grep "$re" --
# grep tree-ish
git ls-tree -r --name-only $tree | xargs -P 8 git grep "$re" $tree --
I tried to get some timings for this, but ran across some quite
surprising results. Here's a simple grep of the linux-2.6 working tree,
using a single-threaded grep:
$ time git grep SIMPLE >/dev/null
real 0m0.439s
user 0m0.272s
sys 0m0.160s
and then the same thing, via xargs, without even turning on
parallelization. This should give us a measurement of the overhead for
going through xargs at all. We'd expect it to be slower, but not too
much so:
$ time git ls-files | xargs git grep SIMPLE -- >/dev/null
real 0m11.989s
user 0m11.769s
sys 0m0.268s
Twenty-five times slower! Running 'perf' reports the culprit as pathspec
matching:
+ 63.23% git git [.] match_pathspec_depth
+ 28.60% git libc-2.13.so [.] __strncmp_sse42
+ 2.22% git git [.] strncmp@plt
+ 1.67% git git [.] kwsexec
where the strncmps are called as part of match_pathspec_depth. So over
90% of the CPU time is spent on matching the pathspecs, compared to less
than 2% actually grepping.
Which really makes me wonder if our pathspec matching could stand to be
faster. True, giving a bunch of single files is the least efficient way
to use pathspecs, but that's pretty amazingly slow.
The case where we would most expect the setup cost to be drowned out is
using a more complex regex, grepping tree objects. There we have a
baseline of:
$ time git grep 'a.*c' HEAD >/dev/null
real 0m5.684s
user 0m5.472s
sys 0m0.196s
$ time git ls-tree --name-only -r HEAD |
xargs git grep 'a.*c' HEAD -- >/dev/null
real 0m10.906s
user 0m10.725s
sys 0m0.240s
Here, we still almost double our time. It looks like we don't use the
same pathspec matching code in this case. But we do waste a lot of extra
time zlib-inflating the trees in "ls-tree", only to do it separately in
"grep".
Doing it in parallel yields:
$ time git ls-tree --name-only -r HEAD |
xargs -n 4000 -P 8 git grep 'a.*c' HEAD -- >/dev/null
real 0m3.573s
user 0m21.885s
sys 0m0.400s
So that does at least yield a real speedup, albeit only by about half,
despite using over six times as much CPU (though my numbers are skewed
somewhat, as this is a quad i7 with hyperthreading and turbo boost).
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Nguyen Thai Ngoc Duy @ 2011-12-24 10:49 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð, Thomas Rast, René Scharfe,
Eric Herman, git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <20111224070715.GA32267@sigill.intra.peff.net>
On Sat, Dec 24, 2011 at 2:07 PM, Jeff King <peff@peff.net> wrote:
> I tried to get some timings for this, but ran across some quite
> surprising results. Here's a simple grep of the linux-2.6 working tree,
> using a single-threaded grep:
>
> $ time git grep SIMPLE >/dev/null
> real 0m0.439s
> user 0m0.272s
> sys 0m0.160s
>
> and then the same thing, via xargs, without even turning on
> parallelization. This should give us a measurement of the overhead for
> going through xargs at all. We'd expect it to be slower, but not too
> much so:
>
> $ time git ls-files | xargs git grep SIMPLE -- >/dev/null
> real 0m11.989s
> user 0m11.769s
> sys 0m0.268s
>
> Twenty-five times slower! Running 'perf' reports the culprit as pathspec
> matching:
>
> + 63.23% git git [.] match_pathspec_depth
> + 28.60% git libc-2.13.so [.] __strncmp_sse42
> + 2.22% git git [.] strncmp@plt
> + 1.67% git git [.] kwsexec
>
> where the strncmps are called as part of match_pathspec_depth. So over
> 90% of the CPU time is spent on matching the pathspecs, compared to less
> than 2% actually grepping.
>
> Which really makes me wonder if our pathspec matching could stand to be
> faster. True, giving a bunch of single files is the least efficient way
> to use pathspecs, but that's pretty amazingly slow.
We could eliminate get_pathspec_depth() in grep_directory() when
read_directory() learns to filter path properly using (and at the cost
of) tree_entry_interesting(). The latter function has more
optimizaions built in and should be faster than the former. This is a
good test case for my read_directory() rewrite. Thanks.
get_pathspec_depth() can still use some optimizations though for
grep_cache() case.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Nguyen Thai Ngoc Duy @ 2011-12-24 10:55 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð, Thomas Rast, René Scharfe,
Eric Herman, git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <20111224070715.GA32267@sigill.intra.peff.net>
(Sorry I replied without reading though the mail)
On Sat, Dec 24, 2011 at 2:07 PM, Jeff King <peff@peff.net> wrote:
> The case where we would most expect the setup cost to be drowned out is
> using a more complex regex, grepping tree objects. There we have a
> baseline of:
>
> $ time git grep 'a.*c' HEAD >/dev/null
> real 0m5.684s
> user 0m5.472s
> sys 0m0.196s
>
> $ time git ls-tree --name-only -r HEAD |
> xargs git grep 'a.*c' HEAD -- >/dev/null
> real 0m10.906s
> user 0m10.725s
> sys 0m0.240s
>
> Here, we still almost double our time. It looks like we don't use the
> same pathspec matching code in this case. But we do waste a lot of extra
> time zlib-inflating the trees in "ls-tree", only to do it separately in
> "grep".
I assume this is gree_tree(), we have another form of pathspec
matching here: tree_entry_interesting() and it's still a bunch of
strcmp inside. Does strcmp show up in perf report?
--
Duy
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Jeff King @ 2011-12-24 13:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Ævar Arnfjörð, Thomas Rast, René Scharfe,
Eric Herman, git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <CACsJy8DbfE8r3KsxCnb30-sb3LUAAWapAKJUSJ1zBZme1FoMwg@mail.gmail.com>
On Sat, Dec 24, 2011 at 05:55:14PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sat, Dec 24, 2011 at 2:07 PM, Jeff King <peff@peff.net> wrote:
> > The case where we would most expect the setup cost to be drowned out is
> > using a more complex regex, grepping tree objects. There we have a
> > baseline of:
> >
> > $ time git grep 'a.*c' HEAD >/dev/null
> > real 0m5.684s
> > user 0m5.472s
> > sys 0m0.196s
> >
> > $ time git ls-tree --name-only -r HEAD |
> > xargs git grep 'a.*c' HEAD -- >/dev/null
> > real 0m10.906s
> > user 0m10.725s
> > sys 0m0.240s
> >
> > Here, we still almost double our time. It looks like we don't use the
> > same pathspec matching code in this case. But we do waste a lot of extra
> > time zlib-inflating the trees in "ls-tree", only to do it separately in
> > "grep".
>
> I assume this is gree_tree(), we have another form of pathspec
> matching here: tree_entry_interesting() and it's still a bunch of
> strcmp inside. Does strcmp show up in perf report?
Yes, but not nearly as high. The top of the report is:
+ 32.16% git libc-2.13.so [.] re_search_internal
+ 17.82% git libz.so.1.2.3.4 [.] 0xe986
+ 7.81% git git [.] look_ahead
+ 6.24% git libc-2.13.so [.] __strncmp_sse42
+ 4.08% git git [.] tree_entry_interesting
+ 3.27% git git [.] end_of_line
+ 2.63% git libz.so.1.2.3.4 [.] adler32
+ 1.93% git libz.so.1.2.3.4 [.] inflate
where the strncmps are from[1]:
- 6.24% git libc-2.13.so [.] __strncmp_sse42
- __strncmp_sse42
+ 80.92% grep_tree
+ 19.08% tree_entry_interesting
So we're spending maybe 10% of our time on pathspecs, but most of it is
going to zlib and the actual regex search.
-Peff
[1] Note that this is with -O2, so some of that is from inlined calls.
^ permalink raw reply
* (amended) need to talk to Linus Torvalds
From: Pedro Bessa @ 2011-12-24 12:49 UTC (permalink / raw)
To: git
Since Wine exists, how about asking Microsoft permission, reimplementing
Windows7 in the best programming language ever, e-mailing it to Microsoft,
asking them to not make the rest of the industry be stuck for 10 years with
the same technology?
^ 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