Re: [PATCH v3 13/13] alloc: allow arbitrary repositories for alloc functions

On Tue, 8 May 2018 12:37:36 -0700 Stefan Beller wrote: > +void clear_alloc_state(struct alloc_state *s) > +{ > + while (s->slab_nr > 0) { > + s->slab_nr--; > + free(s->slabs[s->slab_nr]); > + } I should have caught this earlier, but you need

Re: [GSoC] A blog about 'git stash' project

Hello, On 08.05.2018 07:00, Taylor Blau wrote: On Fri, May 04, 2018 at 12:48:21AM +0300, Paul-Sebastian Ungureanu wrote: Hello everybody, The community bonding period started. It is well known that for a greater rate of success, it is recommended to send weekly reports regarding project

Re: [PATCH 8/8] gpg-interface: handle alternative signature types

On Tue, May 08, 2018 at 09:28:14AM -0400, Jeff King wrote: > OK, so my question then is: what does just-gpgsm support look like? > > Do we literally add gpgsm.program? My thought was that taking us the > first step towards a more generic config scheme would prevent us having > to backtrack later.

Re: [PATCH] pack-format.txt: more details on pack file format

>>> +Deltified representation >> >> Does this refer to OFS delta as well as REF deltas? > > Yes. Both OFS and REF deltas have the same "body" which is what this > part is about. The differences between OFS and REF deltas are not > described (in fact I don't think we describe what OFS and REF

Re: [PATCH] t6050-replace: don't disable stdin for the whole test script

Hi Gábor, On Mon, 7 May 2018, SZEDER Gábor wrote: > The test script 't6050-replace.sh' starts off with redirecting the whole > test script's stdin from /dev/null. This redirection has been there > since the test script was introduced in a3e8267225 (replace_object: add > a test case,

Re: [PATCH v3 13/13] alloc: allow arbitrary repositories for alloc functions

On Tue, May 8, 2018 at 1:04 PM, Jonathan Tan wrote: > On Tue, 8 May 2018 12:37:36 -0700 > Stefan Beller wrote: > >> +void clear_alloc_state(struct alloc_state *s) >> +{ >> + while (s->slab_nr > 0) { >> + s->slab_nr--; >> +

Re: [PATCH v3 09/12] get_short_oid / peel_onion: ^{tree} should be tree, not treeish

On Tue, May 08 2018, Jeff King wrote: > On Mon, May 07, 2018 at 01:08:46PM +0900, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason writes: >> >> > Right, and I'm with you so far, this makes sense to me for all existing >> > uses of the peel syntax, otherwise v2.17.0^{tree}

[PATCH v3 08/13] alloc: add repository argument to alloc_object_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 09/13] alloc: add repository argument to alloc_report

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 12/13] object: allow create_object to handle arbitrary repositories

Reviewed-by: Jonathan Tan Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- object.c | 12 ++-- object.h | 3 +-- 2 files changed, 7 insertions(+), 8

[PATCH v3 06/13] alloc: add repository argument to alloc_commit_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 10/13] alloc: add repository argument to alloc_commit_index

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 03/13] object: add repository argument to grow_object_hash

From: Jonathan Nieder Add a repository argument to allow the caller of grow_object_hash 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.

[PATCH v3 13/13] alloc: allow arbitrary repositories for alloc functions

We have to convert all of the alloc functions at once, because alloc_report uses a funky macro for reporting. It is better for the sake of mechanical conversion to convert multiple functions at once rather than changing the structure of the reporting function. We record all memory allocation in

[PATCH v3 04/13] alloc: add repository argument to alloc_blob_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 00/13] object store: alloc

v3: * I used the (soon to be renamed?) branch-diff tool to attach a diff below between v2 and v3 * fixed comment in patch 1 * correctly free objects and its hashmap in the last patch. * drop free'ing the commit->util pointer as we do not know where it points to. v2: * I decided to stick

[PATCH v3 02/13] object: add repository argument to create_object

Add a repository argument to allow the callers of create_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. Signed-off-by: Jonathan Nieder

[PATCH v3 05/13] alloc: add repository argument to alloc_tree_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 01/13] repository: introduce parsed objects field

Convert the existing global cache for parsed objects (obj_hash) into repository-specific parsed object caches. Existing code that uses obj_hash are modified to use the parsed object cache of the_repository; future patches will use the parsed object caches of other repositories. Another future use

[PATCH v3 07/13] alloc: add repository argument to alloc_tag_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH v3 11/13] object: allow grow_object_hash to handle arbitrary repositories

Reviewed-by: Jonathan Tan Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- object.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff

Re: [PATCH 06/28] t0000: annotate with SHA1 prerequisite

On Tue, May 08, 2018 at 08:28:47PM +0200, Martin Ågren wrote: > On 8 May 2018 at 01:40, brian m. carlson wrote: > > As I mentioned in an earlier email, I plan to set an environment > > variable for the algorithms in use and then do something like: > > > > test

[PATCH v5 0/7] Teach '--column' to 'git-grep(1)'

Hi, Attached is my fifth re-roll of the series to add '--column' to 'git-grep(1)'. The main changes are from a René's concerns in [1]. He points out that '--column' with certain extended expressions can produce nonsense (particularly because we leave the regmatch_t uninitialized). > So at least

[PATCH v5 6/7] grep.c: add configuration variables to show matched option

To support git-grep(1)'s new option, '--column', document and teach grep.c how to interpret relevant configuration options, similar to those associated with '--line-number'. Signed-off-by: Taylor Blau --- Documentation/config.txt | 5 + Documentation/git-grep.txt | 3

[PATCH v5 3/7] grep.[ch]: extend grep_opt to allow showing matched column

To support showing the matched column when calling 'git-grep(1)', teach 'grep_opt' the normal set of options to configure the default behavior and colorization of this feature. Signed-off-by: Taylor Blau --- grep.c | 3 +++ grep.h | 2 ++ 2 files changed, 5 insertions(+)

[PATCH v5 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

Take advantage of 'git-grep(1)''s new option, '--column' in order to teach Peff's 'git-jump' script how to jump to the correct column for any given match. 'git-grep(1)''s output is in the correct format for Vim's jump list, so no additional cleanup is necessary. Signed-off-by: Taylor Blau

[PATCH v5 4/7] grep.c: display column number of first match

To prepare for 'git grep' learning '--column', teach grep.c's show_line() how to show the column of the first match on non-context line. Signed-off-by: Taylor Blau --- grep.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/grep.c

[PATCH v5 1/7] Documentation/config.txt: camel-case lineNumber for consistency

lineNumber has casing that is inconsistent with surrounding options, like color.grep.matchContext, and color.grep.matchSelected. Re-case this documentation in order to be consistent with the text around it, and to ensure that new entries are consistent, too. Signed-off-by: Taylor Blau

[PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Teach 'git-grep(1)' a new option, '--column', to show the column number of the first match on a non-context line. This makes it possible to teach 'contrib/git-jump/git-jump' how to seek to the first matching position of a grep match in your editor, and allows similar additional scripting

Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

On 8 May 2018 at 20:10, Jeff King wrote: > On Sun, May 06, 2018 at 04:10:29PM +0200, Martin Ågren wrote: >> Unlike in the previous patch, this function is not prepared for >> indicating errors via a `strbuf err`, so let's just drop the dead code. >> Any improved error-handling can

Re: [PATCH v4 2/7] grep.c: expose matched column in match_line()

Am 05.05.2018 um 04:42 schrieb Taylor Blau: > When calling match_line(), callers presently cannot determine the > relative offset of the match because match_line() discards the > 'regmatch_t' that contains this information. > > Instead, teach match_line() to take in a 'regmatch_t *' so that

Re: [PATCH 2/2] Documentation: render revisions correctly under Asciidoctor

On Tue, May 08, 2018 at 08:31:10PM +0200, Martin Ågren wrote: > On 8 May 2018 at 03:13, brian m. carlson wrote: > > Since this patch fixes the present issue, I'd like to leave it as it is > > and run through a cleanup series a bit later that catches all the > >

[PATCH v5 2/7] grep.c: expose matched column in match_line()

When calling match_line(), callers presently cannot determine the relative offset of the match because match_line() discards the 'regmatch_t' that contains this information. Instead, teach match_line() to take in a 'regmatch_t *' so that callers can inspect the match's starting and ending offset

regarding fix on "git clone $there $here"

Dear git experts, Recently we try to upgrade ubuntu from 17.10 to 18.04, then we found one inconsistent behavior on git clone. At 2.14.1 or 2.15.1, if I run command like - mkdir /tmp/111 - git clone g...@github.com:111/111 /tmp/111 because it will failure, then /tmp/111 will be removed

Re: [PATCH 01/28] t/test-lib: add an SHA1 prerequisite

On Tue, May 08, 2018 at 08:26:05PM +0200, Martin Ågren wrote: > On 8 May 2018 at 01:30, brian m. carlson wrote: > > On Mon, May 07, 2018 at 12:10:39PM +0200, Martin Ågren wrote: > >> Do we actually need more SHA-1-related prereqs, at least long-term, in > >> which

[PATCH 2/4] submodule foreach: document '$sm_path' instead of '$path'

From: Prathamesh Chavan As using a variable '$path' may be harmful to users due to capitalization issues, see 64394e3ae9 (git-submodule.sh: Don't use $path variable in eval_gettext string, 2012-04-17). Adjust the documentation to advocate for using $sm_path, which contains

[PATCH 3/4] submodule foreach: document variable '$displaypath'

From: Prathamesh Chavan It was observed that the variable '$displaypath' was accessible but undocumented. Hence, document it. Discussed-with: Ramsay Jones Signed-off-by: Stefan Beller Signed-off-by: Prathamesh Chavan

[PATCHv2 0/4] Rebooting pc/submodule-helper-foreach

v2: * rebased onto origin/master * dropped leftover "toplevel" variable from experimentation * reworded the commit message for the first patch extensively * dropped the third patch * see "branch-diff" below. v1: The "What's cooking" email carried this series for some time now: > *

[PATCH 1/4] submodule foreach: correct '$path' in nested submodules from a subdirectory

From: Prathamesh Chavan When running 'git submodule foreach --recursive' from a subdirectory of your repository, nested submodules get a bogus value for $path: For a submodule 'sub' that contains a nested submodule 'nested', running 'git -C dir submodule foreach echo $path'

[PATCH 4/4] submodule: port submodule subcommand 'foreach' from shell to C

From: Prathamesh Chavan This aims to make git-submodule foreach a builtin. 'foreach' is ported to the submodule--helper, and submodule--helper is called from git-submodule.sh. Helped-by: Brandon Williams Mentored-by: Christian Couder

Re: [PATCH v2] mailmap: update brian m. carlson's email address

On Tue, May 08, 2018 at 10:34:58AM +0530, Kaartic Sivaraam wrote: > Just to be sure, you're meaning the use of `git log --use-mailmap` when > you mean `git log` in the log message. Am I right? Or did you mean `git > shortlog` ? > > I'm asking this because I think the `git log` output doesn't

Re: [PATCH/RFC] completion: complete all possible -no-

At 17:24 +0200 08 May 2018, Duy Nguyen wrote: It took me so long to reply partly because I remember seeing some guy doing clever trick with tab completion that also shows a short help text in addition to the complete words. I could not find that again and from my reading

Re: [RFC PATCH v4 1/3] Teach remote add the --remote-tags option

On Tuesday 01 May 2018 10:29 PM, Wink Saville wrote: > When --remote-tags is passed to `git remote add` the tagopt is set to > --remote-tags and a second fetch line is added so tags are placed in > a separate hierarchy per remote. > I find '--remote' in the option name to be redundant given that

Re: Weak option parsing in `git submodule`

On Tuesday 08 May 2018 12:35 AM, Stefan Beller wrote: >> The lack of checking for the reason behind why `git add` fails seems to >> be the reason behind that weird message. > > (from the man page) > git submodule [--quiet] add [] [--] [] > > When options are given after or we can

Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

On Tuesday 08 May 2018 08:49 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I couldn't quite get what you meant by "(but not the other way >> around)". Did you mean >> >> $ git push --force ../child2 refs/tags/*:refs/tags/* >> >> should not become non-forcing

Re: main url for linking to git source?

On Monday 07 May 2018 11:45 PM, Stefan Beller wrote: >> I could see arguments both ways, so I thought I'd take a straw poll of >> what people on the list think. > > Junios reply below focuses on the URL passed to git-clone, which > is only found at https://git-scm.com/downloads (?) > > There I

Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

On Monday 30 April 2018 01:50 AM, Ævar Arnfjörð Bjarmason wrote: > diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh > index 15c8d5a734..c9a2011915 100755 > --- a/t/t5516-fetch-push.sh > +++ b/t/t5516-fetch-push.sh > @@ -981,7 +981,17 @@ test_expect_success 'push requires --force to

Re: [PATCH v2 13/13] alloc: allow arbitrary repositories for alloc functions

On Mon, May 07, 2018 at 03:59:16PM -0700, Stefan Beller wrote: > @@ -501,9 +509,31 @@ void raw_object_store_clear(struct raw_object_store *o) > void parsed_object_pool_clear(struct parsed_object_pool *o) > [...] > + for (i = 0; i < o->obj_hash_size; i++) { > + struct object *obj

Re: main url for linking to git source?

On Mon, May 07, 2018 at 10:46:58PM -0400, Konstantin Ryabitsev wrote: > On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote: > > I think I would also prefer a list of available repositories over a > > hard-coded choice. It may be that some places (say, Australia) have > > better

Re: [PATCH 2/2] gitk: add an option to run gitk on an item in the file list

On Tue, May 8, 2018 at 2:22 PM, Alex Riesen wrote: > From: Alex Riesen > > Similar to a git gui feature which visualizes history in a submodule, > the submodules cause the gitk be started inside the submodule. > > Signed-off-by: Alex Riesen

[PATCH 2/2] gitk: add an option to run gitk on an item in the file list

From: Alex Riesen Similar to a git gui feature which visualizes history in a submodule, the submodules cause the gitk be started inside the submodule. Signed-off-by: Alex Riesen --- gitk | 12 1 file changed, 12 insertions(+) diff --git

[PATCH 0/2] gitk: improve handling of submodules in the file list panel

Currently, the submodule entries in the file list panel are mostly ignored. This series attempts to improve the situation by showing part of submodule history when focusing it in the file list panel and by adding a menu element to start gitk in the submodule (similar to git gui). [1/2]: gitk:

[PATCH 1/2] gitk: show part of submodule log instead of empty pane when listing trees

From: Alex Riesen Currently, the submodules either are not shown at all (if listing a committed tree) or a Tcl error appears (when clicking on a submodule from the index list). This will make it show first arbitrarily chosen number of commits, which might be only marginally

Re: [PATCH 2/2] gitk: add an option to run gitk on an item in the file list

Bert Wesarg, Tue, May 08, 2018 15:17:03 +0200: > On Tue, May 8, 2018 at 2:22 PM, Alex Riesen > wrote: > > +proc flist_gitk {} { > > +global flist_menu_file findstring gdttype > > + > > +set x [shellquote $flist_menu_file] > > this needs to handle cdup,

Re: [PATCH 4/8] push tests: assert re-pushing annotated tags

> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh > index c9a2011915..71fc902062 100755 > --- a/t/t5516-fetch-push.sh > +++ b/t/t5516-fetch-push.sh > @@ -965,35 +965,43 @@ test_expect_success 'push into aliased refs > (inconsistent)' ' > ) > ' > > -test_expect_success 'push

Re: [PATCH v3 11/12] config doc: document core.disambiguate

On Tue, May 01, 2018 at 06:40:15PM +, Ævar Arnfjörð Bjarmason wrote: > The core.disambiguate variable was added in > 5b33cb1fd7 ("get_short_sha1: make default disambiguation > configurable", 2016-09-27) but never documented. Thanks, this seems reasonable. It was originally added as a tool to

Re: [PATCH/RFC] completion: complete all possible -no-

On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine wrote: > I haven't looked at the implementation, so this may be an entirely > stupid suggestion, but would it be possible to instead render the > completions as? > > % git checkout -- > --[no-]conflict=

Re: [PATCH v3 04/12] cache.h: add comment explaining the order in object_type

On Tue, May 1, 2018 at 8:40 PM, Ævar Arnfjörð Bjarmason wrote: > The order in the enum might seem arbitrary, and isn't explained by > 72518e9c26 ("more lightweight revalidation while reusing deflated > stream in packing", 2006-09-03) which added it. > > Derrick Stolee suggested

[PATCH] pack-format.txt: more details on pack file format

The current document mentions OBJ_* constants without their actual values. A git developer would know these are from cache.h but that's not very friendly to a person who wants to read this file to implement a pack file parser. Similarly, the deltified representation is not documented at all (the

Re: [PATCH 8/8] gpg-interface: handle alternative signature types

On Mon, May 07, 2018 at 11:06:50PM +, brian m. carlson wrote: > I think my main objection to this series is that it is generic in a way > that isn't necessarily useful. We know there are essentially only two > formats of PEM-style signatures: OpenPGP and CMS[0]. Even if there are > more,

Re: [PATCH v3 13/15] git_config_set: make use of the config parser's event stream

On Mon, Apr 09, 2018 at 10:32:20AM +0200, Johannes Schindelin wrote: > +static int store_aux_event(enum config_event_t type, > +size_t begin, size_t end, void *data) > +{ > + struct config_store_data *store = data; > + > + ALLOC_GROW(store->parsed, store->parsed_nr

Re: [PATCH v2 13/13] alloc: allow arbitrary repositories for alloc functions

On Tue, May 8, 2018 at 12:59 AM, Stefan Beller wrote: > @@ -501,9 +509,31 @@ void raw_object_store_clear(struct raw_object_store *o) > void parsed_object_pool_clear(struct parsed_object_pool *o) > { > /* > -* TOOD free objects in o->obj_hash. > -* >

Re: [PATCH/RFC] completion: complete all possible -no-

On Tue, May 8, 2018 at 8:24 AM, Duy Nguyen wrote: > I'm arguing about this because I want to see your reaction, because > I'm thinking of doing the very same thing for config completion. Right > now "git config " gives you two pages of all available config > variables. I'm

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

On Sat, May 05, 2018 at 08:49:43AM +0200, Ævar Arnfjörð Bjarmason wrote: > > +test_expect_success 'grep --only-matching --heading' ' > > + git grep --only-matching --heading --line-number --column mmap file > > >actual && > > + test_cmp expected actual > > +' > > + > > cat >expected < >

Re: [PATCH 1/2] gitk: show part of submodule log instead of empty pane when listing trees

On Tue, May 8, 2018 at 5:22 AM, Alex Riesen wrote: > From: Alex Riesen > > Currently, the submodules either are not shown at all (if listing a > committed tree) or a Tcl error appears (when clicking on a submodule > from the index list). I do

Re: [PATCH v2 01/13] repository: introduce parsed objects field

On Mon, 7 May 2018 15:59:04 -0700 Stefan Beller wrote: > /* > - * Holds any information related to accessing the raw object content. > + * Holds any information needed to retrieve the raw content > + * of objects. The object_parser uses this to get

Re: [PATCH] pack-format.txt: more details on pack file format

On Tue, May 8, 2018 at 8:56 AM, Nguyễn Thái Ngọc Duy wrote: > The current document mentions OBJ_* constants without their actual > values. A git developer would know these are from cache.h but that's > not very friendly to a person who wants to read this file to implement > a

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

On 5/7/2018 10:58 AM, Junio C Hamano wrote: * bp/merge-rename-config (2018-05-04) 3 commits - merge: pass aggressive when rename detection is turned off - merge: add merge.renames config setting - merge: update documentation for {merge,diff}.renameLimit (this branch uses

Re: [PATCH 4/5] lock_file: make function-local locks non-static

On Mon, May 07, 2018 at 05:24:05PM +0200, Duy Nguyen wrote: > - static struct lock_file lock; > + struct lock_file lock = LOCK_INIT; > >>> > >>> Is it really safe to do this? I vaguely remember something about > >>> (global) linked list and signal handling which could

Re: [PATCH] pack-format.txt: more details on pack file format

On Tue, May 8, 2018 at 7:23 PM, Stefan Beller wrote: >> While at there, I also add some text about this obscure delta format. >> We occasionally have questions about this on the mailing list if I >> remember correctly. > > Let me see if I can understand it, as I am not well

Re: [PATCH] pack-format.txt: more details on pack file format

On Tue, May 08 2018, Nguyễn Thái Ngọc Duy wrote: > The current document mentions OBJ_* constants without their actual > values. A git developer would know these are from cache.h but that's > not very friendly to a person who wants to read this file to implement > a pack file parser. > >

Re: [PATCH 0/5] getting rid of most "static struct lock_file"s

On Sun, May 06, 2018 at 04:10:26PM +0200, Martin Ågren wrote: > This series addresses two classes of "static struct lock_file", removing > the staticness: Those locks that already live inside a function, and > those that can simply be moved into the function they are used from. > > The first

Re: [PATCH 01/28] t/test-lib: add an SHA1 prerequisite

On 8 May 2018 at 01:30, brian m. carlson wrote: > On Mon, May 07, 2018 at 12:10:39PM +0200, Martin Ågren wrote: >> On 7 May 2018 at 01:17, brian m. carlson >> wrote: >> > Add an SHA1 prerequisite to annotate both of these types of

Re: [PATCH] pack-format.txt: more details on pack file format

On Tue, May 8, 2018 at 8:21 PM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, May 08 2018, Nguyễn Thái Ngọc Duy wrote: > >> The current document mentions OBJ_* constants without their actual >> values. A git developer would know these are from cache.h but that's >> not very

Re: [PATCH 06/28] t0000: annotate with SHA1 prerequisite

On 8 May 2018 at 01:40, brian m. carlson wrote: > On Mon, May 07, 2018 at 12:24:13PM +0200, Martin Ågren wrote: >> This could be more centralized at the top of the file, more likely to be >> noticed during a `make test` and easier to adapt in the future. Maybe >>

Re: [PATCH 2/2] Documentation: render revisions correctly under Asciidoctor

On 8 May 2018 at 03:13, brian m. carlson wrote: > On Mon, May 07, 2018 at 06:11:43AM +0200, Martin Ågren wrote: >> Excellent. These two patches fix my original problem and seem like the >> obviously correct approach (in hindsight ;-) ). I wonder if the diagrams >>

Re: [PATCH v3 13/15] git_config_set: make use of the config parser's event stream

On Tue, May 08, 2018 at 09:42:48AM -0400, Jeff King wrote: > On Mon, Apr 09, 2018 at 10:32:20AM +0200, Johannes Schindelin wrote: > > > +static int store_aux_event(enum config_event_t type, > > + size_t begin, size_t end, void *data) > > +{ > > + struct config_store_data

Re: [PATCH v3 06/12] get_short_oid: sort ambiguous objects by type, then SHA-1

On Tue, May 01, 2018 at 06:40:10PM +, Ævar Arnfjörð Bjarmason wrote: > Change the output emitted when an ambiguous object is encountered so > that we show tags first, then commits, followed by trees, and finally > blobs. Within each type we show objects in hashcmp() order. Before > this

Re: [PATCH v2 13/13] alloc: allow arbitrary repositories for alloc functions

On Tue, May 8, 2018 at 8:00 AM, Duy Nguyen wrote: > On Tue, May 8, 2018 at 12:59 AM, Stefan Beller wrote: >> @@ -501,9 +509,31 @@ void raw_object_store_clear(struct raw_object_store *o) >> void parsed_object_pool_clear(struct parsed_object_pool *o) >> {

Re: [PATCH v2 13/13] alloc: allow arbitrary repositories for alloc functions

On Mon, 7 May 2018 15:59:16 -0700 Stefan Beller wrote: > + for (i = 0; i < o->obj_hash_size; i++) { > + struct object *obj = o->obj_hash[i]; > + > + if (!obj) > + continue; > + > + if (obj->type == OBJ_TREE) { > +

Re: [PATCH 2/5] refs.c: do not die if locking fails in `write_pseudoref()`

On Mon, May 07, 2018 at 05:12:27AM -0600, David Turner wrote: > >Right. After commit 076aa2cbda (tempfile: auto-allocate tempfiles on > >heap, 2017-09-05) this is safe though. Quite a few locks have already > >been moved to the stack, e.g., in 14bca6c63c (sequencer: make lockfiles > >non-static,

Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

On Sun, May 06, 2018 at 04:10:29PM +0200, Martin Ågren wrote: > After taking the lock we check whether we got it and die otherwise. But > since we take the lock using `LOCK_DIE_ON_ERROR`, we would already have > died. > > Unlike in the previous patch, this function is not prepared for >