Re: [PATCH v3 1/2] auto gc: don't write bitmaps for incremental repacks

On Fri, Dec 23, 2016 at 08:08:54PM -0500, David Turner wrote: > + git gc --auto 2>err && > + test_i18ngrep ! "^warning:" err && > + ls .git/objects/pack/ | grep -v bitmap | sort >post_packs && I'm not sure why you omit the bitmap here. It shouldn't change, right? In that case it

[PATCH v3 0/2] pack bitmaps and incremental packing

Cleaned up the first patch's test code. Decided to remove the unnecessary checks from the second patch. David Turner (2): auto gc: don't write bitmaps for incremental repacks repack: die on incremental + write-bitmap-index builtin/gc.c| 9 - builtin/repack.c| 9

[PATCH v3 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 8 +++- 2 files changed, 12 insertions(+), 5

[PATCH v3 1/2] auto gc: don't write bitmaps for incremental repacks

When git gc --auto does an incremental repack of loose objects, we do not expect to be able to write a bitmap; it is very likely that objects in the new pack will have references to objects outside of the pack. So we shouldn't try to write a bitmap, because doing so will likely issue a warning.

Re: What's cooking in git.git (Dec 2016, #07; Thu, 22)

> On 22 Dec 2016, at 23:18, Junio C Hamano wrote: > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On Fri, Dec 23, 2016 at 2:21 PM, Jeff King wrote: > On Fri, Dec 23, 2016 at 01:17:03PM -0800, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >> > I guess both you and Michael are in favor of just removing compaction >> > variant without any renames, so let

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On Fri, Dec 23, 2016 at 01:17:03PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > I guess both you and Michael are in favor of just removing compaction > > variant without any renames, so let me prepare a reroll and queue > > that instead. We can flip the

Re: [PATCH v2 2/2] repack: die on incremental + write-bitmap-index

On Fri, Dec 23, 2016 at 02:43:35PM -0500, David Turner wrote: > The bitmap index only works for single packs, so requesting an > incremental repack with bitmap indexes makes no sense. OK. I doubt this will come up much after the git-gc change from the first patch. And it should already be

Re: [PATCH v2 1/2] auto gc: don't write bitmaps for incremental repacks

On Fri, Dec 23, 2016 at 02:43:34PM -0500, David Turner wrote: > When git gc --auto does an incremental repack of loose objects, we do > not expect to be able to write a bitmap; it is very likely that > objects in the new pack will have references to objects outside of the > pack. So we shouldn't

Re: [PATCH v2 1/2] auto gc: don't write bitmaps for incremental repacks

David Turner writes: > +test_expect_success 'auto gc with too many loose objects does not attempt to > create bitmaps' ' > + test_config gc.auto 3 && > + test_config gc.autodetach false && > + test_config pack.writebitmaps true && > + # We need to create

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

Junio C Hamano writes: > I guess both you and Michael are in favor of just removing compaction > variant without any renames, so let me prepare a reroll and queue > that instead. We can flip the default perhaps one release later. -- >8 -- Subject: [PATCH] diff: retire

[PATCH v2 1/2] auto gc: don't write bitmaps for incremental repacks

When git gc --auto does an incremental repack of loose objects, we do not expect to be able to write a bitmap; it is very likely that objects in the new pack will have references to objects outside of the pack. So we shouldn't try to write a bitmap, because doing so will likely issue a warning.

[PATCH v2 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 5 +++-- 2 files changed, 12 insertions(+), 2 deletions(-)

Re: [PATCH] mingw: add a regression test for pushing to UNC paths

Am 23.12.2016 um 18:11 schrieb Johannes Schindelin: Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. Clever!

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

Jeff King writes: > On Fri, Dec 23, 2016 at 12:12:13AM -0800, Jacob Keller wrote: > >> I actually would prefer that we just say "this is the default now" and >> provide some knob "no-indent-heuristic" or "no-compaction-heuristic" >> and go with that, I think, since I am pretty

Re: What's cooking in git.git (Dec 2016, #07; Thu, 22)

Duy Nguyen writes: > On Fri, Dec 23, 2016 at 5:18 AM, Junio C Hamano wrote: >> Will merge to 'next'. >> - nd/config-misc-fixes 12-22 >> #3 > > Hold it. You made a comment about rollback lockfile on

[PATCH] mingw: add a regression test for pushing to UNC paths

On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression

Re: git 2.11.0 error when pushing to remote located on a windows share

Hi, On Tue, 6 Dec 2016, Torsten Bögershausen wrote: > On 2016-12-05 12:05, thomas.attw...@stfc.ac.uk wrote: > > On Sun, 4 Dec 2016 08:09:14 +, Torsten Bögershausen wrote: > >> There seems to be another issue, which may or may not being related: > >>

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On Fri, Dec 23, 2016 at 12:12:13AM -0800, Jacob Keller wrote: > I actually would prefer that we just say "this is the default now" and > provide some knob "no-indent-heuristic" or "no-compaction-heuristic" > and go with that, I think, since I am pretty sure we're all in > agreement that the

Re: [PATCH v2 1/3] mingw: adjust is_console() to work with stdin

Hi Dscho On 2016-12-23 10:30, Johannes Schindelin wrote: Hi Beat, On Fri, 23 Dec 2016, Beat Bolli wrote: On 22.12.16 18:08, Johannes Schindelin wrote: > diff --git a/compat/winansi.c b/compat/winansi.c > index cb725fb02f..590d61cb1b 100644 > --- a/compat/winansi.c > +++ b/compat/winansi.c >

Hello

Hello, Complement of the Season, I'M Anessa female 25 years old single, I am contacting you because I will be relocating to your country. I will send you my photos and also tell you much about my self. Thanks. Sincerely yours Anessa.

Re: What's cooking in git.git (Dec 2016, #07; Thu, 22)

On Fri, Dec 23, 2016 at 5:18 AM, Junio C Hamano wrote: > Will merge to 'next'. > - nd/config-misc-fixes 12-22 > #3 Hold it. You made a comment about rollback lockfile on uninitialized variable or something but I haven't time

Re: [PATCH v2 1/3] mingw: adjust is_console() to work with stdin

Hi Beat, On Fri, 23 Dec 2016, Beat Bolli wrote: > On 22.12.16 18:08, Johannes Schindelin wrote: > > diff --git a/compat/winansi.c b/compat/winansi.c > > index cb725fb02f..590d61cb1b 100644 > > --- a/compat/winansi.c > > +++ b/compat/winansi.c > > @@ -84,6 +84,7 @@ static void

Re: [RFC/PATCH] add diffstat information to rebase

On Thu, Dec 22, 2016 at 2:37 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> $ git rebase -i HEAD^^ >> >> pick 2eaa3f532c Third batch for 2.12 >> # Documentation/RelNotes/2.12.0.txt | 40 >> +++ >>

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On Thu, Dec 22, 2016 at 11:22 PM, Jeff King wrote: > On Thu, Dec 22, 2016 at 01:12:12PM -0800, Junio C Hamano wrote: > >> Jacob Keller writes: >> >> > I don't think we have too many config options that interact in this >> > way, so I understand that "last