[PATCH 1/3] .mailmap: merge different spellings of names

This is a continuation of 94b410bba86 (.mailmap: Map email addresses to names, 2013-07-12), merging names that are spelled differently but have the same author email to the same person. Most spellings differed in accents or the order of names. Signed-off-by: Stefan Beller --- .mailmap | 11

[PATCH 2/3] .mailmap: assume Jason McMullan to be the same person

Over the years of contributing to open source, I realized the world of open source is smaller than I originally thought and a name is still a pretty unique thing. So let's assume these two author idents are the same person. In 10813e0d3c7 (.mailmap: update long-lost friends with multiple defunct

[PATCH 3/3] .mailmap: map names with multiple emails to the same author identity

There are multiple author idents who have different email addresses, but the same name; assume they are the same person, as the world of open source is actually rather small. Sift through the history via: git shortlog -sne origin/pu |awk '{ NF--; $1=""; print }' |sort |uniq -d |cut -c 2-

[PATCH v3 13/32] tag: add repository argument to lookup_tag

Add a repository argument to allow the callers of lookup_tag to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 07/32] commit: add repository argument to lookup_commit_reference_gently

Add a repository argument to allow callers of lookup_commit_reference_gently to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a

[PATCH v3 09/32] commit: add repository argument to lookup_commit

Add a repository argument to allow callers of lookup_commit to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 27/32] commit.c: allow get_cached_commit_buffer to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 4 ++-- commit.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/commit.c b/commit.c index dd8c9c15b14..15b044331a1 100644 --- a/commit.c +++ b/commit.c @@ -283,10 +283,10 @@ void set_commit_buffer(struct repository *r, struct

[PATCH v3 26/32] commit.c: allow set_commit_buffer to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 4 ++-- commit.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/commit.c b/commit.c index 1baac77861f..dd8c9c15b14 100644 --- a/commit.c +++ b/commit.c @@ -275,10 +275,10 @@ void free_commit_buffer_slab(struct buffer_slab *bs)

[PATCH v3 31/32] commit.c: allow lookup_commit_reference_gently to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 8 commit.h | 4 +--- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/commit.c b/commit.c index 15b044331a1..08b4602f43f 100644 --- a/commit.c +++ b/commit.c @@ -24,16 +24,16 @@ int save_commit_buffer = 1; const char

[PATCH v3 29/32] object.c: allow parse_object to handle arbitrary repositories

Signed-off-by: Stefan Beller --- object.c | 14 +++--- object.h | 3 +-- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/object.c b/object.c index cd870fee22b..b0faab85d40 100644 --- a/object.c +++ b/object.c @@ -245,28 +245,28 @@ struct object *parse_object_or_die(const

[PATCH v3 32/32] commit.c: allow lookup_commit_reference to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 4 ++-- commit.h | 5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/commit.c b/commit.c index 08b4602f43f..b88ced5b026 100644 --- a/commit.c +++ b/commit.c @@ -36,9 +36,9 @@ struct commit *lookup_commit_reference_gently(struct

[PATCH v3 30/32] tag.c: allow deref_tag to handle arbitrary repositories

Signed-off-by: Stefan Beller --- tag.c | 5 ++--- tag.h | 3 +-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/tag.c b/tag.c index 682e7793059..94a89b21cb5 100644 --- a/tag.c +++ b/tag.c @@ -64,12 +64,11 @@ int gpg_verify_tag(const struct object_id *oid, const char

[PATCH v3 28/32] object.c: allow parse_object_buffer to handle arbitrary repositories

Signed-off-by: Stefan Beller --- object.c | 18 +- object.h | 3 +-- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/object.c b/object.c index 9d588448192..cd870fee22b 100644 --- a/object.c +++ b/object.c @@ -185,21 +185,21 @@ struct object

[PATCH v3 22/32] tag: allow parse_tag_buffer to handle arbitrary repositories

Signed-off-by: Stefan Beller --- tag.c | 10 +- tag.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/tag.c b/tag.c index 46b5882ee12..682e7793059 100644 --- a/tag.c +++ b/tag.c @@ -126,7 +126,7 @@ void release_tag_memory(struct tag *t) t->date = 0; }

[PATCH v3 23/32] commit.c: allow parse_commit_buffer to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 10 +- commit.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/commit.c b/commit.c index 8749e151451..41d23352098 100644 --- a/commit.c +++ b/commit.c @@ -364,7 +364,7 @@ const void *detach_commit_buffer(struct commit

[PATCH v3 24/32] commit-slabs: remove realloc counter outside of slab struct

The realloc counter is declared outside the struct for the given slabname, which makes it harder for a follow up patch to move the declaration of the struct around as then the counter variable would need special treatment. As the reallocation counter is currently unused we can just remove it. If

[PATCH v3 25/32] commit.c: migrate the commit buffer to the parsed object store

Signed-off-by: Stefan Beller --- commit.c | 29 +++-- commit.h | 4 object.c | 5 + object.h | 4 4 files changed, 36 insertions(+), 6 deletions(-) diff --git a/commit.c b/commit.c index 41d23352098..1baac77861f 100644 --- a/commit.c +++ b/commit.c @@

[PATCH v3 00/32] object-store: lookup_commit

This continues the elimination of global variables in the object store and teaches lookup_commit[_reference] and alike to handle a_repository. This is also available as https://github.com/stefanbeller/git/tree/object-store-lookup-commit or applies on top of 02f70d63027 (Merge branch

[PATCH v3 12/32] commit: add repository argument to get_cached_commit_buffer

Add a repository argument to allow callers of get_cached_commit_buffer to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

[PATCH v3 11/32] commit: add repository argument to set_commit_buffer

Add a repository argument to allow callers of set_commit_buffer to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 17/32] object: allow lookup_object to handle arbitrary repositories

Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller --- object.c | 15 +++ object.h | 3 +-- 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/object.c b/object.c index f41f82c6725..9d74de95f5b 100644 --- a/object.c +++ b/object.c @@ -84,21 +84,20 @@ static

[PATCH v3 08/32] commit: add repository argument to lookup_commit_reference

Add a repository argument to allow callers of lookup_commit_reference to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

[PATCH v3 16/32] object: allow object_as_type to handle arbitrary repositories

Signed-off-by: Stefan Beller --- object.c | 4 ++-- object.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/object.c b/object.c index e095d49b379..f41f82c6725 100644 --- a/object.c +++ b/object.c @@ -158,13 +158,13 @@ void *create_object(struct repository *r, const

[PATCH v3 19/32] tree: allow lookup_tree to handle arbitrary repositories

Signed-off-by: Stefan Beller --- tree.c | 10 +- tree.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/tree.c b/tree.c index 45e89ff08eb..78d440a9c8f 100644 --- a/tree.c +++ b/tree.c @@ -195,13 +195,13 @@ int read_tree(struct tree *tree, int stage, struct

[PATCH v3 15/32] tag: add repository argument to deref_tag

Add a repository argument to allow the callers of deref_tag to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 14/32] tag: add repository argument to parse_tag_buffer

Add a repository argument to allow the callers of parse_tag_buffer to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 06/32] tree: add repository argument to lookup_tree

Add a repository argument to allow the callers of lookup_tree to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 01/32] object: add repository argument to parse_object

Add a repository argument to allow the callers of parse_object to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 18/32] blob: allow lookup_blob to handle arbitrary repositories

Signed-off-by: Stefan Beller --- blob.c | 10 +- blob.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/blob.c b/blob.c index 17b9314f0a0..342bdbb1bbe 100644 --- a/blob.c +++ b/blob.c @@ -5,13 +5,13 @@ const char *blob_type = "blob"; -struct blob

[PATCH v3 20/32] commit: allow lookup_commit to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 10 +- commit.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/commit.c b/commit.c index aa5557dee84..8749e151451 100644 --- a/commit.c +++ b/commit.c @@ -53,13 +53,13 @@ struct commit *lookup_commit_or_die(const

[PATCH v3 02/32] object: add repository argument to lookup_object

Add a repository argument to allow callers of lookup_object to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 21/32] tag: allow lookup_tag to handle arbitrary repositories

Signed-off-by: Stefan Beller --- tag.c | 10 +- tag.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/tag.c b/tag.c index fbb4659325b..46b5882ee12 100644 --- a/tag.c +++ b/tag.c @@ -92,13 +92,13 @@ struct object *deref_tag_noverify(struct object *o)

[PATCH v3 10/32] commit: add repository argument to parse_commit_buffer

Add a repository argument to allow the callers of parse_commit_buffer to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

[PATCH v3 04/32] object: add repository argument to object_as_type

Signed-off-by: Stefan Beller --- blob.c | 2 +- builtin/fsck.c | 2 +- commit.c | 4 ++-- object.c | 2 +- object.h | 3 ++- refs.c | 2 +- tag.c | 2 +- tree.c | 2 +- 8 files changed, 10 insertions(+), 9 deletions(-) diff --git a/blob.c

[PATCH v3 05/32] blob: add repository argument to lookup_blob

Add a repository argument to allow the callers of lookup_blob to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCH v3 03/32] object: add repository argument to parse_object_buffer

Add a repository argument to allow the callers of parse_object_buffer to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

Re: [PATCH 4/4] fsck: silence stderr when parsing .gitmodules

On 28/06/18 23:12, Jeff King wrote: > On Thu, Jun 28, 2018 at 06:06:03PM -0400, Jeff King wrote: > >> Note that we didn't test this case at all, so I've added >> coverage in t7415. We may end up toning down or removing >> this fsck check in the future. So take this test as checking >> what

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On 28/06/18 23:03, Jeff King wrote: > On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote: [snip] > Yes, it can go in quickly. But I'd prefer not to keep it in the long > term if it's literally doing nothing. Hmm, I don't think you can say its doing nothing! "Yeah, this solution

[PATCH v4 9/9] diff.c: add white space mode to move detection that allows indent changes

The option of --color-moved has proven to be useful as observed on the mailing list. However when refactoring sometimes the indentation changes, for example when partitioning a functions into smaller helper functions the code usually mostly moved around except for a decrease in indentation. To

[PATCH v4 8/9] diff.c: factor advance_or_nullify out of mark_color_as_moved

This moves the part of code that checks if we're still in a block into its own function. We'll need a different approach on advancing the blocks in a later patch, so having it as a separate function will prove useful. While at it rename the variable `p` to `prev` to indicate that it refers to

[PATCH v4 1/9] xdiff/xdiff.h: remove unused flags

These flags were there since the beginning (3443546f6e (Use a *real* built-in diff generator, 2006-03-24), but were never used. Remove them. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- xdiff/xdiff.h | 8 1 file changed, 8 deletions(-) diff --git a/xdiff/xdiff.h

[PATCH v4 5/9] diff.c: adjust hash function signature to match hashmap expectation

This makes the follow up patch easier. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index ce7bedc1b92..d1bae900cdc 100644 --- a/diff.c +++ b/diff.c @@ -707,11 +707,15

[PATCH v4 2/9] xdiff/xdiffi.c: remove unneeded function declarations

There is no need to forward-declare these functions, as they are used after their implementation only. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- xdiff/xdiffi.c | 17 - 1 file changed, 17 deletions(-) diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c index

[PATCH v4 0/9] Moved code detection: ignore space on uniform indentation

v4: * see range diff below * brought best practices to t4015 and have git not upstream of a pipe (new patch 3) * squashed in the SQUASH patches * fixed the translation as well. v3: This is a complete rewrite of the actual patch, with slight modifications] on the refactoring how to

[PATCH v4 7/9] diff.c: decouple white space treatment from move detection algorithm

In the original implementation of the move detection logic the choice for ignoring white space changes is the same for the move detection as it is for the regular diff. Some cases came up where different treatment would have been nice. Allow the user to specify that white space should be ignored

[PATCH v4 4/9] diff.c: do not pass diff options as keydata to hashmap

When we initialize the hashmap, we give it a pointer to the diff_options, which it then passes along to each call of the hashmap_cmp_fn function. There's no need to pass it a second time as the "keydata" parameter, and our comparison functions never look at keydata. This was a mistake left over

[PATCH v4 3/9] t4015: avoid git as a pipe input

In t4015 we have a pattern of git diff [] | grep -v "index" | test_decode_color >actual && to produce output that we want to test against. This pattern was introduced in 86b452e2769 (diff.c: add dimming to moved line detection, 2017-06-30) as then the focus on getting the

[PATCH v4 6/9] diff.c: add a blocks mode for moved code detection

The new "blocks" mode provides a middle ground between plain and zebra. It is as intuitive (few colors) as plain, but still has the requirement for a minimum of lines/characters to count a block as moved. Suggested-by: Ævar Arnfjörð Bjarmason

Re: [PATCH v6 0/4] stash: Convert some `git stash` commands to a builtin

Hello, On 27.06.2018 01:12, Johannes Schindelin wrote: Joel Teichroeb (4): stash: convert apply to builtin stash: convert drop and clear to builtin stash: convert branch to builtin stash: convert pop to builtin Were there any changes since v5 in these patches? There are some

Re: [PATCH 0/1] Makefile: fix the "built from commit" code

On Thu, Jun 28, 2018 at 12:53:15PM +, Johannes Schindelin via GitGitGadget wrote: > Let's fix that quoting, and while at it, also suppress the unhelpful > message > > fatal: not a git repository (or any of the parent directories): .git > > that gets printed to stderr if no current commit

Re: [PATCH v6 2/4] stash: convert drop and clear to builtin

Hi, On 27.06.2018 01:17, Johannes Schindelin wrote: I thought you had introduced `get_oidf()` specifically so you could avoid the `rev-parse` call... `get_oidf(_oid, "%s@{0}", ref_stash)` should do this, right? We discussed this over the IRC channel, but since not everybody might follow the

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

On Thu, Jun 28, 2018 at 2:40 PM Junio C Hamano wrote: > The tip of 'next' has been rewound and it currently has only 4 > topics. Quite a many topics are cooking in 'pu' and need to be > sifted into good bins (for 'next') and the remainder. Help is > appreciated in that area ;-) Which branches

Re: [PATCH v6 0/4] stash: add new tests and introduce a new helper function

Hello, Heh, what is more useful than apology is to tell us which order these three (apparent) series build on top of each other ;-) The answer, IIUC, is that * oidf+tests come first, then * apply/drop/branch/pop (as these rely on oidf) on top, and finally * list (as it wants to add to

Re: [PATCH v5 3/8] block alloc: add lifecycle APIs for cache_entry structs

> diff --git a/read-cache.c b/read-cache.c > index 9624ce1784..116fd51680 100644 > --- a/read-cache.c > +++ b/read-cache.c > +struct cache_entry *make_transient_cache_entry(unsigned int mode, const > struct object_id *oid, > +const char *path, int

Re: [PATCH v5 2/8] read-cache: make_cache_entry should take object_id struct

> The make_cache_entry function should take an object_id struct instead > of sha. > diff --git a/read-cache.c b/read-cache.c > index fa8366ecab..9624ce1784 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -746,8 +746,10 @@ int add_file_to_index(struct index_state *istate, const > char

Re: [PATCH v3] fetch-pack: support negotiation tip whitelist

On 06/28, Jonathan Tan wrote: > During negotiation, fetch-pack eventually reports as "have" lines all > commits reachable from all refs. Allow the user to restrict the commits > sent in this way by providing a whitelist of tips; only the tips > themselves and their ancestors will be sent. > >

[PATCH v3] fetch-pack: support negotiation tip whitelist

During negotiation, fetch-pack eventually reports as "have" lines all commits reachable from all refs. Allow the user to restrict the commits sent in this way by providing a whitelist of tips; only the tips themselves and their ancestors will be sent. Both globs and single objects are supported.

Re: [PATCH 4/4] fsck: silence stderr when parsing .gitmodules

On Thu, Jun 28, 2018 at 06:06:03PM -0400, Jeff King wrote: > Note that we didn't test this case at all, so I've added > coverage in t7415. We may end up toning down or removing > this fsck check in the future. So take this test as checking > what happens now with a focus on stderr, and not any >

[PATCH 4/4] fsck: silence stderr when parsing .gitmodules

If there's a parsing error we'll already report it via the usual fsck report() function (or not, if the user has asked to skip this object or warning type). The error message from the config parser just adds confusion. Let's suppress it. Note that we didn't test this case at all, so I've added

[PATCH 3/4] config: add options parameter to git_config_from_mem

The underlying config parser knows how to handle a config_options struct, but git_config_from_mem() always passes NULL. Let's allow our callers to specify the options struct. We could add a "_with_options" variant, but since there are only a handful of callers, let's just update them to pass

[PATCH 2/4] config: add CONFIG_ERROR_SILENT handler

We can currently die() or error(), but there's not yet any way for callers to ask us just to quietly return an error. Let's give them one. Signed-off-by: Jeff King --- config.c | 3 +++ config.h | 1 + 2 files changed, 4 insertions(+) diff --git a/config.c b/config.c index

[PATCH 1/4] config: turn die_on_error into caller-facing enum

The config code has a die_on_error flag, which lets us emit an error() instead of dying when we see a bogus config file. But there's no way for a caller of the config code to set this: it's auto-set based on whether we're reading a file or a blob. Instead, let's add it to the config_options

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote: > > Yes, though I don't think it's too bad. We already have a "die_on_error" > > flag in the config code. I think it just needs to become a tristate: > > die/error/silent (and probably get passed in via config_options, since I > >

Re: [PATCH 5/5] builtin/rebase: support running "git rebase "

On Thu, Jun 28, 2018 at 12:48 AM Pratik Karki wrote: > > This patch gives life to the skeleton added in the previous patch. > This patch makes real operation happen i.e. by using > `git -c rebase.usebuiltin=true rebase `. > With this patch, the basic operation of rebase can be done. Would it

What's cooking in git.git (Jun 2018, #07; Thu, 28)

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 integration branches, but I am still holding onto them. The tip of 'next' has been

Re: [PATCH 4/5] sequencer: refactor the code to detach HEAD to checkout.c

Hi Pratik, On Thu, Jun 28, 2018 at 12:48 AM Pratik Karki wrote: > > The motivation behind this commit is to extract the core part of > do_reset() from sequencer.c and move it to a new detach_head_to() > function in checkout.c. > [...] > > The new function will be used in the next commit by the

Re: [PATCH] sequencer: use configured comment character

Aaron Schrab writes: > Use configured comment character when generating comments about branches > in an instruction sheet. Failure to honor this configuration causes a > failure to parse the resulting instruction sheet. > > Signed-off-by: Aaron Schrab > --- > sequencer.c | 2 +- > 1 file

Re: [PATCH 3/5] rebase: refactor common shell functions into their own file

On Thu, Jun 28, 2018 at 12:48 AM Pratik Karki wrote: > > The function present in `git-legacy-rebase.sh` are used by backends > so, this refactor tries to extract the functions out so that, the it not only tries to, it actually does. :) > `git-legacy-rebase.sh` can be retired easily as the >

Re: [PATCH v5 6/8] mem-pool: fill out functionality

Jameson Miller writes: > +void mem_pool_combine(struct mem_pool *dst, struct mem_pool *src) > +{ > + struct mp_block *p; > + > + /* Append the blocks from src to dst */ > + if (dst->mp_block && src->mp_block) { > + /* > + * src and dst have blocks, append > +

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On 28/06/18 18:45, Jeff King wrote: > On Thu, Jun 28, 2018 at 05:56:18PM +0100, Ramsay Jones wrote: [snip] >>> One thing we could do is turn the parse failure into a noop. The main >>> point of the check is to protect people against the malicious >>> .gitmodules bug. If the file can't be

Re: [PATCH 2/5] rebase: start implementing it as a builtin

On Thu, Jun 28, 2018 at 12:48 AM Pratik Karki wrote: > > This commit imitates the strategy that was used to convert the > difftool to a builtin, see be8a90e (difftool: add a skeleton for the > upcoming builtin, 2017-01-17) for details: This commit renames the > shell script `git-rebase.sh` to

Re: [PATCH v5 3/8] block alloc: add lifecycle APIs for cache_entry structs

Jameson Miller writes: > Add an API around managing the lifetime of cache_entry > structs. Abstracting memory management details behind this API will > allow for alternative memory management strategies without affecting > all the call sites. This commit does not change how memory is >

Re: [PATCH 2/2] grep.c: teach 'git grep --only-matching'

On Mon, Jun 25, 2018 at 04:26:00PM -0500, Taylor Blau wrote: > For instance, a line containing the following (taken from README.md:27): > > (`man gitcvs-migration` or `git help cvs-migration` if git is > > Is printed as follows: > > $ git grep -no -e git -- README.md | grep ":27" >

Re: curious about wording in "man git-config", ENVIRONMENT

On Tue, Jun 26, 2018 at 12:51:45PM -0400, Robert P. J. Day wrote: > > I agree it's weird. I think it's trying to mean "behaves as if it > > was set to", but with the additional notion that the command-line > > argument would take precedence over the environment (which is our > > usual rule). But

Re: [PATCH] doc: substitute ETC_GIT(CONFIG|ATTRIBUTES) in generated docs

On Thu, Jun 28, 2018 at 12:36:06PM -0400, Todd Zullinger wrote: > >> It might be enough if the default values are relatively sane > >> and consistent. That would be a slight improvement over the > >> current situation still. > > > > Yeah. Taking a step back from the implementation questions, I

Re: [GSoC][PATCH v5 0/2] rebase -i: rewrite append_todo_help() in C

Alban Gruin writes: > This patch rewrites append_todo_help() from shell to C. The C version > covers a bit more than the old shell version. To achieve that, some > parameters were added to rebase--helper. > > This also introduce a new source file, rebase-interactive.c. > > This is part of the

Re: [PATCH 1/1] Makefile: fix the "built from commit" code

On Thu, Jun 28, 2018 at 06:23:56PM +0200, Johannes Schindelin wrote: > On Thu, 28 Jun 2018, Jeff King wrote: > > > On Wed, Jun 27, 2018 at 09:35:23PM +0200, Johannes Schindelin via > > GitGitGadget wrote: > > > > > To prevent erroneous commits from being reported (e.g. when unpacking > > >

Re: [PATCH 1/1] Makefile: fix the "built from commit" code

On Thu, Jun 28, 2018 at 10:27:32AM -0700, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> I.e.: > >> > >> FOO='with spaces' > >> BAR=$FOO sh -c 'echo $BAR' > >> > >> works just fine. > > > > $ x="two spaces" > > > > $ echo $x > > two spaces > > > > Maybe we should

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On Thu, Jun 28, 2018 at 05:56:18PM +0100, Ramsay Jones wrote: > > Yeah, this solution seems sensible. Given that we would never report any > > error for that blob, there is no point in even looking at it. I wonder > > if we ought to do the same for other types, too. Is there any point in > >

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On Thu, Jun 28, 2018 at 09:39:39AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Yeah, this solution seems sensible. Given that we would never report any > > error for that blob, there is no point in even looking at it. I wonder > > if we ought to do the same for other types, too. Is

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

Ramsay Jones writes: > Junio, do you want me to address the above 'rejected push' > issue in this patch, or with a follow-up patch? (It should > be a pretty rare problem - famous last words!) If you feel the need to say "famous last words", it is an indication that it is better done as a

Re: [PATCH 1/1] Makefile: fix the "built from commit" code

Johannes Schindelin writes: >> I.e.: >> >> FOO='with spaces' >> BAR=$FOO sh -c 'echo $BAR' >> >> works just fine. > > $ x="two spaces" > > $ echo $x > two spaces > > Maybe we should quote a little bit more religiously. Both of you are wrong ;-) Of course, the lack of

Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

On Thu, Jun 28, 2018 at 07:21:18PM +0200, Lars Schneider wrote: > How about this: > > 1) We allow users to set the encoding "auto". Example: > > *.txt working-tree-encoding=auto > > 2) We define a new variable `core.autoencoding`. By default the value is > UTF-8 (== no re-encoding) but

Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

> On Jun 28, 2018, at 4:34 PM, Jeff King wrote: > > On Thu, Jun 28, 2018 at 02:44:47AM +, brian m. carlson wrote: > >> On Wed, Jun 27, 2018 at 07:54:52AM +, Steve Groeger wrote: >>> We have common code that is supposed to be usable across different >>> platforms and hence different

Re: [PATCH v5 5/8] mem-pool: add life cycle management functions

Jameson Miller writes: > Add initialization and discard functions to mem_pool type. As the > memory allocated by mem_pool can now be freed, we also track the large > allocations. > > If the there are existing mp_blocks in the mem_poo's linked list of mem_poo? > mp_blocksl, then the mp_block

Re: [PATCH v5 2/8] read-cache: make_cache_entry should take object_id struct

Jameson Miller writes: > The make_cache_entry function should take an object_id struct instead > of sha. The name of the hash is SHA-1, not sha ;-) It is not worth a reroll, but I do not think "should" is a particularly good thing to say in the title or justification in the log message in this

Re: [PATCH v4] Documentation: declare "core.ignoreCase" as internal variable

On 28.06.18 13:21, Marc Strapetz wrote: > The current description of "core.ignoreCase" reads like an option which > is intended to be changed by the user while it's actually expected to > be set by Git on initialization only. Subsequently, Git relies on the > proper configuration of this variable,

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

On 28/06/18 12:49, Jeff King wrote: > On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote: > >> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02), >> fsck will issue an error message for '.gitmodules' content that cannot >> be parsed correctly. This is the case,

Re: Inconsistencies in commit-graph technical docs.

Thanks for the quick response and for the patch. I started writing such a long process document because I _thought_ that I found a major issue with the Large Edge List. But, in the end, it was user error. It turned out that I was looking at index '11' when I should have been looking at index

Re: [PATCH v4] Documentation: declare "core.ignoreCase" as internal variable

Thanks.

Re: [PATCH] fsck: check skiplist for object in fsck_blob()

Jeff King writes: > Yeah, this solution seems sensible. Given that we would never report any > error for that blob, there is no point in even looking at it. I wonder > if we ought to do the same for other types, too. Is there any point in > opening a tree that is in the skiplist? Suppose the

Re: [PATCH] doc: substitute ETC_GIT(CONFIG|ATTRIBUTES) in generated docs

Jeff King wrote: > We could get rid around that by using $(DOC_ETC_GITCONFIG) or something, > with: > > DOC_ETC_GITCONFIG ?= $(ETC_GITCONFIG) > > in the Makefile. But that still leaves the choice of which generic text > to use up to the caller. Maybe we should provide more guidance. > > I.e.,

Re: [PATCH 1/1] Makefile: fix the "built from commit" code

Hi Peff, On Thu, 28 Jun 2018, Jeff King wrote: > On Wed, Jun 27, 2018 at 09:35:23PM +0200, Johannes Schindelin via > GitGitGadget wrote: > > > To prevent erroneous commits from being reported (e.g. when unpacking > > Git's source code from a .tar.gz file into a subdirectory of a different > >

Re: [PATCH v6 3/4] stash: convert branch to builtin

Hello, On 27.06.2018 21:39, Junio C Hamano wrote: This is primarily because cmd_$foo() is designed to be replacement of "main()" in usual programs---it is allowed to assume the global variables it uses have their initial values and nobody cares the state it leaves behind when it returns.

Re: [PATCH v2] fetch-pack: support negotiation tip whitelist

On 06/28, Jonathan Tan wrote: > > This seems like a pretty difficult to use feature, requiring that I > > provide the actual OIDs. I think a much better UI would probably be to > > accept a number of different things ranging from exact OIDs to actual > > ref names or even better, allowing for

Re: [RFC PATCH v5] Implement --first-parent for git rev-list --bisect

Johannes Schindelin writes: > On Wed, 27 Jun 2018, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> >git rev-list --bisect-all --first-parent F..E >revs && >> ># only E, e1..e8 should be listed, nothing else >> >test_line_count = 9 revs && >> >for rev in E e1 e2 e3

Re: [PATCH v2] fetch-pack: support negotiation tip whitelist

> This seems like a pretty difficult to use feature, requiring that I > provide the actual OIDs. I think a much better UI would probably be to > accept a number of different things ranging from exact OIDs to actual > ref names or even better, allowing for ref-patterns which include globs. > That

Re: [PATCH v2] fetch-pack: support negotiation tip whitelist

On 06/27, Jonathan Tan wrote: > During negotiation, fetch-pack eventually reports as "have" lines all > commits reachable from all refs. Allow the user to restrict the commits > sent in this way by providing a whitelist of tips; only the tips > themselves and their ancestors will be sent. > >

Re: [PATCH v1 0/9] Introducing remote ODBs

On Tue, Jun 26, 2018 at 2:37 AM, Eric Sunshine wrote: > In addition to the t5702 failures, I'm also seeing failures of > t0410.1, t5616.6 and t5616.7 at the tip of 'pu' as of [1], all of > which seem to be related to these changes. Yeah but only

Re: [PATCH 29/29] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

On Tue, Jun 26, 2018 at 07:15:45PM -0700, Elijah Newren wrote: > Crazy idea: maybe we could defang it a little more thoroughly with > something like the following (apologies in advance if gmail whitespace > damages this): > > diff --git a/t/test-lib.sh b/t/test-lib.sh > index

  1   2   >