Re: difflame improvements

On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz wrote: > On Thu, Feb 16, 2017 at 11:17 PM, Jeff King wrote: > >> This isn't difflame's fault; that's what "git blame" tells you about >> that line. But since I already told difflame "v2.6.5..HEAD", it

Re: [PATCH] git-check-ref-format: fix typo in man page

On Sun, Feb 19, 2017 at 12:20:33AM -, Philip Oakley wrote: > > Normalize 'refname' by removing any leading slash (`/`) > > characters and collapsing runs of adjacent slashes between > > - name components into a single slash. Iff the normalized > > + name components into a single slash. If

[PATCH] fetch: print an error when declining to request an unadvertised object

Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't allow requests for unadvertised objects by sha1. The more common case of requesting a nonexistent ref normally triggers a die() in get_fetch_map, so "git fetch" wasn't bothering to check after the fetch that it got all the

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

On Sun, 2017-02-12 at 15:49 -0800, Junio C Hamano wrote: > The fact that we have the above two choices tells me that a two-step > approach may be an appropriate approach. [...] > Even if you did only the first step, as long as the second step can > be done without reverting what the first step

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Junio C Hamano writes: > ... > So, let's give Pranit a concrete "here is what we want to see > squashed in", while you guys discuss peculiarity with various > platforms and their system headers, which admittedly is a more > interesting tangent ;-) > > There are early returns

Re: [PATCH] git-check-ref-format: fix typo in man page

From: "Damien Regad" --- Documentation/git-check-ref-format.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 8611a99..377c85a 100644 ---

RE: [PATCH 3/5] name-hash: precompute hash values during preload-index

From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano > > The fact that each preload_thread() still walks the index in-order > makes me wonder if it may allow us to further optimize the "dir" > part of the hash by passing the previous ce for which we already > precomputed

Re: [PATCH] git-check-ref-format: fix typo in man page

On Sat, Feb 18, 2017 at 2:47 PM, Damien Regad wrote: > > --- > Documentation/git-check-ref-format.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/git-check-ref-format.txt > b/Documentation/git-check-ref-format.txt > index

RE: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano > Jeff King writes: >> On Wed, Feb 15, 2017 at 09:27:53AM -0500, Jeff Hostetler wrote: >> >>> I have some informal numbers in a spreadsheet. I was seeing >>> a 8-9% speed up on a status on my gigantic

RE: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

> Jeff King writes: > >> On Fri, Feb 17, 2017 at 09:58:21PM -0800, Junio C Hamano wrote: >> >>> Jeff Hostetler writes: >>> >>> > I'll try to put together a before/after perf-test to better >>> > demonstrate this. >>> >>> I didn't pick up the series while

[PATCH] git-check-ref-format: fix typo in man page

--- Documentation/git-check-ref-format.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 8611a99..377c85a 100644 --- a/Documentation/git-check-ref-format.txt +++

Re: Git bisect does not find commit introducing the bug

Am 18.02.2017 um 19:36 schrieb Alex Hoffman: Let's consider your example with distinct names for nodes: --o1--o2--o3--G--X1 \\ x1--x2--x3--x4--X2--B-- It makes sense that git bisect is expecting a single transition, as this is a precondition for a binary search to

Re: Git bisect does not find commit introducing the bug

On 18 February 2017 at 10:36, Alex Hoffman wrote: > You definitely convinced me that git MUST search more than only in the > paths between good and bad commits, as the good commit G does not have > to be the first good commit (thank you for that). My problem/confusion > is that it

Re: Git bisect does not find commit introducing the bug

From: "Alex Hoffman" But this is not how Git works. Git computes graph differences, i.e., it subtracts from the commits reachable from v.bad those that are reachable from v.good. This leaves more than just those on some path from v.good to v.bad. And it should work this way.

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Jeff King writes: > On Fri, Feb 17, 2017 at 09:58:21PM -0800, Junio C Hamano wrote: > >> Jeff Hostetler writes: >> >> > I'll try to put together a before/after perf-test to better >> > demonstrate this. >> >> I didn't pick up the series while watching

Re: [PATCH v3 02/19] builtin/diff-tree: convert to struct object_id

On Sat, Feb 18, 2017 at 07:12:18PM +, brian m. carlson wrote: > On Fri, Feb 17, 2017 at 10:15:31PM -0500, Jeff King wrote: > > So for this case, something like the patch below. > > > > Incidentally, there's an off-by-one in the original loop of > > stdin_diff_commit that reads past the end

Re: Git bisect does not find commit introducing the bug

On Sat, Feb 18, 2017 at 7:36 PM, Alex Hoffman wrote: >> But this is not how Git works. Git computes graph differences, i.e., it >> subtracts from the commits reachable from v.bad those that are reachable >> from v.good. This leaves more than just those on some path from v.good to >>

Re: [PATCH v3 02/19] builtin/diff-tree: convert to struct object_id

On Fri, Feb 17, 2017 at 10:15:31PM -0500, Jeff King wrote: > So for this case, something like the patch below. > > Incidentally, there's an off-by-one in the original loop of > stdin_diff_commit that reads past the end of the trailing NUL for the > final sha1 on the line. The problem is the: > >

Re: Git bisect does not find commit introducing the bug

> But this is not how Git works. Git computes graph differences, i.e., it > subtracts from the commits reachable from v.bad those that are reachable > from v.good. This leaves more than just those on some path from v.good to > v.bad. And it should work this way. Consider this history: > >

Re: Git bisect does not find commit introducing the bug

Am 18.02.2017 um 12:15 schrieb Alex Hoffman: No one commented the fact, that I find this very confusing. Don't you find this confusing? I will underline, that 'git bisect good v.good' will fail if the commit 'v.good' is not a parent of the bad commit, meaning there MUST be at least a path

[PATCH v4 15/15] refs: rename get_ref_store() to get_submodule_ref_store() and make it public

This function is intended to replace *_submodule() refs API. It provides a ref store for a specific submodule, which can be operated on by a new set of refs API. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 12 refs.h | 11

[PATCH v4 13/15] refs: move submodule code out of files-backend.c

files-backend is now initialized with a $GIT_DIR. Converting a submodule path to where real submodule gitdir is located is done in get_ref_store(). The new code in init_submodule_ref_store() is basically a copy of strbuf_git_path_submodule(). This gives a slight performance improvement for

[PATCH v4 12/15] path.c: move some code out of strbuf_git_path_submodule()

refs is learning to avoid path rewriting that is done by strbuf_git_path_submodule(). Factor out this code so it could be reused by refs* Signed-off-by: Nguyễn Thái Ngọc Duy --- path.c | 34 +++--- submodule.c | 31

[PATCH v4 14/15] files-backend: remove submodule_allowed from files_downcast()

Since submodule or not is irrelevant to files-backend after the last patch, remove the parameter from files_downcast() and kill files_assert_main_repository(). PS. This implies that all ref operations are allowed for submodules. But we may need to look more closely to see if that's really true...

[PATCH v4 11/15] refs.c: make get_main_ref_store() public and use it

get_ref_store() will soon be renamed to get_submodule_ref_store(). Together with future get_worktree_ref_store(), the three functions provide an appropriate ref store for different operation modes. New APIs will be added to operate directly on ref stores. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v4 05/15] refs.c: share is_per_worktree_ref() to files-backend.c

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 6 -- refs/refs-internal.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/refs.c b/refs.c index 81b64b4ed..c6af84357 100644 --- a/refs.c +++ b/refs.c @@ -489,12 +489,6 @@ int

[PATCH v4 10/15] refs.c: kill register_ref_store(), add register_submodule_ref_store()

This is the last function in this code (besides public API) that takes submodule argument and handles both main/submodule cases. Break it down, move main store registration in get_main_ref_store() and keep the rest in register_submodule_ref_store(). Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v4 06/15] files-backend: remove the use of git_path()

Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of deciding what goes where. The end goal is to pass $GIT_DIR only. A refs "view" of a linked worktree is a logical ref store that combines two files backends together. (*) Not entirely true since strbuf_git_path_submodule() still

[PATCH v4 07/15] refs.c: introduce get_main_ref_store()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/refs.c b/refs.c index c6af84357..c3bdc99d8 100644 --- a/refs.c +++ b/refs.c @@ -1450,15 +1450,23 @@ static struct ref_store

[PATCH v4 08/15] refs: rename lookup_ref_store() to lookup_submodule_ref_store()

With get_main_ref_store() being used inside get_ref_store(), lookup_ref_store() is only used for submodule code path. Rename to reflect that and delete dead code. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 13 - 1 file changed, 4 insertions(+), 9

[PATCH v4 09/15] refs.c: flatten get_ref_store() a bit

This helps the future changes in this code. And because get_ref_store() is destined to become get_submodule_ref_store(), the "get main store" code path will be removed eventually. After this the patch to delete that code will be cleaner. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH v4 04/15] files-backend: replace *git_path*() with files_path()

This centralizes all path rewriting of files-backend.c in one place so we have easier time removing the path rewriting later. There could be some hidden indirect git_path() though, I didn't audit the code to the bottom. Side note: set_worktree_head_symref() is a bad boy and should not be in

[PATCH v4 03/15] files-backend: add files_path()

This will be the replacement for both git_path() and git_path_submodule() in this file. The idea is backend takes a git path and use that, oblivious of submodule, linked worktrees and such. This is the middle step towards that. Eventually the "submodule" field in 'struct files_ref_store' should

[PATCH v4 02/15] files-backend: convert git_path() to strbuf_git_path()

git_path() and friends are going to be killed in files-backend.c in near future. And because there's a risk with overwriting buffer in git_path(), let's convert them all to strbuf_git_path(). We'll have easier time killing/converting strbuf_git_path() then because we won't have to worry about

[PATCH v4 00/15] Remove submodule from files-backend.c

v4: - is based on master+mh/ref-remove-empty-directory+mh/submodule-hash instead of mh/submodule-hash alone. It could merge with pu cleanly. - 06/16 from v5, "correct is_per_worktree_ref", is removed. The "remove the use of git_path" patch is updated to handle it correctly even

[PATCH v4 01/15] refs-internal.c: make files_log_ref_write() static

Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10) but probably never used outside refs-internal.c Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/files-backend.c | 3 +++ refs/refs-internal.h | 4 2 files changed, 3 insertions(+), 4 deletions(-) diff

Re: [PATCH v2 00/16] Remove submodule from files-backend.c

On Sat, Feb 18, 2017 at 1:35 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> I'll be sending two more follow-up series, if you are interested, soon: >> >> 1) v2 of nd/worktree-gc-protection >> >> which kills parse_ref() in worktree.c _and_

Re: [git-for-windows] Re: Continuous Testing of Git on Windows

From: "Junio C Hamano" Sent: Thursday, February 16, 2017 12:20 AM "Philip Oakley" writes: It may even be worth 'splitting' the pu branch sequence into the existing pu (with merges from series that are selected as reasonable), and then a pr branch

Re: Git bisect does not find commit introducing the bug

>> First of all this is confusing, as this commit cannot be reached >> starting from "v.good". > Hm, IMHO it shows that your example is pretty artificial (although you > might have come across it in a real-world scenario): you introduced a > new feature in f4154e9 (and it worked) and you broke

Please I want you to patiently read this offer.?

Hello. I know this means of communication may not be morally right to you as a person but I also have had a great thought about it and I have come to this conclusion which I am about to share with you. INTRODUCTION:I am the Credit Manager U. B. A Bank of Burkina Faso Ouagadougou and in one way

Re: Git bisect does not find commit introducing the bug

Am 18.02.2017 um 00:21 schrieb Stephan Beyer: On 02/17/2017 11:29 PM, Alex Hoffman wrote: * 7a9e952 (bisect bad) |\ | * 671cec2 <--- expected | |\ | * | 04c6f4b <--- found * | | 3915157 |\ \ \ | | |/ | |/| | * | f4154e9 (bisect good) | * | 85855bf | |/ * | f1a36f5 |/ * 1b7fb88 The