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
> non-identical, and the non-i
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 majord..
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 majord...@vger.ker
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
> ---
> This v4 contains only the split-index options and appli
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 compreh
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 lying around from a
random
'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 parent
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 the parents. Fix by copying the merge if at least
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 17:18:06.304699181 +
> +++
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 th
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 performed.
>>
>> Also when we know that mtime is not sup
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, and the non-identical parent is
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 iden
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 supported by the environment,
> for
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 wonder where the memory used for untracked cache goes
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 6f6b289..246b3d3 100644
> --- a/builtin/update-index.c
>
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
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
> never use the untracked cac
"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 format.
>
> My idea was to futu
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
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 against the single hash on the
>> >
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 additional test fail only under prove but pass
>
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 b/builtin/update-index.c
ind
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 253160a..f0af41c 100755
--- a/t/t7063-sta
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
+++ b/builtin/update-index.c
@@ -35,6 +35,1
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
@@ -1116,8 +1116,6 @@ int cmd_u
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 --
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 ove
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(-)
diff --git a/Documentation
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
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 a/builtin/update-index.c b/built
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 for me. Some mysterious variable leaks
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.
>>
>> Can you outl
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
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 keeping an orig
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
> now I can only reprod
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 commit message (thanks Luk
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 Schneider
Helped-by: Pete Harlan
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 messages typically are compo
39 matches
Mail list logo