Re: [PATCH v5] blame: add support for --[no-]progress option

On Tue, Nov 24, 2015 at 11:36 PM, Edmundo Carmona Antoranz wrote: > * created struct progress_info in builtin/blame.c > this struct holds the information used to display progress so > that only one additional parameter is passed to > found_guilty_entry(). Commit

[PATCH v2] git-p4: Add option to ignore empty commits

From: Lars Schneider diff to v1: * change the default behavior and replace "ignore empty commits" option with "keep empty commits" (thanks Junio/Luke) --> I kept the original topic name in the subject letter to ease finding v1, ok? * add 'an' to fix grammar in

Re: [PATCH 1/2] git-p4: support multiple depot paths in p4 submit

On 07 Dec 2015, at 19:51, Sam Hocevar wrote: > On Sun, Dec 06, 2015, Lars Schneider wrote: >> Thanks for the patch! Do you see a way to demonstrate the bug in a test case >> similar to t9821 [1]? > > Not yet, I'm afraid. It's proving trickier than expected because for >

[PATCH v2] git-p4: Add option to keep empty commits

From: Lars Schneider A changelist that contains only excluded files due to a client spec was imported as an empty commit. Fix that issue by ignoring these commits. Add option "git-p4.keepEmptyCommits" to make the previous behavior available. Signed-off-by: Lars

Re: [PATCH 1/2] git-p4: support multiple depot paths in p4 submit

On 8 December 2015 at 11:41, Sam Hocevar wrote: > On Tue, Dec 08, 2015, Lars Schneider wrote: > >> > Would a refactor of lib-git-p4.sh (and probably all git-p4 tests) to >> > support multiple depots be acceptable and/or welcome? I prefer to ask >> > before I dig into the task.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

On Mon, Dec 07, 2015 at 11:24:52AM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: > > > On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote: > >> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote: > > [snip] > >> > "--keep-empty" has always been about

Re: [PATCH 1/2] git-p4: support multiple depot paths in p4 submit

On Tue, Dec 08, 2015, Lars Schneider wrote: > > Would a refactor of lib-git-p4.sh (and probably all git-p4 tests) to > > support multiple depots be acceptable and/or welcome? I prefer to ask > > before I dig into the task. > > Can you outline your idea a bit? Are you aware of the following way

Re: [PATCH 3/2] git.c: make sure we do not leak GIT_* to alias scripts

On Mon, Dec 7, 2015 at 7:54 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> Let's hope there will be no third report about this commit.. > > Hmm, why does this additional test fail only under prove but pass > without it? It passes with prove

Re: [PATCH 3/2] git.c: make sure we do not leak GIT_* to alias scripts

On Tue, Dec 08, 2015 at 05:55:20PM +0100, Duy Nguyen wrote: > On Mon, Dec 7, 2015 at 7:54 PM, Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > >> Let's hope there will be no third report about this commit.. > > > > Hmm, why does this

Re: best practices against long git rebase times?

On Mon, Dec 7, 2015 at 11:59 PM, Jeff King wrote: > On Mon, Dec 07, 2015 at 02:56:33PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > You're computing the patch against the parent for each of those 3000 >> > commits (to get a hash of it to compare

Re: [PATCH 2/2] format-patch: add an option to suppress commit hash

"brian m. carlson" writes: >> Don't test "any number of '0'"; test 40 '0's. This is because the >> line format was designed to be usable by things like /etc/magic to >> detect format-patch output, and we want to notice if/when we break >> that aspect of our output

[PATCH 0/8] Untracked cache improvements

Following the previous RFC version of this patch series and the related discussions, here is a new version that tries to improve the untracked cache feature. This patch series implements core.untrackedCache as a bool config variable. When it's true git should always try to use the untracked

[PATCH 5/8] dir: add add_untracked_cache()

This new function will be used in a later patch. Signed-off-by: Christian Couder --- builtin/update-index.c | 11 +-- dir.c | 14 ++ dir.h | 1 + 3 files changed, 16 insertions(+), 10 deletions(-) diff --git

[PATCH 1/8] update-index: add untracked cache notifications

Doing: cd /tmp git --git-dir=/git/somewhere/else/.git update-index --untracked-cache doesn't work how one would expect. It hardcodes "/tmp" as the directory that "works" into the index, so if you use the working tree, you'll never use the untracked cache. With this patch "git update-index

[PATCH 7/8] config: add core.untrackedCache

When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. Also when we know that mtime is not supported by the environment, for example because the repo is shared

[PATCH 2/8] update-index: use enum for untracked cache options

Signed-off-by: Christian Couder --- builtin/update-index.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index 6f6b289..246b3d3 100644 --- a/builtin/update-index.c +++

[PATCH 4/8] update-index: move 'uc' var declaration

Signed-off-by: Christian Couder --- builtin/update-index.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index ecb685d..21f74b2 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@

[PATCH 8/8] t7063: add tests for core.untrackedCache

Signed-off-by: Christian Couder --- t/t7063-status-untracked-cache.sh | 48 +-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh index

[PATCH 6/8] dir: add remove_untracked_cache()

This new function will be used in a later patch. Signed-off-by: Christian Couder --- builtin/update-index.c | 3 +-- dir.c | 6 ++ dir.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/builtin/update-index.c

RE: Why does send-pack call pack-objects for all remote refs?

Your interpretation of my email was correct. As you picked up on, I had a fundamental misunderstanding of what pack-objects was doing. Thanks for the explanation, I have a much better idea of what is going on now. Given my use pattern, it may be reasonable for me to patch in an option to compute

[PATCH 3/8] update-index: add --test-untracked-cache

It is nice to just be able to test if untracked cache is supported without enabling it. Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 9 - builtin/update-index.c | 5 + 2 files changed, 13 insertions(+), 1 deletion(-)

Re: [PATCH 2/8] update-index: use enum for untracked cache options

Christian Couder writes: > Signed-off-by: Christian Couder > --- > builtin/update-index.c | 18 +- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/builtin/update-index.c b/builtin/update-index.c > index

Re: [PATCH 1/8] update-index: add untracked cache notifications

Christian Couder writes: > Doing: > > cd /tmp > git --git-dir=/git/somewhere/else/.git update-index --untracked-cache > > doesn't work how one would expect. It hardcodes "/tmp" as the directory > that "works" into the index, so if you use the working tree, you'll

Re: [PATCH 7/8] config: add core.untrackedCache

Christian Couder writes: > When we know that mtime is fully supported by the environment, we > might want the untracked cache to be always used by default without > any mtime test or kernel version check being performed. > > Also when we know that mtime is not

GPG public keys

Hello, Can you please point me to the public GPG keys used for source code signing? Thanks, Jamie -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/8] dir: add remove_untracked_cache()

Christian Couder writes: > This new function will be used in a later patch. > > Signed-off-by: Christian Couder > --- Up to this step I looked at and they made sense (I am not saying the remainder of the series do not make sense). I however

[PATCH v3] contrib/subtree: fix "subtree split" skipped-merge bug

A bug occurs in 'git-subtree split' where a merge is skipped even when both parents act on the subtree, provided the merge results in a tree identical to one of the parents. Fix by copying the merge if at least one parent is non-identical, and the non-identical parent is not an ancestor of the

Re: [PATCH v4] contrib/subtree: fix "subtree split" skipped-merge bug

On Tue, Dec 8, 2015 at 7:19 PM, Dave Ware wrote: > 'git subtree split' can incorrectly skip a merge even when both parents > act on the subtree, provided the merge results in a tree identical to > one of the parents. Fix by copying the merge if at least one parent is

Re: [PATCH 6/8] dir: add remove_untracked_cache()

On 08.12.15 18:15, Christian Couder wrote: > This new function will be used in a later patch. Why not combine 5/8 with 6/8 into a single patch ? (And please consider to mark the series with v2) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH 5/8] dir: add add_untracked_cache()

On 08.12.15 18:15, Christian Couder wrote: > This new function will be used in a later patch. May be Factor out code into add_untracked_cache(), which will be used in the next commit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH 3/2] git.c: make sure we do not leak GIT_* to alias scripts

Jeff King writes: > It fails for me when run via "make" (with prove or without) but not as > "./t0001-init.sh". Looks like extra variables from my config.mak leak > through: > > $ make t0001-init.sh GIT_TEST_OPTS="-v -i" > [...] > --- expected2015-12-08

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > Christian Couder writes: > >> When we know that mtime is fully supported by the environment, we >> might want the untracked cache to be always used by default without >> any mtime test or kernel version check being

Re: GPG public keys

Jamie Evans writes: > Can you please point me to the public GPG keys used for source code signing? I suspect that you are asking about our project, but instead of throwing you a fish, I'll show you how to catch one yourself. In a copy of linux kernel repository I have

[ANNOUNCE] Git v2.6.4

The latest maintenance release Git v2.6.4 is now available at the usual places, with a handful of fixes that are already in the 'master' front. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.6.4' tag and

[PATCH v4] contrib/subtree: fix "subtree split" skipped-merge bug

'git subtree split' can incorrectly skip a merge even when both parents act on the subtree, provided the merge results in a tree identical to one of the parents. Fix by copying the merge if at least one parent is non-identical, and the non-identical parent is not an ancestor of the identical

Re: [PATCH v3] contrib/subtree: fix "subtree split" skipped-merge bug

On Wed, Dec 9, 2015 at 10:23 AM, Junio C Hamano wrote: > Dave Ware writes: > >> A bug occurs in 'git-subtree split' where a merge is skipped even when >> both parents act on the subtree, provided the merge results in a tree >> identical to one of

Update

Good day, hoping you read this email and respond to me in good time.I do not intend to solicit for funds but your time and energy in using my own resources to assist the less privileged becauseI am medically ill and confined at the moment hence I request your indulgence.I will give you a

Re: [PATCH v4] Documentation/git-update-index: add missing opts to synopsis

On Wed, Nov 25, 2015 at 10:30 AM, Christian Couder wrote: > Split index related options should appear in the 'SYNOPSIS' > section. > > These options are already documented in the 'OPTIONS' section. > > Signed-off-by: Christian Couder > --- >

Re: [PATCH v3] contrib/subtree: fix "subtree split" skipped-merge bug

Dave Ware writes: > A bug occurs in 'git-subtree split' where a merge is skipped even when > both parents act on the subtree, provided the merge results in a tree > identical to one of the parents. Fix by copying the merge if at least > one parent is non-identical,