[PATCH] show-ref: make --head always show the HEAD ref

2013-05-30 Thread Doug Bell
The docs seem to say that doing git show-ref --head --tags would show both the HEAD ref and all the tag refs. However, doing both --head and either of --tags or --heads would filter out the HEAD ref. Signed-off-by: Doug Bell madcity...@gmail.com --- I think this patch could be done

Re: [PATCH v2 2/7] add tests for rebasing with patch-equivalence present

2013-05-30 Thread Martin von Zweigbergk
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk martinv...@gmail.com wrote: On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:

project

2013-05-30 Thread Yong F
Hello, I am Mr. Fang Yong from Wing Lung Bank.I have a secured business proposal worth US$16.5M .Get back to me for more details. Regards, Fang L. Yong -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH v2 2/7] add tests for rebasing with patch-equivalence present

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk martinv...@gmail.com wrote: On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk martinv...@gmail.com wrote: On Wed, May 29, 2013 at 12:09 AM,

Re: [PATCH v2 2/7] add tests for rebasing with patch-equivalence present

2013-05-30 Thread Martin von Zweigbergk
On Wed, May 29, 2013 at 11:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk martinv...@gmail.com wrote: On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 30, 2013 at 12:30 AM, Martin

Re: [PATCH v13 02/15] path.c: refactor relative_path(), not only strip prefix

2013-05-30 Thread Jiang Xin
2013/5/26 Jiang Xin worldhello@gmail.com: 2013/5/22 Michael Haggerty mhag...@alum.mit.edu: The old and new versions both seem to be (differently) inconsistent about when the output has a trailing slash. What is the rule? The reason for introducing patch 02/15 is that we don't want to

Re: [msysGit] Re: t0008-ignores failure

2013-05-30 Thread Johannes Sixt
Am 30.05.2013 04:55, schrieb Jeff King: So while it would be nice to work on paths with colons everywhere, I doubt it is worth the effort to start checking it through the whole test suite. And on top of it, on Windows, you can't have a path component or file name that contains a colon... --

[PATCH v2 0/6] git send-email suppress-cc=self fixes

2013-05-30 Thread Michael S. Tsirkin
This includes bugfixes related to handling of --suppress-cc=self flag. Tests are also included. Changes from v1: - tweak coding style in tests to address comments by Junio Michael S. Tsirkin (6): t/send-email.sh: add test for suppress-cc=self send-email: fix suppress-cc=self on cccmd

[PATCH v2 1/6] t/send-email.sh: add test for suppress-cc=self

2013-05-30 Thread Michael S. Tsirkin
This adds a basic test for --suppress-cc=self option of git send-email. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- t/t9001-send-email.sh | 43 +++ 1 file changed, 43 insertions(+) diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index

[PATCH v2 2/6] send-email: fix suppress-cc=self on cccmd

2013-05-30 Thread Michael S. Tsirkin
When cccmd is used, old-style suppress-from filter is applied by the newer suppress-cc=self isn't. Fix this up. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- git-send-email.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl

[PATCH v2 3/6] t/send-email: test suppress-cc=self on cccmd

2013-05-30 Thread Michael S. Tsirkin
Check that suppress-cc=self works when applied to output of cccmd. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- t/t9001-send-email.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index e1a7f3e..452b362 100755 ---

[PATCH v2 4/6] send-email: make --suppress-cc=self sanitize input

2013-05-30 Thread Michael S. Tsirkin
--suppress-cc=self fails to filter sender address in many cases where it needs to be sanitized in some way, for example quoted: A U. Thor aut...@example.com To fix, make send-email sanitize both sender and the address it is compared against. Signed-off-by: Michael S. Tsirkin m...@redhat.com ---

[PATCH v2 5/6] t/send-email: add test with quoted sender

2013-05-30 Thread Michael S. Tsirkin
add test where sender address needs to be quoted. Make sure --suppress-cc=self works well in this case. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- t/t9001-send-email.sh | 20 1 file changed, 20 insertions(+) diff --git a/t/t9001-send-email.sh

[PATCH v2 6/6] t/send-email: test suppress-cc=self with non-ascii

2013-05-30 Thread Michael S. Tsirkin
test suppress-cc=self when sender is non-acsii Signed-off-by: Michael S. Tsirkin m...@redhat.com --- t/t9001-send-email.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 42fb809..430e8de 100755 --- a/t/t9001-send-email.sh +++

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

2013-05-30 Thread Ramkumar Ramachandra
Jonathan Nieder wrote: That's detectable and could be made to error out, so it's not too bad. Sure it's possible, but I'm arguing about whether it's worth the effort. There can be loops like a - b - c - d - e - a. Given that nobody has even bothered to get git to print an error message when a

Re: [PATCH] git clone depth of 0 not possible.

2013-05-30 Thread Matthijs Kooijman
Hi Junio, On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote: Matthijs Kooijman matth...@stdin.nl writes: Did you consider how to implement this? Looking at the code, it seems the deepen parameter in the wire protocol now means: - 0: Do not change anything about the

[PATCH] wildmatch: properly fold case everywhere

2013-05-30 Thread Anthony Ramine
Case folding is not done correctly when matching against the [:upper:] character class and uppercased character ranges (e.g. A-Z). Specifically, an uppercase letter fails to match against any of them when case folding is requested because plain characters in the pattern and the whole string and

Re: [PATCH] wildmatch: properly fold case everywhere

2013-05-30 Thread Duy Nguyen
On Thu, May 30, 2013 at 3:45 PM, Anthony Ramine n.ox...@gmail.com wrote: Case folding is not done correctly when matching against the [:upper:] character class and uppercased character ranges (e.g. A-Z). Specifically, an uppercase letter fails to match against any of them when case folding is

Re: [PATCH v7] Add new git-related helper to contrib

2013-05-30 Thread Ramkumar Ramachandra
Let's do one more review. Felipe Contreras wrote: diff --git a/contrib/related/git-related b/contrib/related/git-related new file mode 100755 index 000..1b9b1e7 --- /dev/null +++ b/contrib/related/git-related @@ -0,0 +1,120 @@ +#!/usr/bin/env ruby + +# This script finds people that

Re: [PATCH] wildmatch: properly fold case everywhere

2013-05-30 Thread Eric Sunshine
On Thu, May 30, 2013 at 4:45 AM, Anthony Ramine n.ox...@gmail.com wrote: Case folding is not done correctly when matching against the [:upper:] character class and uppercased character ranges (e.g. A-Z). Specifically, an uppercase letter fails to match against any of them when case folding is

Re: [PATCH] wildmatch: properly fold case everywhere

2013-05-30 Thread Anthony Ramine
Yes indeed. Will amend. Should I add your name in Reviewed-by as well? -- Anthony Ramine Le 30 mai 2013 à 11:07, Eric Sunshine a écrit : On Thu, May 30, 2013 at 4:45 AM, Anthony Ramine n.ox...@gmail.com wrote: Case folding is not done correctly when matching against the [:upper:] character

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

2013-05-30 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes: * rr/die-on-missing-upstream (2013-05-22) 2 commits - sha1_name: fix error message for @{N}, @{date} - sha1_name: fix error message for @{u} When a reflog notation is used for implicit current branch, we did not say which branch and worse said

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

2013-05-30 Thread Ramkumar Ramachandra
Thomas Rast wrote: diff --git i/sha1_name.c w/sha1_name.c index 5ea16ff..a07558d 100644 --- i/sha1_name.c +++ w/sha1_name.c @@ -538,7 +538,6 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1) back to %s., len, str,

Re: [PATCH] wildmatch: properly fold case everywhere

2013-05-30 Thread Eric Sunshine
On Thu, May 30, 2013 at 5:29 AM, Anthony Ramine n.ox...@gmail.com wrote: Yes indeed. Will amend. Should I add your name in Reviewed-by as well? No. I merely spotted a minor typographical error. -- Anthony Ramine Le 30 mai 2013 à 11:07, Eric Sunshine a écrit : On Thu, May 30, 2013 at 4:45

Re: Has anyone tried to implement git grep --blame?

2013-05-30 Thread Jakub Narebski
Ævar Arnfjörð Bjarmason avarab at gmail.com writes: This would be so much more convenient if git-grep supported it natively: $ git grep -n 'if \(0\)' | perl -pe's/([^:]+):([^:]+).*/`git blame -L $2,$2 $1`/se' d18f76dc (Ævar Arnfjörð Bjarmason 2010-08-17 09:24:38 + 2278) if (0)

[PATCH v5] wildmatch: properly fold case everywhere

2013-05-30 Thread Anthony Ramine
Case folding is not done correctly when matching against the [:upper:] character class and uppercased character ranges (e.g. A-Z). Specifically, an uppercase letter fails to match against any of them when case folding is requested because plain characters in the pattern and the whole string are

Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
Hi, I'm a fairly heavy user of the magit Emacs extension for interacting with my git repos. However I've noticed there are some cases where lag is very high. By analysing strace output of emacs calling git I found two commands that where particularly problematic when interrogating the repo:

Re: [PATCH v7] Add new git-related helper to contrib

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Let's do one more review. Felipe Contreras wrote: diff --git a/contrib/related/git-related b/contrib/related/git-related new file mode 100755 index 000..1b9b1e7 --- /dev/null +++

Re: Poor performance of git describe in big repos

2013-05-30 Thread Ramkumar Ramachandra
Alex Bennée wrote: time /usr/bin/git --no-pager traversed 223 commits real0m4.817s user0m4.320s sys 0m0.464s I'm quite clueless about why it is taking this long: I think it's IO because there's nothing to compute? I really can't trace anything unless you can reproduce it on a

[PATCH 0/7] unpack-trees: plug memory leak for merges

2013-05-30 Thread René Scharfe
This series adds const to cache_entry pointers in a lot of places, in order to show that we can free them in unpack_nondirectories, which the last patch finally does. First three easy patches for adding const and splitting a function in two: cache: mark cache_entry pointers const read-cache:

[PATCH 1/7] cache: mark cache_entry pointers const

2013-05-30 Thread René Scharfe
Add const for pointers that are only dereferenced for reading by the inline functions copy_cache_entry and ce_mode_from_stat. This allows callers to pass in const pointers. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- cache.h | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH 2/7] read-cache: mark cache_entry pointers const

2013-05-30 Thread René Scharfe
ie_match_stat and ie_modified only derefence their struct cache_entry pointers for reading. Add const to the parameter declaration here and do the same for the static helper function used by them, as it's the same there as well. This allows callers to pass in const pointers. Signed-off-by: René

[PATCH 7/7] unpack-trees: free cache_entry array members for merges

2013-05-30 Thread René Scharfe
The merge functions duplicate entries as needed and they don't free them. Release them in unpack_nondirectories, the same function where they were allocated, after we're done. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- unpack-trees.c | 11 --- 1 file changed, 8

[PATCH 3/7] unpack-trees: factor out dup_entry

2013-05-30 Thread René Scharfe
While we're add it, mark the struct cache_entry pointer of add_entry const because we only read from it and this allows callers to pass in const pointers. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- unpack-trees.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)

[PATCH 4/7] unpack-trees: create working copy of merge entry in merged_entry

2013-05-30 Thread René Scharfe
Duplicate the merge entry right away and work with that instead of modifying the entry we got and duplicating it only at the end of the function. Then mark that pointer const to document that we don't modify the referenced cache_entry. This change is safe because all existing merge functions

[PATCH 6/7] diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const

2013-05-30 Thread René Scharfe
Change the type merge_fn_t to accept the array of cache_entry pointers as const pointers to const pointers. This documents the fact that the merge functions don't modify the cache_entry contents or replace any of the pointers in the array. Only a single cast is necessary in unpack_nondirectories

[PATCH 5/7] diff-lib, read-tree, unpack-trees: mark cache_entry pointers const

2013-05-30 Thread René Scharfe
Add const to struct cache_entry pointers throughout the tree which are only used for reading. This allows callers to pass in const pointers. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- builtin/read-tree.c | 2 +- diff-lib.c | 23 +++--- unpack-trees.c | 91

Re: [PATCH] Makefile: promote wildmatch to be the default fnmatch implementation

2013-05-30 Thread Duy Nguyen
On Thu, May 30, 2013 at 9:25 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This makes git use wildmatch by default for all fnmatch() calls. Users who want to use system fnmatch (or compat fnmatch) need to set NO_WILDMATCH flag. wildmatch is a

Re: Poor performance of git describe in big repos

2013-05-30 Thread John Keeping
On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote: One factor might be the size of my repo (.git is around 2.4G). Could this just be due to computational cost of searching through large packs to walk the commit chain? Is there any way to make this easier for git to do? What does git

[PATCH 0/4] cherry-pick: fix memory leaks

2013-05-30 Thread Felipe Contreras
Hi, I took a shot at fixing the memory leaks of cherry-pick, and at least in my tests the memory doesn't seem to increase any more. Felipe Contreras (4): commit: reload cache properly read-cache: plug small memory leak unpack-trees: plug a memory leak unpack-trees: free created cache

[PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Felipe Contreras
We are supposedly adding files, to to which cache if 'the_index' is discarded? Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- builtin/commit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/commit.c b/builtin/commit.c index d2f30d9..092b49e 100644 ---

[PATCH 2/4] read-cache: plug small memory leak

2013-05-30 Thread Felipe Contreras
We free each entry, but not the array of entries themselves. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- read-cache.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/read-cache.c b/read-cache.c index 04ed561..9d9b886 100644 --- a/read-cache.c +++ b/read-cache.c @@

[PATCH 4/4] unpack-trees: free created cache entries

2013-05-30 Thread Felipe Contreras
We created them, and nobody else is going to destroy them. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index eff2944..9f19d01 100644 ---

[PATCH 3/4] unpack-trees: plug a memory leak

2013-05-30 Thread Felipe Contreras
Before overwriting the destination index, first let's discard it's contents. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/unpack-trees.c b/unpack-trees.c index ede4299..eff2944 100644 ---

Re: [PATCH 7/7] unpack-trees: free cache_entry array members for merges

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 6:34 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: The merge functions duplicate entries as needed and they don't free them. Release them in unpack_nondirectories, the same function where they were allocated, after we're done. Ah, you beat me to this change,

Re: [PATCH v7] Add new git-related helper to contrib

2013-05-30 Thread Ramkumar Ramachandra
Felipe Contreras wrote: What's your objective? Block this patch from ever going in? Not a single one of these comments makes a difference at all, all of them can wait until after the patch is merged, many of them are a matter of preferences, and some of them have already been addressed as

Re: [PATCH v7] Add new git-related helper to contrib

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 7:08 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Felipe Contreras wrote: What's your objective? Block this patch from ever going in? Not a single one of these comments makes a difference at all, all of them can wait until after the patch is merged, many of them

Re: [PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Thomas Rast
Felipe Contreras felipe.contre...@gmail.com writes: We are supposedly adding files, to to which cache if 'the_index' is discarded? [...] if (!current_head) { discard_cache(); + if (read_cache() 0) + die(_(cannot read the index));

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
The repo is a fairly hairy one as it includes two historically un-related but content related repos which I'm the process of cherry-picking stuff across. 11:58 ajb@sloy/x86_64 [work.git] git count-objects -v count: 493 size: 4572 in-pack: 399307 packs: 1 size-pack: 1930755 prune-packable: 0

Re: [PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote: Felipe Contreras felipe.contre...@gmail.com writes: We are supposedly adding files, to to which cache if 'the_index' is discarded? [...] if (!current_head) { discard_cache(); + if

Re: [PATCH v2 2/7] add tests for rebasing with patch-equivalence present

2013-05-30 Thread Johannes Sixt
Am 30.05.2013 07:30, schrieb Martin von Zweigbergk: On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: +# f +# / +# a---b---c---g---h +# \ +# d---G---i ... +test_run_rebase () { +

Re: [PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Thomas Rast
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote: Felipe Contreras felipe.contre...@gmail.com writes: We are supposedly adding files, to to which cache if 'the_index' is discarded? [...] if (!current_head) {

Re: [PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 7:58 AM, Thomas Rast tr...@inf.ethz.ch wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote: Felipe Contreras felipe.contre...@gmail.com writes: We are supposedly adding files, to to which

Re: [PATCH 1/4] commit: reload cache properly

2013-05-30 Thread Duy Nguyen
On Thu, May 30, 2013 at 7:17 PM, Thomas Rast tr...@inf.ethz.ch wrote: Felipe Contreras felipe.contre...@gmail.com writes: We are supposedly adding files, to to which cache if 'the_index' is discarded? [...] if (!current_head) { discard_cache(); + if

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
It looks like it's a file caching effect combined with my repo being more pathalogical in size and contents. Note run 1 (cold) vs run 2 on the linux file tree: 13:52 ajb@sloy/x86_64 [linux.git] time git describe --debug --long --tags HEAD~1 searching to describe HEAD~1 annotated

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
You may find that performance improves if you repack with git gc --aggressive. It seems that increases the time to get to where it wants to: 14:12 ajb@sloy/x86_64 [work.git] time /usr/bin/git --no-pager describe --long --tags --debug searching to describe HEAD lightweight 10

Re: Poor performance of git describe in big repos

2013-05-30 Thread Duy Nguyen
On Thu, May 30, 2013 at 7:29 PM, Alex Bennée kernel-hac...@bennee.com wrote: I ran perf on it and the top items in the report where: 41.58% git libcrypto.so.1.0.0 [.] 0x6ae73 33.96% git libz.so.1.2.3.4 [.] 0xe0ec 10.39% git libz.so.1.2.3.4 [.] adler32 2.03% git

[PATCH v2 1/3] read-cache: plug a few leaks

2013-05-30 Thread Felipe Contreras
We don't free 'istate-cache' properly. Apparently 'initialized' doesn't really mean initialized, but loaded, or rather 'not-empty', and the cache can be used even if it's not 'initialized', so we can't rely on this variable to keep track of the 'istate-cache'. So assume it always has data, and

[PATCH v2 3/3] unpack-trees: free created cache entries

2013-05-30 Thread Felipe Contreras
We created them, and nobody else is going to destroy them. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index eff2944..9f19d01 100644 ---

[PATCH v2 2/3] unpack-trees: plug a memory leak

2013-05-30 Thread Felipe Contreras
Before overwriting the destination index, first let's discard it's contents. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/unpack-trees.c b/unpack-trees.c index ede4299..eff2944 100644 ---

[PATCH v2 0/3] cherry-pick: fix memory leaks

2013-05-30 Thread Felipe Contreras
Hi, A small change since v1; one patch is dropped and another is updated to make up for it. Felipe Contreras (3): read-cache: plug a few leaks unpack-trees: plug a memory leak unpack-trees: free created cache entries read-cache.c | 4 unpack-trees.c | 16 +--- 2 files

Re: [PATCH v2 2/3] unpack-trees: plug a memory leak

2013-05-30 Thread Stefano Lattarini
On 05/30/2013 03:34 PM, Felipe Contreras wrote: Before overwriting the destination index, first let's discard it's s/it's/its/ contents. [SNIP] Regards, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

Re: Poor performance of git describe in big repos

2013-05-30 Thread Duy Nguyen
On Thu, May 30, 2013 at 8:34 PM, Alex Bennée kernel-hac...@bennee.com wrote: From the following run: 14:31 ajb@sloy/x86_64 [work.git] time /usr/bin/git --no-pager describe --long --tags ajb-build-test-5224-11-g9660048 real0m14.720s user0m12.985s sys 0m1.700s 14:31

[PATCH 1/2] core: use env variable instead of config var to turn on logging pack access

2013-05-30 Thread Nguyễn Thái Ngọc Duy
5f44324 (core: log offset pack data accesses happened - 2011-07-06) provides a way to observe pack access patterns via a config switch. Setting an environment variable looks more obvious than a config var, especially when you just need to _observe_, and more inline with other tracing knobs we

[PATCH 2/2] git.txt: document GIT_TRACE_PACKET

2013-05-30 Thread Nguyễn Thái Ngọc Duy
This can help with debugging object negotiation or other protocol issues. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git.txt b/Documentation/git.txt index 3e74440..12ef7a2 100644 ---

[PATCH] cherry-pick: don't barf when there's nothing to do

2013-05-30 Thread Felipe Contreras
If the user set --ff, it's expected that if theres's nothing to do we fast-forward our current HEAD, which is a no-op. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index

[PATCH] test: fix post rewrite hook report

2013-05-30 Thread Felipe Contreras
First expected, then actual. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t5407-post-rewrite-hook.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh index baa670c..ea2e0d4 100755 ---

[PATCH 0/4] Trivial patches

2013-05-30 Thread Felipe Contreras
Hi, Here's a bunch of trivial patches, mostly syle, but the first one might be important. Felipe Contreras (4): read-cache: fix wrong 'the_index' usage read-cache: trivial style cleanups unpack-trees: trivial cleanup sha1_file: trivial style cleanup read-cache.c | 6 +++---

[PATCH 1/4] read-cache: fix wrong 'the_index' usage

2013-05-30 Thread Felipe Contreras
We are dealing with the 'istate' index, not 'the_index'. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- read-cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/read-cache.c b/read-cache.c index 04ed561..5253ec5 100644 --- a/read-cache.c +++ b/read-cache.c

[PATCH 2/4] read-cache: trivial style cleanups

2013-05-30 Thread Felipe Contreras
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- read-cache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/read-cache.c b/read-cache.c index 5253ec5..7040e79 100644 --- a/read-cache.c +++ b/read-cache.c @@ -979,7 +979,7 @@ int add_index_entry(struct

[PATCH 3/4] unpack-trees: trivial cleanup

2013-05-30 Thread Felipe Contreras
dfc has not been initialized at this point. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index ede4299..36f4ff7 100644 --- a/unpack-trees.c +++ b/unpack-trees.c

[PATCH 4/4] sha1_file: trivial style cleanup

2013-05-30 Thread Felipe Contreras
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- sha1_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 67e815b..b114cc9 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -2138,7 +2138,7 @@ void *unpack_entry(struct packed_git *p,

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 14:45, Duy Nguyen pclo...@gmail.com wrote: On Thu, May 30, 2013 at 8:34 PM, Alex Bennée kernel-hac...@bennee.com wrote: snip Thanks. Can you share verify-pack -v output of pack-a9ba133a6f25ffa74c3c407e09ab030f8745b201.pack? I think you need to put it somewhere on Internet

Re: Poor performance of git describe in big repos

2013-05-30 Thread Ramkumar Ramachandra
Alex Bennée wrote: And through my special repo: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03% git [kernel.kallsyms] [k] clear_page_c I'm not sure why

Re: [PATCH] test: fix post rewrite hook report

2013-05-30 Thread Thomas Rast
Felipe Contreras felipe.contre...@gmail.com writes: First expected, then actual. Ack. That is the prevalent (almost universal, but not quite) style. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t5407-post-rewrite-hook.sh | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH 7/7] unpack-trees: free cache_entry array members for merges

2013-05-30 Thread René Scharfe
Am 30.05.2013 14:04, schrieb Felipe Contreras: On Thu, May 30, 2013 at 6:34 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: The merge functions duplicate entries as needed and they don't free them. Release them in unpack_nondirectories, the same function where they were allocated, after

Re: [PATCH v2 3/3] unpack-trees: free created cache entries

2013-05-30 Thread René Scharfe
Am 30.05.2013 15:34, schrieb Felipe Contreras: We created them, and nobody else is going to destroy them. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- unpack-trees.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

2013-05-30 Thread Jonathan Nieder
Felipe Contreras wrote: On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder jrnie...@gmail.com wrote: Felipe Contreras wrote: On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder jrnie...@gmail.com wrote: A bigger problem (in my opinion) with allowing arbitrary changes to the meaning of existing

Re: [PATCH v2 2/7] add tests for rebasing with patch-equivalence present

2013-05-30 Thread Martin von Zweigbergk
On Thu, May 30, 2013 at 5:54 AM, Johannes Sixt j...@kdbg.org wrote: Am 30.05.2013 07:30, schrieb Martin von Zweigbergk: On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: +# f +# / +# a---b---c---g---h +#

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 15:32, Ramkumar Ramachandra artag...@gmail.com wrote: Alex Bennée wrote: And through my special repo: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03%

Re: [PATCH v2 1/3] read-cache: plug a few leaks

2013-05-30 Thread René Scharfe
Am 30.05.2013 15:34, schrieb Felipe Contreras: We don't free 'istate-cache' properly. Apparently 'initialized' doesn't really mean initialized, but loaded, or rather 'not-empty', and the cache can be used even if it's not 'initialized', so we can't rely on this variable to keep track of the

Re: t0008-ignores failure (was: [msysGit] Git for Windows 1.8.3)

2013-05-30 Thread Johannes Schindelin
Hi Karsten, On Thu, 30 May 2013, Karsten Blees wrote: Am 25.05.2013 21:16, schrieb Pat Thoyts: On that note -- with this merge as it now stands I get the following test failures: t0008-ignores.sh 155, 158, 162, 164 These tests fail because they use absolute

Re: Poor performance of git describe in big repos

2013-05-30 Thread Ramkumar Ramachandra
Alex Bennée wrote: 15:50 ajb@sloy/x86_64 [work.git] time git log --pretty=oneline | wc -l 24648 real0m0.434s user0m0.388s sys 0m0.112s Although it doesn't take too long to walk the whole mainline history (obviously ignoring all the other branches). Damn, non-starter.

Re: [PATCH 7/7] unpack-trees: free cache_entry array members for merges

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 9:40 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Am 30.05.2013 14:04, schrieb Felipe Contreras: On Thu, May 30, 2013 at 6:34 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: The merge functions duplicate entries as needed and they don't free them. Release

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

2013-05-30 Thread Felipe Contreras
On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder jrnie...@gmail.com wrote: Felipe Contreras wrote: On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder jrnie...@gmail.com wrote: Felipe Contreras wrote: On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder jrnie...@gmail.com wrote: A bigger problem

Re: Poor performance of git describe in big repos

2013-05-30 Thread Thomas Rast
Alex Bennée kernel-hac...@bennee.com writes: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03% git [kernel.kallsyms] [k] clear_page_c Do you have any large blobs

Re: t0008-ignores failure (was: [msysGit] Git for Windows 1.8.3)

2013-05-30 Thread Pat Thoyts
On 30 May 2013 16:15, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Karsten, On Thu, 30 May 2013, Karsten Blees wrote: Am 25.05.2013 21:16, schrieb Pat Thoyts: On that note -- with this merge as it now stands I get the following test failures: t0008-ignores.sh

Re: [PATCH] git-gui: fix file name handling with non-empty prefix

2013-05-30 Thread John Keeping
In the hope that the Pat Thoyts who just posted in another thread from a GMail address is the same one that maintains git-gui, let's see if that address works... On Sat, May 11, 2013 at 10:03:25PM -0400, Andrew Wong wrote: Sorry for the late reply. I was able to reproduce the problem that you

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03% git

Re: Poor performance of git describe in big repos

2013-05-30 Thread Thomas Rast
Alex Bennée kernel-hac...@bennee.com writes: On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git

Should git help respect the 'pager' setting?

2013-05-30 Thread Michael Campbell
I have my global git config pager set to 'cat', but when I do a git help command, it still uses a pager. This is especially irksome in emacs shell buffers, where I am most of the time. I know I can do a M-x man - git-whatever, but wondered if this was a bug or user error. (git --no-pager help

preventing evil merges

2013-05-30 Thread Sandro Santilli
Hey all, I've be burnt by what someone on IRC referred to as evil merges, that is loss of history after amending a merge commit: git merge anotherbranch git add something git commit --amend After the steps above the addition of something can't be found in the history anymore, but the file is

Re: Should git help respect the 'pager' setting?

2013-05-30 Thread Matthieu Moy
Michael Campbell michael.campb...@gmail.com writes: I have my global git config pager set to 'cat', but when I do a git help command, it still uses a pager. This is especially irksome in emacs shell buffers, where I am most of the time. I know I can do a M-x man - git-whatever, but wondered

Re: Poor performance of git describe in big repos

2013-05-30 Thread Thomas Rast
Thomas Rast tr...@inf.ethz.ch writes: I had a brief look around sha1_file.c, in particular sha1_object_info, and it turns out we lack the deflate only early part logic as I suspected. So that'll have to be fixed first. After that I *think* it should automatically carry over into the tag

Re: Should git help respect the 'pager' setting?

2013-05-30 Thread Ramkumar Ramachandra
Matthieu Moy wrote: Michael Campbell michael.campb...@gmail.com writes: I have my global git config pager set to 'cat', but when I do a git help command, it still uses a pager. This is especially irksome in emacs shell buffers, where I am most of the time. I know I can do a M-x man -

Re: Should git help respect the 'pager' setting?

2013-05-30 Thread Matthieu Moy
Ramkumar Ramachandra artag...@gmail.com writes: It just needs to set $PAGER or $MANPAGER before the exec(), no? Yes, that should do the same as man -P. I would argue that it should do this. $GIT_PAGER works everywhere else, but obviously man has no knowledge about it. I find it a bit weird

Re: Should git help respect the 'pager' setting?

2013-05-30 Thread Ramkumar Ramachandra
Matthieu Moy wrote: I find it a bit weird that Git sets the configuration for external commands, but it may make sense. No strong opinion here. I don't mean a setenv() kind of thing: how would we unset it after that? Perhaps something like execvpe(), passing in the environment as an argument?

Re: Should git help respect the 'pager' setting?

2013-05-30 Thread John Keeping
On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote: Matthieu Moy wrote: I find it a bit weird that Git sets the configuration for external commands, but it may make sense. No strong opinion here. I don't mean a setenv() kind of thing: how would we unset it after that?

Re: t0008-ignores failure (was: [msysGit] Git for Windows 1.8.3)

2013-05-30 Thread Johannes Schindelin
Hi Pat, On Thu, 30 May 2013, Pat Thoyts wrote: On 30 May 2013 16:15, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Thu, 30 May 2013, Karsten Blees wrote: Am 25.05.2013 21:16, schrieb Pat Thoyts: On that note -- with this merge as it now stands I get the following test

Re: Poor performance of git describe in big repos

2013-05-30 Thread Antoine Pelisse
The culprit, according to some callgrind investigation, is lookup_commit_reference_gently() [for the unannotated case] or deref_tag() [annotated case] calling parse_object(). Using the scenario you described earlier, I think it ends-up spending most of its time in check_sha1_signature (both

  1   2   >