[PATCH v3 6/7] t3406: modernize style

Update the following: - Quote 'setup' - Remove blank lines within test case body - Use test_commit instead of custom quick_one - Create branch "topic" from tag created by test_commit --- t/t3406-rebase-message.sh | 30 +- 1 file changed, 9 insertions(+), 21 deletio

[PATCH v3 7/7] tests: move test for rebase messages from t3400 to t3406

t3406 is supposed to test "messages from rebase operation", so let's move tests in t3400 that fit that description into 3406. Most of the functionality they tested, except for the messages, has now been subsumed by t3420. --- t/t3400-rebase.sh | 22 -- t/t3406-rebase-me

[PATCH v3 5/7] add tests for rebasing merged history

--- t/t3400-rebase.sh | 31 + t/t3401-rebase-partial.sh | 45 --- t/t3404-rebase-interactive.sh | 10 +- t/t3409-rebase-preserve-merges.sh | 53 t/t3425-rebase-topology-merges.sh | 252 ++ 5 files changed, 254 ins

[PATCH v3 4/7] add tests for rebasing root

--- t/t3420-rebase-topology-linear.sh | 129 ++ 1 file changed, 129 insertions(+) diff --git a/t/t3420-rebase-topology-linear.sh b/t/t3420-rebase-topology-linear.sh index 81e3d59..659a7b3 100755 --- a/t/t3420-rebase-topology-linear.sh +++ b/t/t3420-rebase-topo

[PATCH v3 2/7] add tests for rebasing with patch-equivalence present

--- t/lib-rebase.sh | 17 t/t3420-rebase-topology-linear.sh | 85 +++ 2 files changed, 102 insertions(+) diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh index 62b3887..16eeb1c 100644 --- a/t/lib-rebase.sh +++ b/t/lib-rebase.sh @@ -80,3

[PATCH v3 0/7] Rebase topology test

Patches are now expected to be dropped iff they are on upstream. I've also followed all of Johannes's other suggestions except for the one about topo-order. Martin von Zweigbergk (7): add simple tests of consistency across rebase types add tests for rebasing with patch-equivalence present ad

[PATCH v3 1/7] add simple tests of consistency across rebase types

Helped-by: Johannes Sixt --- t/lib-rebase.sh | 15 t/t3420-rebase-topology-linear.sh | 78 +++ 2 files changed, 93 insertions(+) create mode 100755 t/t3420-rebase-topology-linear.sh diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh ind

[PATCH v3 3/7] add tests for rebasing of empty commits

--- t/t3401-rebase-partial.sh | 24 t/t3420-rebase-topology-linear.sh | 58 +++ 2 files changed, 58 insertions(+), 24 deletions(-) diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh index 58f4823..7ba1797 100755 --- a/t/

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

Thomas Rast wrote: > diff --git a/commit.c b/commit.c > index 888e02a..00e8d4a 100644 > --- a/commit.c > +++ b/commit.c > @@ -31,8 +31,12 @@ static struct commit *check_commit(struct object *obj, > struct commit *lookup_commit_reference_gently(const unsigned char *sha1, >

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

Junio C Hamano pobox.com> writes: > * kb/status-ignored-optim-2 (2013-05-29) 1 commit > - dir.c: fix ignore processing within not-ignored directories > > Fix 1.8.3 regressions in the .gitignore path exclusion logic. Hi, I see that the Tested-by line in kb/status-ignored-optim-2 (3973cbd) doe

Re: [PATCH v2 5/7] add tests for rebasing merged history

On Wed, May 29, 2013 at 12:57 AM, Johannes Sixt wrote: > Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: >> +# a---b---c >> +# \ \ >> +# d---e \ >> +#\ \ \ >> +# n---o---w---v >> +# \ >> +# z > >> +#TODO: make

[PATCH v3] credential-osxkeychain: support more protocols

Add protocol imap, imaps, ftp and smtp for credential-osxkeychain. Signed-off-by: Xidorn Quan Acked-by: John Szakmeister Acked-by: Jeff King --- contrib/credential/osxkeychain/git-credential-osxkeychain.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/contrib/

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

On Thu, May 30, 2013 at 10:13 AM, René Scharfe wrote: > 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 >> 'ini

Re: [RFC] reflog: show committer date in verbose mode

2013/5/31 Jiang Xin : > By default, reflog won't show committer date and for some cases won't > show commit log either. It will be helpful to show them all by passing > a more complicated pretty formatter to `git reflog` like this: > > $ git reflog show \ > --pretty="%Cred%h%Creset %gd: %

[RFC] reflog: show committer date in verbose mode

By default, reflog won't show committer date and for some cases won't show commit log either. It will be helpful to show them all by passing a more complicated pretty formatter to `git reflog` like this: $ git reflog show \ --pretty="%Cred%h%Creset %gd: %gs%n >> %Cblue%ci (%cr)%Creset:

[PATCH] git.txt: remove stale comment regarding GIT_WORK_TREE

Official support for specifying --work-tree/GIT_WORK_TREE without --git-dir/GIT_DIR was added with v1.7.4-rc3~2^2~2. Update description of GIT_WORK_TREE to reflect this. Signed-off-by: Chris Rorvick --- Commit ea472c1 made most of the relevant updates. Noticed this while troubleshooting a scri

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

On Fri, May 31, 2013 at 4:22 AM, Jeff King wrote: > On Thu, May 30, 2013 at 10:00:23PM +0200, Thomas Rast wrote: > >> lookup_commit_reference_gently unconditionally parses the object given >> to it. This slows down git-describe a lot if you have a repository >> with large tagged blobs in it: pars

Re: [PATCH v2 24/25] register_ref(): make a copy of the bad reference SHA-1

From: "Michael Haggerty" Sent: Thursday, May 30, 2013 10:51 PM On 05/29/2013 06:53 PM, Junio C Hamano wrote: Michael Haggerty writes: [...] + current_bad_sha1 = xmalloc(20); + hashcpy(current_bad_sha1, sha1); This, together with 18/25, may hint that we want hashdup()? I thought about it,

[PATCH v2 FIXUP 22/25] fixup! string_list_add_refs_by_glob(): add a comment about memory management

Signed-off-by: Michael Haggerty --- Junio, would you mind squashing this patch onto mh/reflife 22/25? notes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/notes.c b/notes.c index 602d956..b69c0b8 100644 --- a/notes.c +++ b/notes.c @@ -932,6 +932,7 @@ static int string_list_add_one_ref(con

Re: [PATCH v2 24/25] register_ref(): make a copy of the bad reference SHA-1

On 05/29/2013 06:53 PM, Junio C Hamano wrote: > Michael Haggerty writes: >> [...] >> +current_bad_sha1 = xmalloc(20); >> +hashcpy(current_bad_sha1, sha1); > > This, together with 18/25, may hint that we want hashdup()? I thought about it, but was surprised that I could on

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

On Thu, May 30, 2013 at 10:00:23PM +0200, Thomas Rast wrote: > lookup_commit_reference_gently unconditionally parses the object given > to it. This slows down git-describe a lot if you have a repository > with large tagged blobs in it: parse_object() will read the entire > blob and verify that it

Re: [PATCH v2 11/25] object_array_remove_duplicates(): rewrite to reduce copying

On 05/29/2013 06:18 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> The old version copied one entry to its destination position, then >> deleted any matching entries from the tail of the array. This >> required the tail of the array to be copied multiple times. It didn't >> affect th

[PATCH 1/2] sha1_file: silence sha1_loose_object_info

sha1_object_info() returns -1 (OBJ_BAD) if it cannot find the object for some reason, which suggests that it wants the _caller_ to report this error. However, part of its work happens in sha1_loose_object_info, which _does_ report errors itself. This is doubly strange because: * packed_object_in

[PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

lookup_commit_reference_gently unconditionally parses the object given to it. This slows down git-describe a lot if you have a repository with large tagged blobs in it: parse_object() will read the entire blob and verify that its sha1 matches, only to then throw it away. Speed it up by checking t

Re: [PATCH v2 00/25] Remove assumptions about each_ref_fn arg lifetimes

On 05/29/2013 10:25 AM, Thomas Rast wrote: > Michael Haggerty writes: > I read the entire series on Monday, and give it an Ack at maybe 90% > confidence level -- sorry, I was short on caffeine and sleep ;-) Thanks very much. I'll buy you a coffee the next time I see you :-) Michael -- Michael

Re: Poor performance of git describe in big repos

On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: > Alex Bennée writes: > > > On 30 May 2013 16:33, Thomas Rast wrote: > >> Alex Bennée 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 > >>

Re: [PATCH v2 22/25] string_list_add_refs_by_glob(): add a comment about memory management

On 05/29/2013 10:21 AM, Thomas Rast wrote: > Michael Haggerty writes: > >> Since string_list_add_one_ref() adds refname to the string list, but >> the lifetime of refname is limited, it is important that the >> string_list passed to string_list_add_one_ref() has strdup_strings >> set. Document t

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

Am 30.05.2013 01:58, schrieb Junio C Hamano: > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits > (merged to 'next' on 2013-04-24 at 6306b29) > + submodule: fix quoting in relative_path() > (merged to 'next' on 2013-04-22 at f211e25) > + submodule: drop the top-level requirement > + rev

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

Am 30.05.2013 01:58, schrieb Junio C Hamano: > * jl/submodule-mv (2013-04-23) 5 commits > (merged to 'next' on 2013-04-23 at c04f574) > + submodule.c: duplicate real_path's return value > (merged to 'next' on 2013-04-19 at 45ae3c9) > + rm: delete .gitmodules entry of submodules removed from t

Re: Poor performance of git describe in big repos

> 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

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

Hi Pat, On Thu, 30 May 2013, Pat Thoyts wrote: > On 30 May 2013 16:15, Johannes Schindelin 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 failures: >

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

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 > t

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

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?

Ramkumar Ramachandra 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 that Git sets

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

Matthieu Moy wrote: > Michael Campbell writes: >> I have my global git config pager set to 'cat', but when I do a "git >> help ", 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-, but wondered if this w

Re: Poor performance of git describe in big repos

Thomas Rast 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 readers. Strik

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

Michael Campbell writes: > I have my global git config pager set to 'cat', but when I do a "git > help ", 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-, but wondered if this was a bug or user > error.

preventing evil merges

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

Should "git help" respect the 'pager' setting?

I have my global git config pager set to 'cat', but when I do a "git help ", 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-, but wondered if this was a bug or user error. ("git --no-pager help " does the sa

Re: Poor performance of git describe in big repos

Alex Bennée writes: > On 30 May 2013 16:33, Thomas Rast wrote: >> Alex Bennée 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.k

Re: Poor performance of git describe in big repos

On 30 May 2013 16:33, Thomas Rast wrote: > Alex Bennée 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 >

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

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: t0008-ignores failure (was: [msysGit] Git for Windows 1.8.3)

On 30 May 2013 16:15, Johannes Schindelin 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 15

Re: Poor performance of git describe in big repos

Alex Bennée 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 in the repo that are r

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

On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: >> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote: >>> Felipe Contreras wrote: On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote: > > A bigger problem (in my opinion) with allowing arbi

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

On Thu, May 30, 2013 at 9:40 AM, René Scharfe wrote: > Am 30.05.2013 14:04, schrieb Felipe Contreras: > >> On Thu, May 30, 2013 at 6:34 AM, René Scharfe >> wrote: >>> >>> The merge functions duplicate entries as needed and they don't free >>> them. Release them in unpack_nondirectories, the same

Re: Poor performance of git describe in big repos

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: t0008-ignores failure (was: [msysGit] Git for Windows 1.8.3)

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 abso

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

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

Re: Poor performance of git describe in big repos

On 30 May 2013 15:32, Ramkumar Ramachandra 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% gi

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

On Thu, May 30, 2013 at 5:54 AM, Johannes Sixt wrote: > Am 30.05.2013 07:30, schrieb Martin von Zweigbergk: >> On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt wrote: >>> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: +# f +# / +# a---b---c---g---h +# \

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

Felipe Contreras wrote: > On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote: >> Felipe Contreras wrote: >>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote: A bigger problem (in my opinion) with allowing arbitrary changes to the meaning of existing commands is that scripts

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

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 --- unpack-trees.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index eff2944..9f19d0

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

Am 30.05.2013 14:04, schrieb Felipe Contreras: On Thu, May 30, 2013 at 6:34 AM, René Scharfe 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

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

Felipe Contreras writes: > First expected, then actual. Ack. That is the prevalent (almost universal, but not quite) style. > Signed-off-by: Felipe Contreras > --- > t/t5407-post-rewrite-hook.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/t/t5407-post-rewrite

Re: Poor performance of git describe in big repos

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 w

Re: Poor performance of git describe in big repos

On 30 May 2013 14:45, Duy Nguyen wrote: > On Thu, May 30, 2013 at 8:34 PM, Alex Bennée wrote: > > Thanks. Can you share "verify-pack -v" output of > pack-a9ba133a6f25ffa74c3c407e09ab030f8745b201.pack? I think you need > to put it somewhere on Internet temporarily as it's likely to exceed > git@v

[PATCH 4/4] sha1_file: trivial style cleanup

Signed-off-by: Felipe Contreras --- 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, off_t obj_offset,

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

dfc has not been initialized at this point. Signed-off-by: Felipe Contreras --- 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 @@ -1040,8 +1040,7 @@ int u

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

Signed-off-by: Felipe Contreras --- 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 index_state *istate, struct cach

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

We are dealing with the 'istate' index, not 'the_index'. Signed-off-by: Felipe Contreras --- 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 @@ -626,7 +626,7 @@ int ad

[PATCH 0/4] Trivial patches

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 +++--- sha1_file

[PATCH] test: fix post rewrite hook report

First expected, then actual. Signed-off-by: Felipe Contreras --- 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 --- a/t/t5407-post-rewrite-hook.sh +++ b

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

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 --- sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index d8f9d30..b9d4b48 100644 --- a

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

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

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

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 have.

Re: Poor performance of git describe in big repos

On Thu, May 30, 2013 at 8:34 PM, Alex Bennée 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 ajb@sloy/x86_64 [work.g

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

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

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

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

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

Before overwriting the destination index, first let's discard it's contents. Signed-off-by: Felipe Contreras --- 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 --- a/unpack-trees.c +++ b/unpack-t

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

We created them, and nobody else is going to destroy them. Signed-off-by: Felipe Contreras --- 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 --- a/unpack-trees.c +++ b/unpack-trees.c

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

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

Re: Poor performance of git describe in big repos

On Thu, May 30, 2013 at 7:29 PM, Alex Bennée 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 [kernel.kallsyms] [k]

Re: Poor performance of git describe in big repos

> 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 ajb-build

Re: Poor performance of git describe in big repos

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: [PATCH 1/4] commit: reload cache properly

On Thu, May 30, 2013 at 7:17 PM, Thomas Rast wrote: > Felipe Contreras writes: > >> We are supposedly adding files, to to which cache if 'the_index' is >> discarded? > [...] >> if (!current_head) { >> discard_cache(); >> + if (read_cache() < 0) >> +

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

On Thu, May 30, 2013 at 7:58 AM, Thomas Rast wrote: > Felipe Contreras writes: > >> On Thu, May 30, 2013 at 7:17 AM, Thomas Rast wrote: >>> Felipe Contreras writes: >>> We are supposedly adding files, to to which cache if 'the_index' is discarded? >>> [...] if (!current_hea

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

Felipe Contreras writes: > On Thu, May 30, 2013 at 7:17 AM, Thomas Rast wrote: >> Felipe Contreras writes: >> >>> We are supposedly adding files, to to which cache if 'the_index' is >>> discarded? >> [...] >>> if (!current_head) { >>> discard_cache(); >>> + if (r

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

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

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

On Thu, May 30, 2013 at 7:17 AM, Thomas Rast wrote: > Felipe Contreras writes: > >> We are supposedly adding files, to to which cache if 'the_index' is >> discarded? > [...] >> if (!current_head) { >> discard_cache(); >> + if (read_cache() < 0) >> +

Re: Poor performance of git describe in big repos

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 garba

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

Felipe Contreras 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")); > return; >

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

On Thu, May 30, 2013 at 7:08 AM, Ramkumar Ramachandra 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 are a >> m

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

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 7/7] unpack-trees: free cache_entry array members for merges

On Thu, May 30, 2013 at 6:34 AM, René Scharfe 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, but.. > @@ -600,9 +600,14 @@

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

Before overwriting the destination index, first let's discard it's contents. Signed-off-by: Felipe Contreras --- 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 --- a/unpack-trees.c +++ b/unpack-t

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

We created them, and nobody else is going to destroy them. Signed-off-by: Felipe Contreras --- 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 --- a/unpack-trees.c +++ b/unpack-trees.c

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

We free each entry, but not the array of entries themselves. Signed-off-by: Felipe Contreras --- 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 @@ -1510,6 +1510,8 @@ int discard_in

[PATCH 1/4] commit: reload cache properly

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

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

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 entr

Re: Poor performance of git describe in big repos

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

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

On Thu, May 30, 2013 at 9:25 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy 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 drop-in fnmatch replaceme

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

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 --- builtin/read-tree.c | 2 +- diff-lib.c | 23 +++--- unpack-trees.c | 91 +++

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

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 4/7] unpack-trees: create working copy of merge entry in merged_entry

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 call

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

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 --- unpack-trees.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/unpack-trees.

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

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 --- unpack-trees.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff

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

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 1/7] cache: mark cache_entry pointers const

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 --- cache.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cache.h

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

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:

  1   2   >