Re: [PATCH v2 00/21] Read `packed-refs` using mmap()

Hi Peff, On Wed, 20 Sep 2017, Jeff King wrote: > On Tue, Sep 19, 2017 at 08:22:08AM +0200, Michael Haggerty wrote: > > > This branch is also available from my fork on GitHub as branch > > `mmap-packed-refs`. > > > > My main uncertainties are: > > > > 1. Does this code actually work on

Re: [PATCH v2 00/21] Read `packed-refs` using mmap()

On Tue, Sep 19, 2017 at 08:22:08AM +0200, Michael Haggerty wrote: > This branch is also available from my fork on GitHub as branch > `mmap-packed-refs`. > > My main uncertainties are: > > 1. Does this code actually work on Windows? > > 2. Did I implement the new compile-time option correctly?

Re: [PATCH v2 00/21] Read `packed-refs` using mmap()

Hi Michael, On Tue, 19 Sep 2017, Michael Haggerty wrote: > This is v2 of a patch series that changes the reading and caching of the > `packed-refs` file to use `mmap()`. Thanks to Junio, Stefan, and > Johannes for their comments about v1 [1]. Thank you for the new iteration. > The main change

[PATCH v2 00/21] Read `packed-refs` using mmap()

This is v2 of a patch series that changes the reading and caching of the `packed-refs` file to use `mmap()`. Thanks to Junio, Stefan, and Johannes for their comments about v1 [1]. The main change since v1 is to accommodate Windows, which doesn't let you replace a file using `rename()` if the file

Re: [PATCH v2 00/21]

Duy Nguyen writes: > On Sun, May 7, 2017 at 11:20 AM, Junio C Hamano wrote: >> On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: >>> >>> Nguyễn Thái Ngọc Duy writes: >>> >>> > Changes since v1: >>> > >>> > -

Re: [PATCH v2 00/21]

On Sun, May 7, 2017 at 11:20 AM, Junio C Hamano wrote: > On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: >> >> Nguyễn Thái Ngọc Duy writes: >> >> > Changes since v1: >> > >> > - fopen_or_warn() and warn_on_fopen_errors() are

Re: [PATCH v2 00/21]

On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > Changes since v1: > > > > - fopen_or_warn() and warn_on_fopen_errors() are introduced. The > >latter's name is probably not great... > > - A new patch (first

Re: [PATCH v2 00/21]

Nguyễn Thái Ngọc Duy writes: > Changes since v1: > > - fopen_or_warn() and warn_on_fopen_errors() are introduced. The >latter's name is probably not great... > - A new patch (first one) to convert a bunch to using xfopen() > - Fix test failure on Windows, found by

[PATCH v2 00/21]

Changes since v1: - fopen_or_warn() and warn_on_fopen_errors() are introduced. The latter's name is probably not great... - A new patch (first one) to convert a bunch to using xfopen() - Fix test failure on Windows, found by Johannes Sixt - Fix the memory leak in log.c, found by Jeff

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 12:40:29PM -0700, Junio C Hamano wrote: > > Here's that minor tweak, in case anybody is interested. It's less useful > > without that follow-on that touches "eol" more, but perhaps it increases > > readability on its own. > > Yup, the only thing that the original (with

Re: [PATCH v2 00/21] object_id part 7

Jeff King writes: > Here's that minor tweak, in case anybody is interested. It's less useful > without that follow-on that touches "eol" more, but perhaps it increases > readability on its own. Yup, the only thing that the original (with Brian's fix) appears to be more careful

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 01:35:36PM -0400, Jeff King wrote: > I thought I'd knock this out quickly before I forgot about it. But it > actually isn't so simple. > > The main caller in read_head_info() does indeed just pass strlen(line) > as the length in each case. But the cert parser really does

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 11:13:15AM +, brian m. carlson wrote: > > I suggested an additional cleanup around "linelen" in one patch. In the > > name of keeping the number of re-rolls sane, I'm OK if we skip that for > > now (the only reason I mentioned it at all is that you have to justify > >

Re: [PATCH v2 00/21] object_id part 7

Jeff King writes: > On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote: > >> This is part 7 in the continuing transition to use struct object_id. >> >> This series focuses on two main areas: adding two constants for the >> maximum hash size we'll be using (which

Re: [PATCH v2 00/21] object_id part 7

On Tue, Mar 28, 2017 at 03:31:59AM -0400, Jeff King wrote: > I read through the whole series and didn't find anything objectionable. > The pointer-arithmetic fix should perhaps graduate separately. Junio's welcome to take that patch separately if he likes. > I suggested an additional cleanup

Re: [PATCH v2 00/21] object_id part 7

On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote: > This is part 7 in the continuing transition to use struct object_id. > > This series focuses on two main areas: adding two constants for the > maximum hash size we'll be using (which will be suitable for allocating > memory) and

[PATCH v2 00/21] object_id part 7

This is part 7 in the continuing transition to use struct object_id. This series focuses on two main areas: adding two constants for the maximum hash size we'll be using (which will be suitable for allocating memory) and converting struct sha1_array to struct oid_array. The rationale for adding

Re: [PATCH v2 00/21] Add configuration options for split-index

On Mon, Dec 19, 2016 at 1:02 PM, Duy Nguyen wrote: > On Sat, Dec 17, 2016 at 03:55:26PM +0100, Christian Couder wrote: >> Goal >> >> >> We want to make it possible to use the split-index feature >> automatically by just setting a new "core.splitIndex" configuration >>

Re: [PATCH v2 00/21] Add configuration options for split-index

Duy Nguyen writes: > I've read through the series (*) and I think it looks good, just a few > minor comments here and there. > > (*) guiltily admit that I only skimmed through tests, not giving them > as much attention as I should have OK. I'd still want to see them get

Re: [PATCH v2 00/21] Add configuration options for split-index

On Sat, Dec 17, 2016 at 03:55:26PM +0100, Christian Couder wrote: > Goal > > > We want to make it possible to use the split-index feature > automatically by just setting a new "core.splitIndex" configuration > variable to true. > > This can be valuable as split-index can help significantly

Re: [PATCH v2 00/21] Add configuration options for split-index

> The previous versions were: > > RFC: https://github.com/chriscool/git/commits/config-split-index7 > v1: https://github.com/chriscool/git/commits/config-split-index72 The diff since v1 is: diff --git a/Documentation/config.txt b/Documentation/config.txt index 8fbef25cb1..52a3cac4ff 100644

[PATCH v2 00/21] Add configuration options for split-index

Goal We want to make it possible to use the split-index feature automatically by just setting a new "core.splitIndex" configuration variable to true. This can be valuable as split-index can help significantly speed up `git rebase` especially along with the work to libify `git apply` that

[PATCH v2 00/21] git bisect improvements

Hi, a long time ago[1] I sent the first version of this patchset to the list. Since then I wrote different variants of the algorithm, fixed some bugs, made the tests work ;), and finally performed some performance tests to pick the best version of the different variants. For the performance

Re: [PATCH v2 00/21] Support multiple worktrees

On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote: Do we even need to expose them as ref-like things as a part of the external API/UI in the first place? For

Re: [PATCH v2 00/21] Support multiple worktrees

Duy Nguyen pclo...@gmail.com writes: On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote: Do we even need to expose them as ref-like things as a part of the external API/UI in the first place? For end-user scripts that want to operate in a real or borrowing worktree,

Re: [PATCH v2 00/21] Support multiple worktrees

On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: I am not happy with the choice of main/HEAD that would squat on a good name for remote-tracking branch (i.e. s/origin/main/), though. $GIT_DIR/COMMON_HEAD perhaps? It's not just

Re: [PATCH v2 00/21] Support multiple worktrees

Duy Nguyen pclo...@gmail.com writes: I am not happy with the choice of main/HEAD that would squat on a good name for remote-tracking branch (i.e. s/origin/main/), though. $GIT_DIR/COMMON_HEAD perhaps? It's not just about HEAD. Anything worktree-specific of the main checkout can be accessed

Re: [PATCH v2 00/21] Support multiple worktrees

Duy Nguyen pclo...@gmail.com writes: I've got a better version [1] that fixes everything I can think of (there's still some room for improvements). I'm going to use it a bit longer before reposting again. But here's its basic design without going down to code New .git file format includes

Re: [PATCH v2 00/21] Support multiple worktrees

On Sat, Dec 21, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: I've got a better version [1] that fixes everything I can think of (there's still some room for improvements). I'm going to use it a bit longer before reposting again. But here's its

Re: [PATCH v2 00/21] Support multiple worktrees

I've got a better version [1] that fixes everything I can think of (there's still some room for improvements). I'm going to use it a bit longer before reposting again. But here's its basic design without going down to code New .git file format includes two lines: -- 8 -- gitid: id gitdir: path --

[PATCH v2 00/21] Support multiple worktrees

The UI and behavior are taking shape now. On the UI side, you do git checkout --to /somewhere -b newbranch origin/master which will create worktree-only repo at /somewhere. git prune --repos could be used to remove cruft in .git/repos. On the behavior side, you should be able to do everything

Re: [PATCH v2 00/21] Support multiple worktrees

On Sat, Dec 14, 2013 at 5:54 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Known issues Scripts that expand $GIT_DIR/objects and are not aware about the new env variable. I introduced test-path-utils --git-path to test git_path(). I could move it to git rev-parse --git-path for use in