Re: [PATCH v2 0/4] Port git-add--interactive.perl:status_cmd to C

Hi Daniel, On 16-May-17 6:00 AM, Daniel Ferreira wrote: This is the second version of a patch series to start porting git-add--interactive from Perl to C. Series: v1: https://public-inbox.org/git/1494009820-2090-1-git-send-email-bnm...@gmail.com/ Travis CI build:

Re: [PATCH v2 0/4] Multiple subtree split fixes regarding complex repos

Roger Strain writes: > After doing some testing at scale, determined that one call was > taking too long; replaced that with an alternate call which > returns the same data significantly faster. Curious where the time goes. Do you know? > Also, if anyone has any other feedback on these I'd

[PATCH v2 0/4] Multiple subtree split fixes regarding complex repos

After doing some testing at scale, determined that one call was taking too long; replaced that with an alternate call which returns the same data significantly faster. Also, if anyone has any other feedback on these I'd really love to hear it. It's working better for us (as in, it actually

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

Josh Steadmon writes: > Yes, the version on my desktop sends version=2 when archiving: > > ∫ which git > /usr/bin/git > ∫ git --version > git version 2.19.0.605.g01d371f741-goog > ∫ GIT_TRACE_PACKET=${HOME}/server_trace git daemon \ > --enable=upload-archive \ >

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

On 2018.09.27 15:20, Junio C Hamano wrote: > Jonathan Nieder writes: > > > 1. Clients sending version=2 when they do not, in fact, speak protocol > > v2 for a service is a (serious) bug. (Separately from this > > series) we should fix it. > > > > 2. That bug is already in the wild,

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

Jonathan Nieder writes: > 1. Clients sending version=2 when they do not, in fact, speak protocol > v2 for a service is a (serious) bug. (Separately from this > series) we should fix it. > > 2. That bug is already in the wild, alas. Fortunately the semantics of > GIT_PROTOCOL as a

Re: [RFC PATCH v2 0/4] Avoid ls-refs when possible in protocol v2

Jonathan Tan writes: > To answer Junio's questions in [1], I think it's best to include the > full patch set that I'm developing, so here it is. The original patch is > now patch 3 of this set. Yeah, taking it out of context did make its purpose fuzzy. Without the other patches in the series

[RFC PATCH v2 0/4] Avoid ls-refs when possible in protocol v2

To answer Junio's questions in [1], I think it's best to include the full patch set that I'm developing, so here it is. The original patch is now patch 3 of this set. [1] https://public-inbox.org/git/xmqq8t3pnphe@gitster-ct.c.googlers.com/ Rearranging Junio's questions: > ... ah, do you

Re: [PATCH v2 0/4] git-commit-graph.txt: various cleanups

Hi Derrick On Thu, 27 Sep 2018 at 21:16, Derrick Stolee wrote: > Thanks! This version satisfies my concerns and looks good to me. > > Reviewed-by: Derrick Stolee Thanks for the spectacularly snappy review. I don't expect commit graphs to help my use cases a lot, but I still wanted to try them

Re: [PATCH v2 0/4] git-commit-graph.txt: various cleanups

On 9/27/2018 3:12 PM, Martin Ågren wrote: This v2 starts with the same two patches as v1 did, then goes on to change "[commit] graph file" to "commit-graph file" with a dash, to match other instances as well as Derrick's feedback. Thanks! This version satisfies my concerns and looks good to me.

[PATCH v2 0/4] git-commit-graph.txt: various cleanups

This v2 starts with the same two patches as v1 did, then goes on to change "[commit] graph file" to "commit-graph file" with a dash, to match other instances as well as Derrick's feedback. Martin Ågren (4): git-commit-graph.txt: fix bullet lists git-commit-graph.txt: typeset more in monospace

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

On 2018.09.27 11:20, Stefan Beller wrote: > On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote: > > > > This is the second version of my series to add a new protocol v2 command > > for archiving, with support for HTTP(S). > > > > NEEDSWORK: a server built with this series is not

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

Stefan Beller wrote: > On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote: >> I've been discussing workarounds for this with Jonathan Nieder, but >> please let me know if you have any suggestions for v3 of this series. > > Care to open the discussion to the list? What are the different >

Re: [PATCH v2 0/4] Add proto v2 archive command with HTTP support

On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote: > > This is the second version of my series to add a new protocol v2 command > for archiving, with support for HTTP(S). > > NEEDSWORK: a server built with this series is not backwards-compatible > with clients that set GIT_PROTOCOL=version=2 or

[PATCH v2 0/4] Add proto v2 archive command with HTTP support

This is the second version of my series to add a new protocol v2 command for archiving, with support for HTTP(S). NEEDSWORK: a server built with this series is not backwards-compatible with clients that set GIT_PROTOCOL=version=2 or configure protocol.version=2. The old client will

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

Hi, On Mon, 6 Aug 2018, Eric Sunshine wrote: > On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga > wrote: > > But your suggestion did make me think about what behaviour I would > > like to see, exactly. I like that Git removes commits that no longer > > serve any purpose (because I've included

[PATCH v2 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon. Turns out that it is not a Windows-specific issue, even if it occurs a lot more often on Windows than elsewhere. (And even if it is apparently impossible to trigger on

Re: [PATCH v2 0/4] Speed up unpack_trees()

On Thu, Aug 9, 2018 at 10:16 AM Ben Peart wrote: > In fact, in the other [1] patch series, we're detecting the number of > cache entries that are the same as the cache tree and using that to > traverse_by_cache_tree(). At that point, couldn't we copy the > corresponding cache tree entries over

Re: [PATCH v2 0/4] Speed up unpack_trees()

On Wed, Aug 8, 2018 at 10:53 PM Ben Peart wrote: > > > > On 8/1/2018 12:38 PM, Duy Nguyen wrote: > > On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: > >> > >> > >> On 7/31/2018 12:50 PM, Ben Peart wrote: > >>> > >>> > >>> On 7/31/2018 11:31 AM, Duy Nguyen wrote: > >> > > > In

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 8/8/2018 4:53 PM, Ben Peart wrote: On 8/1/2018 12:38 PM, Duy Nguyen wrote: On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 8/1/2018 12:38 PM, Duy Nguyen wrote: On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair cache-tree is now looking quite

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

Eric Sunshine writes: > On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga > wrote: >> But your suggestion did make me think about what behaviour I would >> like to see, exactly. I like that Git removes commits that no longer >> serve any purpose (because I've included their changes in earlier >>

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga wrote: > But your suggestion did make me think about what behaviour I would > like to see, exactly. I like that Git removes commits that no longer > serve any purpose (because I've included their changes in earlier > commits). So I would not want to

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Tue, Jul 31, 2018 at 11:22 PM, Eric Sunshine wrote: > On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga > wrote: >> On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine >> wrote: >> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit >> > object corruption when "rebase -i

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Wed, Aug 1, 2018 at 7:25 PM brian m. carlson wrote: > On Tue, Jul 31, 2018 at 03:33:27AM -0400, Eric Sunshine wrote: > > This is a re-roll of [1] which fixes sequencer bugs resulting in commit > > object corruption when "rebase -i --root" swaps in a new commit as root. > > Unfortunately, those

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Tue, Jul 31, 2018 at 03:33:27AM -0400, Eric Sunshine wrote: > This is a re-roll of [1] which fixes sequencer bugs resulting in commit > object corruption when "rebase -i --root" swaps in a new commit as root. > Unfortunately, those bugs made it into v2.18.0 and have already > corrupted at least

Re: [PATCH v2 0/4] Speed up unpack_trees()

On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote: > > > On 7/31/2018 12:50 PM, Ben Peart wrote: > > > > > > On 7/31/2018 11:31 AM, Duy Nguyen wrote: > > >> > >>> In the performance game of whack-a-mole, that call to repair cache-tree > >>> is now looking quite expensive... > >> > >>

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga wrote: > On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine > wrote: > > This is a re-roll of [1] which fixes sequencer bugs resulting in commit > > object corruption when "rebase -i --root" swaps in a new commit as root. > > Unfortunately, those bugs

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

Hi Eric, On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine wrote: > This is a re-roll of [1] which fixes sequencer bugs resulting in commit > object corruption when "rebase -i --root" swaps in a new commit as root. > Unfortunately, those bugs made it into v2.18.0 and have already > corrupted at

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 7/31/2018 12:50 PM, Ben Peart wrote: On 7/31/2018 11:31 AM, Duy Nguyen wrote: In the performance game of whack-a-mole, that call to repair cache-tree is now looking quite expensive... Yeah and I think we can whack that mole too. I did some measurement. Best case possible, we just

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 7/31/2018 11:31 AM, Duy Nguyen wrote: On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote: I ran "git checkout" on a large repo and averaged the results of 3 runs. This clearly demonstrates the benefit of the optimized unpack_trees() as even the final "diff-index" is essentially a 3rd

Re: [PATCH v2 0/4] Speed up unpack_trees()

On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote: > I ran "git checkout" on a large repo and averaged the results of 3 runs. > This clearly demonstrates the benefit of the optimized unpack_trees() > as even the final "diff-index" is essentially a 3rd call to unpack_trees(). > > baseline

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Tue, Jul 31, 2018 at 6:46 AM Eric Sunshine wrote: > Anyhow, thanks for reading over the series. I appreciate it even if > our "sense of priority" doesn't always align (as evidenced by your > review comments and my responses). To be clear, the changes you suggest all make sense, and would be

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

Hi Eric On 31/07/18 11:46, Eric Sunshine wrote: > On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood > wrote: >> On 31/07/18 08:33, Eric Sunshine wrote: >>> Patch 2/4 of this series conflicts with Akinori MUSHA's >>> 'am/sequencer-author-script-fix' which takes a stab at fixing one of the >>> four

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood wrote: > On 31/07/18 08:33, Eric Sunshine wrote: > > Patch 2/4 of this series conflicts with Akinori MUSHA's > > 'am/sequencer-author-script-fix' which takes a stab at fixing one of the > > four (or so) bugs fixed by this series (namely, adding a

Re: [PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

Hi Eric On 31/07/18 08:33, Eric Sunshine wrote: This is a re-roll of [1] which fixes sequencer bugs resulting in commit object corruption when "rebase -i --root" swaps in a new commit as root. Unfortunately, those bugs made it into v2.18.0 and have already corrupted at least one repository (a

[PATCH v2 0/4] fix "rebase -i --root" corrupting root commit

This is a re-roll of [1] which fixes sequencer bugs resulting in commit object corruption when "rebase -i --root" swaps in a new commit as root. Unfortunately, those bugs made it into v2.18.0 and have already corrupted at least one repository (a local project of mine). Patches 3/4 and 4/4 are new.

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote: This series speeds up unpack_trees() a bit by using cache-tree. unpack-trees could bit split in three big parts - the actual tree unpacking and running n-way merging - update worktree, which could be expensive depending on how much I/O is

Re: [PATCH v2 0/4] Speed up unpack_trees()

On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote: This series speeds up unpack_trees() a bit by using cache-tree. unpack-trees could bit split in three big parts - the actual tree unpacking and running n-way merging - update worktree, which could be expensive depending on how much I/O is

[PATCH v2 0/4] Speed up unpack_trees()

This series speeds up unpack_trees() a bit by using cache-tree. unpack-trees could bit split in three big parts - the actual tree unpacking and running n-way merging - update worktree, which could be expensive depending on how much I/O is involved - repair cache-tree This series focuses on the

[PATCH v2 0/4] fail compilation with strcpy

On Thu, Jul 19, 2018 at 04:32:59PM -0400, Jeff King wrote: > This is a patch series to address the discussion in the thread at: > > https://public-inbox.org/git/20180713204350.ga16...@sigill.intra.peff.net/ > > Basically, the question was: can we declare strcpy banned and have a > linter save

Re: [PATCH v2 0/4] Automatic transfer encoding for patches

LGTM, thanks for the v2.

[PATCH v2 0/4] Automatic transfer encoding for patches

This series introduces an "auto" value for git send-email --transfer-encoding that uses 8bit when possible (i.e. when lines are 998 octets or shorter) and quoted-printable otherwise; it then makes this the default behavior. It also makes --validate aware of transfer encoding so it doesn't

[GSoC] [PATCH v2 0/4] rebase: rewrite rebase in C

As a GSoC project, I have been working on the builtin rebase. The motivation behind the rewrite of rebase i.e. from shell script to C are for following reasons: 1. Writing shell scripts and getting it to production is much faster than doing the equivalent in C but lacks in performance and

[PATCH v2 0/4] branch -l deprecation revisited

This series replaces the contents of jk/branch-l-0-deprecation, jk/branch-l-1-removal, and jk/branch-l-2-reincarnation. It implements the idea discussed in the subthread in: https://public-inbox.org/git/xmqqzi0hety4@gitster-ct.c.googlers.com/ Namely that "branch -l" would warn about

Re: [RFC PATCH v2 0/4] contrib/credential/netrc Makefile & test improvements

On Tue, Jun 12, 2018 at 11:10 PM Todd Zullinger wrote: > > This replaces my 2/2 "use in-tree Git.pm for tests" with > Luis's improved version. It also adds Luis's fix to ensure > the proper exit status on test failures and a minor > whitespace cleanup. > > Is it alright to forge your signoff

[RFC PATCH v2 0/4] contrib/credential/netrc Makefile & test improvements

This replaces my 2/2 "use in-tree Git.pm for tests" with Luis's improved version. It also adds Luis's fix to ensure the proper exit status on test failures and a minor whitespace cleanup. Is it alright to forge your signoff Luis? Luis Marsano (2): git-credential-netrc: use in-tree Git.pm for

[PATCH v2 0/4] Fix i-t-a entries in git-diff and git-apply

v2 first fixes a bug in --ita-invisible-in-index that accidentally affects diffing a worktree and a tree. This caused a regression when v1's 1/2 turned this option on by default. Other than that, 4/4 should address Junio's comments on v1's 2/2. Nguyễn Thái Ngọc Duy (4): diff: ignore

[GSoC][PATCH v2 0/4] rebase: split rebase -p from rebase -i

This splits the `rebase --preserve-merges` functionnality from git-rebase--interactive.sh. All the dead code left by the duplication of git-rebase--interactive.sh is also removed. This will make it easier to rewrite this script in C. This patch series is based of js/sequencer-and-root-commits.

Re: [PATCH v2 0/4] Fix mem leaks of recent object store conversions.

On Fri, May 11, 2018 at 1:37 AM, Jeff King wrote: > On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote: > >> This series replaces the two commits that were queued on >> sb/object-store-replace, >> fixing memory leaks that were recently introduced. >> >> Compared to v1,

Re: [PATCH v2 0/4] Fix mem leaks of recent object store conversions.

On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote: > This series replaces the two commits that were queued on > sb/object-store-replace, > fixing memory leaks that were recently introduced. > > Compared to v1, I merged the two independent series from yesterday, > rewrote the commit

[PATCH v2 0/4] Fix mem leaks of recent object store conversions.

This series replaces the two commits that were queued on sb/object-store-replace, fixing memory leaks that were recently introduced. Compared to v1, I merged the two independent series from yesterday, rewrote the commit message to clear up Junios confusion and addresses Peffs comments for the

Re: [PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG()

On Wed, May 02, 2018 at 11:38:13AM +0200, Johannes Schindelin wrote: > The BUG() macro was introduced in this patch series: > https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net > > The second patch in that series converted one caller from die("BUG: ") > to use the

[PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG()

The BUG() macro was introduced in this patch series: https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net The second patch in that series converted one caller from die("BUG: ") to use the BUG() macro. It seems that there was no concrete plan to address the same

[PATCH v2 0/4] rebase -i: avoid stale "# This is a combination of" in commit messages

Eric Sunshine pointed out that I had such a commit message in https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov630snqhpv5qgrqdd8mw-syzn...@mail.gmail.com/ and I went on a hunt to figure out how the heck this happened. Turns out that if there is a fixup/squash chain where the *last* command

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

Derrick Stolee writes: > On 4/7/2018 2:40 PM, Jakub Narebski wrote: >> Derrick Stolee writes: >> >> [...] >>> On the Linux repository, performance tests were run for the following >>> command: >>> >>> git log --graph --oneline -1000 >>> >>>

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On Mon, Apr 9, 2018 at 6:15 AM, Derrick Stolee wrote: > I don't understand how folding the patches makes the correctness clearer, > since the rename (1/4) is checked by the compiler and the Coccinelle script > (3/4) only works after that rename is complete. > > The only thing I

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On 4/8/2018 7:18 PM, Junio C Hamano wrote: Jeff King writes: If I were doing it myself, I probably would have folded patches 1 and 3 together. They are touching all the same spots, and it would be an error for any case converted in patch 1 to not get converted in patch 3. I'm

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

Jeff King writes: > If I were doing it myself, I probably would have folded patches 1 and 3 > together. They are touching all the same spots, and it would be an error > for any case converted in patch 1 to not get converted in patch 3. I'm > assuming you caught them all due to

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On 4/7/2018 2:40 PM, Jakub Narebski wrote: Derrick Stolee writes: [...] On the Linux repository, performance tests were run for the following command: git log --graph --oneline -1000 Before: 0.92s After: 0.66s Rel %: -28.3% Adding '-- kernel/' to

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

Derrick Stolee writes: [...] > On the Linux repository, performance tests were run for the following > command: > > git log --graph --oneline -1000 > > Before: 0.92s > After: 0.66s > Rel %: -28.3% > > Adding '-- kernel/' to the command requires loading the

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On Fri, Apr 6, 2018 at 12:21 PM, Jeff King wrote: > On Fri, Apr 06, 2018 at 07:09:30PM +, Derrick Stolee wrote: > >> Derrick Stolee (4): >> treewide: rename tree to maybe_tree >> commit: create get_commit_tree() method >> treewide: replace maybe_tree with accessor methods

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On 4/6/2018 3:21 PM, Jeff King wrote: On Fri, Apr 06, 2018 at 07:09:30PM +, Derrick Stolee wrote: Derrick Stolee (4): treewide: rename tree to maybe_tree commit: create get_commit_tree() method treewide: replace maybe_tree with accessor methods commit-graph: lazy-load trees for

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On Fri, Apr 06, 2018 at 07:09:30PM +, Derrick Stolee wrote: > Derrick Stolee (4): > treewide: rename tree to maybe_tree > commit: create get_commit_tree() method > treewide: replace maybe_tree with accessor methods > commit-graph: lazy-load trees for commits I gave this only a

[PATCH v2 0/4] Lazy-load trees when reading commit-graph

There are several commit-graph walks that require loading many commits but never walk the trees reachable from those commits. However, the current logic in parse_commit() requires the root tree to be loaded. This only uses lookup_tree(), but when reading commits from the commit- graph file, the

[PATCH v2 0/4] Colorize push errors

To help users discern large chunks of white text (when the push succeeds) from large chunks of white text (when the push fails), let's add some color to the latter. The original contribution came in via Pull Request from the Git for Windows project:

Re: [PATCH v2 0/4] Teach `--default` to `git-config(1)`

On Fri, Mar 23, 2018 at 08:55:52PM -0400, Taylor Blau wrote: > Attached is 'v2' of my patch series to add a `--default` option to `git > config`. Thanks, this is looking much better. I did come up with a few suggestions/fixes. Some minor which would make v3 easy, and some that would require

[PATCH v2 0/4] Teach `--default` to `git-config(1)`

Hi, Attached is 'v2' of my patch series to add a `--default` option to `git config`. I have addressed the following concerns since the first iteration: 1. Better motivation in 'builtin/config: introduce `--default`'. (cc: Peff, Eric) 2. Fixed a typo in the message of 'builtin/config:

[PATCH v2 0/4] nd/parseopt-completion fixups

v2 fixes the comments from v1 and adds to new patches to improve _git_notes() (sorry I couldn't resist) Interdiff with what's on 'pu' diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 5f7495cda3..2e30950299 100644 ---

Re: [PATCH v2 0/4] Delete ignore_env member in struct repository

On Tue, Feb 27, 2018 at 1:58 AM, Nguyễn Thái Ngọc Duy wrote: > v2 fixes the incorrect use of consecutive getenv() and adds a comment > to clarify the role of old_gitdir > > Interdiff: > > diff --git a/environment.c b/environment.c > index 95de419de8..47c6e31559 100644 > ---

Re: [PATCH v2 0/4] Delete ignore_env member in struct repository

On Tue, Feb 27, 2018 at 4:58 AM, Nguyễn Thái Ngọc Duy wrote: > v2 fixes the incorrect use of consecutive getenv() and adds a comment > to clarify the role of old_gitdir > > diff --git a/environment.c b/environment.c > @@ -148,18 +149,34 @@ static char *expand_namespace(const

[PATCH v2 0/4] Delete ignore_env member in struct repository

v2 fixes the incorrect use of consecutive getenv() and adds a comment to clarify the role of old_gitdir Interdiff: diff --git a/environment.c b/environment.c index 95de419de8..47c6e31559 100644 --- a/environment.c +++ b/environment.c @@ -14,6 +14,7 @@ #include "fmt-merge-msg.h" #include

[PATCH v2 0/4] making test-suite tracing more useful

This series fixes some rough edges in the "-x" feature of the test suite. With it, it should be possible to turn on tracing for CI runs. This is mostly a repost of v1 at: https://public-inbox.org/git/20171019210140.64lb52cqtgdh2...@sigill.intra.peff.net which had some discussion, but wasn't

[PATCH v2 0/4] Fix issues with rename detection limits

This patchset fixes some issues around rename detection limits. Changes since the original submission[1]: * Patches 2 and 3 are swapped in order so as to not temporarily introduce any bugs (even if only cosmetic) * Commit message fixups * Using uint64_t instead of double for holding

[PATCH v2 0/4] bisect: assorted leak-fixes

This fixes a couple of leaks around `find_bisection(). The first patch is new since v1 [1] to make the calling-convention of `find_bisection()` less prone to misuse. Patch 2 is similar to v1, the only difference is that the "while at it" has moved into patch 1. Patches 3 and 4 are identical to v1.

[PATCH v2 0/4] convert diff flags to be stored in a struct

Changes in v2: * removed the diff_flags_cleared singleton * eliminated the 'touched' parallel flags * pass structs by reference instead of by value Now that the 'touched' flags have been removed it may be valuable to go ahead and remove the macros all together (including making the flags

Re: [PATCH v2 0/4] Hash Abstraction

On Sat, Oct 28, 2017 at 11:12 AM, brian m. carlson wrote: > This is a series proposing a basic abstraction for hash functions. > > As we get closer to converting the remainder of the codebase to use > struct object_id, we should think about the design we want our

Re: [PATCH v2 0/4] fsmonitor fixes

Hi Alex, On Wed, 25 Oct 2017, Alex Vandiver wrote: > Updated based on comments from Dscho and Ben. Thanks for those! Thank you for this excellent improvement. Ciao, Dscho

[PATCH v2 0/4] Hash Abstraction

This is a series proposing a basic abstraction for hash functions. As we get closer to converting the remainder of the codebase to use struct object_id, we should think about the design we want our hash function abstraction to take. This series is a proposal for one idea. Input on any aspect of

[PATCH v2 0/4] fsmonitor fixes

Updated based on comments from Dscho and Ben. Thanks for those! - Alex

[PATCH v2 0/4] filter-branch: support for incremental update + fix for ancient tag format

This is the second version of my patches to add incremental support to git-filter-branch. Since the last time I have: * addressed the review feedback (see changelog embedded in final patch) * switched to using the (newly introduced) `--allow-missing-tagger` option to `git mktag` to allow

Re: [PATCH v2 0/4] Some ThreadSanitizer-results

On 8/21/2017 1:43 PM, Martin Ågren wrote: This is the second version of my series to try to address some issues ... 2) hashmap_add, which I could try my hands on if Jeff doesn't beat me to it -- his proposed change should fix it and I doubt I could come up with anything "better", considering

[GSoC][PATCH v2 0/4] submodule: Incremental rewrite of git-submodules

Changes in v2: * In the function get_submodule_displaypath(), I tried avoiding the extra memory allocation, but it rather invoked test 5 from t7406-submodule-update. The details of the test failiure can be seen in the build report as well. (Build #162) This failure occured as even though

[PATCH v2 0/4] Some ThreadSanitizer-results

This is the second version of my series to try to address some issues noted by ThreadSanitizer. Thanks to all who took the time to provide input on the first version. The largest change is in the third patch, which moves the "avoid writing to slopbuf"-logic into strbuf_setlen, and compiles it

[PATCH v2 0/4] Modernize read_graft_line implementation

Compared to v1: - the first patch is dropped to make it easier to merge - free_graft is now static function in commit.c I don't know, what are exact rules about adding Reviewed-by footer, so I didn't add any. Patryk Obara (4): sha1_file: fix hardcoded size in null_sha1 commit: replace the

[RFC PATCH v2 0/4] Partial clone: promised objects (not only blobs)

Thanks for all your comments on the earlier version. This is a substantially different version. In particular: - Now supports all types (tag, commit, tree) of objects, not only blobs - fsck works - Incorporates Ben Peart's code that uses a long-living process (lifetime of the Git invocation)

Re: [PATCH v2 0/4] reflog-walk fixes for maint

Thanks. All made sense to me after reading them twice.

[PATCH v2 0/4] reflog-walk fixes for maint

On Wed, Jul 05, 2017 at 03:55:08AM -0400, Jeff King wrote: > The first patch is my original small fix with an extra test. I think > that would be appropriate for 'maint'. Its behavior still has some > quirks, but it avoids the confusion that you experienced and has a low > risk of breaking

[PATCH v2 0/4] Improvements to sha1_file

Peff suggested putting in a new field in struct object_info for the object contents; I tried it and it seems to work out quite well. Patch 1 is unmodified from the previous version. Patches 2-3 have been rewritten, and patch 4 is similar except that the missing-lookup change is made to

[PATCH v2 0/4] Port git-add--interactive.perl:status_cmd to C

This is the second version of a patch series to start porting git-add--interactive from Perl to C. Series: v1: https://public-inbox.org/git/1494009820-2090-1-git-send-email-bnm...@gmail.com/ Travis CI build: https://travis-ci.org/theiostream/git/builds/232669894 I have applied most of the

[PATCH v2 0/4] travis-ci: build docs with asciidoctor

Hi, changes since v1: * check Asciidoctor stderr output (Brian) http://public-inbox.org/git/20170418104411.hdkzh3psvej63...@genre.crustytoothpaste.net/ * fix make style nit (Junio) http://public-inbox.org/git/xmqq37dcorr7@gitster.mtv.corp.google.com/ Thanks, Lars Base Ref: master

[PATCH v2 0/4] recursing submodules with relative pathspec (grep and ls-files)

v2 of the series tackles the problem slightly differently than v1 did, and in a less invasive way in my opinion. v1 also didn't fix everything. v2 introduces a way to pass a 'prefix' that is respected by a git process. This allows the git child processes (which operate on submodules) to have the

Re: [PATCH v2 0/4] delete_ref: support reflog messages

Junio C Hamano writes: > These looked reasonable. I had to resolve conflicts with another > topic in flight that removed set_worktree_head_symref() function > while queuing, and I think I resolved it correctly, but please > double check what is pushed out on 'pu'. The merge

Re: [PATCH v2 0/4] delete_ref: support reflog messages

Kyle Meyer writes: > Kyle Meyer (4): > delete_ref: accept a reflog message argument > update-ref: pass reflog message to delete_ref() > rename_ref: replace empty message in HEAD's log > branch: record creation of renamed branch in HEAD's log These looked reasonable. I

Re: [PATCH v2 0/4] delete_ref: support reflog messages

On Mon, Feb 20, 2017 at 08:10:31PM -0500, Kyle Meyer wrote: > Kyle Meyer (4): > delete_ref: accept a reflog message argument > update-ref: pass reflog message to delete_ref() > rename_ref: replace empty message in HEAD's log > branch: record creation of renamed branch in HEAD's log These

[PATCH v2 0/4] delete_ref: support reflog messages

Thanks to Junio and Peff for their feedback on v1. https://public-inbox.org/git/20170217035800.13214-1-k...@kyleam.com/T/#u Changes from v1: * "msg" is now positioned as the first argument to delete_ref() to match update_ref(). 20170217081205.zn7j6d5cffgdv...@sigill.intra.peff.net *

[PATCH v2 0/4] stash: create filename argument

Previous round is at: http://public-inbox.org/git/20170121200804.19009-1-t.gumme...@gmail.com/. Thanks Junio, Peff, Øyvind, Jakub and Johannes for your feedback on the previous round. Changes since the previous round: - Re-phrased the Documentation update. - Added missing $ in 2/3 - Added an

[PATCH v2 0/4] urlmatch: allow regexp-based matches

Hi, This is version two of my patch series. The use case is to be able to configure an HTTP proxy for all subdomains of a domain where there are hundreds of subdomains. Previously, I have been using complete regular expressions with an escape-mechanism to match the configuration key's URLs.

[PATCH v2 0/4] fix mergetool+rerere+subdir regression

If rerere is enabled, no pathnames are given, and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Fix the bug. This regression was introduced in 57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0). Changes since v1: * Patch 2/4 was reworked to improve the

Re: [PATCH v2 0/4] road to reentrant real_path

On Sat, Dec 10, 2016 at 2:42 AM, Brandon Williams wrote: > On 12/09, Duy Nguyen wrote: >> On Fri, Dec 9, 2016 at 6:58 AM, Brandon Williams wrote: >> > diff --git a/setup.c b/setup.c >> > index fe572b8..0d9fdd0 100644 >> > --- a/setup.c >> > +++ b/setup.c >>

  1   2   3   >