Nguyễn Thái Ngọc Duy writes:
> v2 changes the subject line to help clarify in "git log --oneline"
Some were not straight-forward converison, but nevertheless looked
correct. Thanks.
>
> Nguyễn Thái Ngọc Duy (21):
> diff-parseopt: convert --patch-with-raw
> diff-parseopt: convert --numstat
v2 changes the subject line to help clarify in "git log --oneline"
Nguyễn Thái Ngọc Duy (21):
diff-parseopt: convert --patch-with-raw
diff-parseopt: convert --numstat and --shortstat
diff-parseopt: convert --dirstat and friends
diff-parseopt: convert --check
diff-parseopt: convert --summ
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 Windows
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? (
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 s
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
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:
>>> >
>>> > - fopen_or_warn() and warn_on_fopen_errors() are introduced. The
>>> >latter's
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 introduced. The
>> >latter's name is probably not great...
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 one) to convert a bunch to using xfopen
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 Johannes Sixt
> - Fix t
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
There
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 Bri
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 about is it tries
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 n
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
> > t
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 will be suitable fo
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 arou
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
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 s
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
>> variable to true.
>>
>>
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 reviewed, though. P
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 s
> 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
-
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 has
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 tests
On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano 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 operat
Duy Nguyen writes:
> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano 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, there should be no
>> reason t
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano wrote:
> Duy Nguyen 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
Duy Nguyen 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 this wa
On Sat, Dec 21, 2013 at 3:32 AM, Junio C Hamano wrote:
> Duy Nguyen 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
>> goi
Duy Nguyen 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 two lines:
>
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:
gitdir:
-- 8< --
On Sat, Dec 14, 2013 at 5:54 PM, Nguyễn Thái Ngọc Duy 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
scripts, but ther
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 everythin
Changes:
- The incorrect patch 'pathspec: make sure the prefix part is
wildcard-clean' is removed. I want to keep this series simple.
Complex pathspec manipulation will have its own series later.
- Fix t7400.38 failure when core.ignorecase is on. We should exercise
core.ignorecase codepath
35 matches
Mail list logo
