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] 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 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

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 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 v2 02/18] Add a new builtin: branch-diff

On Mon, May 7, 2018 at 9:50 AM, Jeff King wrote: > On Sat, May 05, 2018 at 11:57:26PM +0200, Johannes Schindelin wrote: > >> > It feels really petty complaining about the name, but I just want to >> > raise the point, since it will never be easier to change than right now. >> >> I

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

On Sun, May 6, 2018 at 9:32 PM, Martin Ågren <martin.ag...@gmail.com> wrote: > On 6 May 2018 at 19:42, Duy Nguyen <pclo...@gmail.com> wrote: >> On Sun, May 6, 2018 at 7:26 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>> On Sun, May 6, 2018 at 4:10 PM, Martin

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

On Sun, May 6, 2018 at 7:26 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Sun, May 6, 2018 at 4:10 PM, Martin Ågren <martin.ag...@gmail.com> wrote: >> These `struct lock_file`s are local to their respective functions and we >> can drop their staticness. >&g

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

On Sun, May 6, 2018 at 4:10 PM, Martin Ågren wrote: > These `struct lock_file`s are local to their respective functions and we > can drop their staticness. > > Signed-off-by: Martin Ågren > --- > apply.c| 2 +- > builtin/describe.c

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Sun, May 6, 2018 at 6:53 AM, Jacob Keller wrote: > On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic > wrote: >> Hi Dscho, >> >> On 05/05/2018 23:57, Johannes Schindelin wrote: >>> >>> > > This builtin does not do a whole lot so far, apart

Re: [PATCH v2 18/18] completion: support branch-diff

On Fri, May 04, 2018 at 05:35:11PM +0200, Johannes Schindelin wrote: > Tab completion of `branch-diff` is very convenient, especially given > that the revision arguments that need to be passed to `git branch-diff` > are typically more complex than, say, your grandfather's `git log` > arguments. >

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

On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote: > Teach 'git-grep(1)' a new option, '--column', to show the column > number of the first match on a non-context line. Why? Or put it another way, what is this option used for? Only git-jump? (which should also be mentioned

Re: [PATCH] alloc.c: replace alloc by mempool

On Fri, May 4, 2018 at 12:18 AM, Stefan Beller wrote: > I just measured on git.git and linux.git (both of which are not *huge* by > any standard, but should give a good indication. linux has 6M objects, > and when allocating 1024 at a time, we run into the new block

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Fri, May 4, 2018 at 5:23 PM, Johannes Schindelin wrote: >> > So that's what `info` does: it influences whether/where >> > the command is listed in `git help`'s output... Interesting. I thought the >> > lines here were trying to automate parts of the tab completion

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Fri, May 04, 2018 at 04:44:49PM +0200, Duy Nguyen wrote: > On Fri, May 4, 2018 at 9:23 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > Oh, okay. It was not at all clear to me what the exact format and role of > > these lines are... > >

Re: [PATCH v2] checkout & worktree: introduce checkout.implicitRemote

On Fri, May 4, 2018 at 9:54 AM, Ævar Arnfjörð Bjarmason wrote: > Realistically the way we do hooks now would make the UI of this suck, > i.e. you couldn't configure it globally or system-wide easily. Something > like what I noted in >

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Fri, May 4, 2018 at 9:23 AM, Johannes Schindelin wrote: > Oh, okay. It was not at all clear to me what the exact format and role of > these lines are... Noted. I'm making more updates in this file in another topic and will add some explanation so the next guy will

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Thu, May 3, 2018 at 10:32 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Duy, > > On Thu, 3 May 2018, Johannes Schindelin wrote: > >> On Thu, 3 May 2018, Duy Nguyen wrote: >> >> > On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin

Re: [PATCH v2 0/5] Allocate cache entries from memory pool

On Thu, May 3, 2018 at 7:21 PM, Stefan Beller <sbel...@google.com> wrote: > On Thu, May 3, 2018 at 9:35 AM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller <jam...@microsoft.com> wrote: >>> This patch series improve

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

On Thu, May 3, 2018 at 7:24 PM, 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 think you're leaking memory here.

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin wrote: > diff --git a/command-list.txt b/command-list.txt > index a1fad28fd82..c89ac8f417f 100644 > --- a/command-list.txt > +++ b/command-list.txt > @@ -19,6 +19,7 @@ git-archive

Re: [PATCH v2 0/5] Allocate cache entries from memory pool

On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote: > This patch series improves the performance of loading indexes by > reducing the number of malloc() calls. Loading the index from disk is > partly dominated by the time in malloc(), which is called for each > index

Re: [PATCH v2 5/5] block alloc: add validations around cache_entry lifecyle

On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote: > Add an option (controlled by an environment variable) perform extra > validations on mem_pool allocated cache entries. When set: > > 1) Invalidate cache_entry memory when discarding cache_entry. > > 2) When

Re: [PATCH v2 3/5] mem-pool: fill out functionality

Another I noticed in the jm/mem-pool series is this loop in mem_pool_alloc() for (p = mem_pool->mp_block; p; p = p->next_block) if (p->end - p->next_free >= len) break; You always go from the start (mp_block) but at some point those first blocks are filled up and we don't

Re: [PATCH v2] checkout & worktree: introduce checkout.implicitRemote

On Thu, May 3, 2018 at 3:18 PM, Ævar Arnfjörð Bjarmason wrote: > Introduce a checkout.implicitRemote setting which can be used to > designate a remote to prefer (via checkout.implicitRemote=origin) when > running e.g. "git checkout master" to mean origin/master, even though >

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

On Tue, May 1, 2018 at 11:34 PM, Stefan Beller wrote: > @@ -501,9 +516,12 @@ void raw_object_store_clear(struct raw_object_store *o) > void object_parser_clear(struct object_parser *o) > { > /* > -* TOOD free objects in o->obj_hash. > -* You need to

Re: [PATCH 00/13] object store: alloc

On Wed, May 2, 2018 at 8:07 PM, Jameson Miller <jam...@microsoft.com> wrote: > > >> -Original Message- >> From: Duy Nguyen <pclo...@gmail.com> >> Sent: Wednesday, May 2, 2018 1:02 PM >> To: Stefan Beller <sbel...@google.com> >> Cc:

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 8:00 PM, Eric Sunshine wrote: > 2. Building on #1: How well is the term "DWIM" understood by non-power > users? A term, such as "default" is more well known. I'm going off topic but I kinda dislike this term. First time I encountered it in the code

Re: [PATCH 01/13] repository: introduce object parser field

On Wed, May 2, 2018 at 7:26 PM, Stefan Beller wrote: >> Another suggestion is object_pool, if we keep 'struct object' instead >> of 'struct parsed_object' and also want to keep current allocation >> behavior: no individual deallocation. If you free, you free the whole >> pool

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

On Tue, May 1, 2018 at 11:34 PM, Stefan Beller wrote: > #include "cache.h" > #include "object.h" > @@ -30,8 +31,25 @@ struct alloc_state { > int count; /* total number of nodes allocated */ > int nr;/* number of nodes left in current allocation */ >

Re: [PATCH 01/13] repository: introduce object parser field

On Tue, May 1, 2018 at 11:33 PM, 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 00/13] object store: alloc

On Tue, May 1, 2018 at 11:33 PM, Stefan Beller wrote: > I also debated if it is worth converting alloc.c via this patch series > or if it might make more sense to use the new mem-pool by Jameson[1]. > > I vaguely wonder about the performance impact, as the object allocation >

Re: [PATCH v2 00/42] object_id part 13

On Wed, May 02, 2018 at 12:25:28AM +, brian m. carlson wrote: > Changes from v1: > * Add missing sign-off. > * Removed unneeded braces from init_pack_info. > * Express 51 in terms of the_hash_algo->hexsz. > * Fix comments referring to SHA-1. > * Update commit messages as suggested. > * Add and

Re: [PATCH 08/41] packfile: abstract away hash constant values

On Wed, May 2, 2018 at 2:11 AM, brian m. carlson <sand...@crustytoothpaste.net> wrote: > On Tue, May 01, 2018 at 12:22:43PM +0200, Duy Nguyen wrote: >> On Mon, Apr 23, 2018 at 11:39:18PM +, brian m. carlson wrote: >> > There are several instances of the constan

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason wrote: > Introduce a core.DWIMRemote setting which can be used to designate a > remote to prefer (via core.DWIMRemote=origin) when running e.g. "git > checkout master" to mean origin/master, even though there's other >

Re: [PATCH v2 1/4] test-tool: help verifying BUG() code paths

On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin wrote: > When we call BUG(), we signal via SIGABRT that something bad happened, > dumping cores if so configured. In some setups these coredumps are > redirected to some central place such as

Re: completion troubles with bash

On Tue, May 1, 2018 at 2:17 PM, Pascal Bourdier wrote: > Hi, > > > If "GREP_OPTIONS" is set to '--color=always' , then the git completion > send some escape characters like this : > > ^[[1;35;40m^[[K d^[[m^[[Kiff-files mergetool >

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 11:50 AM, Ævar Arnfjörð Bjarmason wrote: > I think at this point git-subtree is widely used enough to move out of > contrib/, maybe others disagree, but patches are always better for > discussion that patch-less ML posts. After narrow/partial clone

Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin wrote: > t1406 specifically verifies that certain code paths fail with a BUG: ... > message. > > In the upcoming commit, we will convert that message to be generated via > BUG() instead of die("BUG: ..."), which

Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

On Tue, May 1, 2018 at 1:04 PM, Johannes Schindelin wrote: >> If SIGABRT occurs as a result of BUG(), and we know that this happens for >> certain cases, it means we have an unfixed bug. > > Not in this case: The code in question is in >

Re: [PATCH 00/41] object_id part 13

On Mon, Apr 30, 2018 at 11:59:43PM +, brian m. carlson wrote: > > I guess I'll be helping review this series instead :D Overall I think this looks good. > > Yeah, I have code to fix that, but it's ugly. > > You can see the work on part2 and part3 of the test fixes, plus the > fixes for all

Re: [PATCH 39/41] Update shell scripts to compute empty tree object ID

On Mon, Apr 23, 2018 at 11:39:49PM +, brian m. carlson wrote: > Several of our shell scripts hard-code the object ID of the empty tree. > To avoid any problems when changing hashes, compute this value on > startup of the script. For performance, store the value in a variable > and reuse it

Re: [PATCH 09/41] pack-objects: abstract away hash algorithm

On Mon, Apr 23, 2018 at 11:39:19PM +, brian m. carlson wrote: > @@ -1850,7 +1852,7 @@ static int try_delta(struct unpacked *trg, struct > unpacked *src, > /* Now some size filtering heuristics. */ > trg_size = trg_entry->size; > if (!trg_entry->delta) { > -

Re: [PATCH 08/41] packfile: abstract away hash constant values

On Mon, Apr 23, 2018 at 11:39:18PM +, brian m. carlson wrote: > There are several instances of the constant 20 and 20-based values in > the packfile code. Abstract away dependence on SHA-1 by using the > values from the_hash_algo instead. While we're abstracting away 20. There's the only 20

Re: [PATCH 04/41] packfile: remove unused member from struct pack_entry

On Mon, Apr 23, 2018 at 11:39:14PM +, brian m. carlson wrote: > The sha1 member in struct pack_entry is unused except for one instance > in which we store a value in it. Since nobody ever reads this value, > don't bother to compute it and remove the member from struct pack_entry. Never used

Re: [PATCH 03/41] Remove unused member in struct object_context

On Mon, Apr 23, 2018 at 11:39:13PM +, brian m. carlson wrote: > The tree member of struct object_context is unused except in one place > where we write to it. Since there are no users of this member, remove > it. Yep. It's never used since its introduction in 573285e552 (sha1_name: add

Re: [PATCH 02/41] server-info: remove unused members from struct pack_info

On Mon, Apr 23, 2018 at 11:39:12PM +, brian m. carlson wrote: > The head member of struct pack_info is completely unused and the > nr_heads member is used only in one place, which is an assignment. > Since these structure members are not useful, remove them. If you reroll, you could add that

Re: [PATCH 01/41] cache: add a function to read an object ID from a buffer

On Mon, Apr 23, 2018 at 11:39:11PM +, brian m. carlson wrote: > diff --git a/cache.h b/cache.h > index bbaf5c349a..4bca177cf3 100644 > --- a/cache.h > +++ b/cache.h > @@ -1008,6 +1008,11 @@ static inline void oidclr(struct object_id *oid) > memset(oid->hash, 0, GIT_MAX_RAWSZ); > } > >

Re: [PATCH 00/41] object_id part 13

On Tue, Apr 24, 2018 at 1:39 AM, brian m. carlson wrote: > [0] I can synthesize blobs, trees, and commits, but things are currently > totally broken, which is, I suppose, to be expected. Yup. I was tired and bored so I went playing with the new hash. Writing and

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

On Mon, Apr 30, 2018 at 6:19 PM, Elijah Newren <new...@gmail.com> wrote: > Hi Duy, > > On Mon, Apr 30, 2018 at 7:45 AM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Mon, Apr 30, 2018 at 4:42 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>> On Sun, Apr

Re: [PATCH v5 00/10] Keep all info in command-list.txt in git binary

This is probably scope creep for this series, but do you guys think we should do the same for config variables completion? We currently maintain a giant list at the end of _git_config(). Extracting the list from Documentation/config.txt to keep it in a C array does not look super hard. There will

Re: [RFC PATCH] checkout: Force matching mtime between files

On Mon, Apr 30, 2018 at 1:56 AM, Junio C Hamano <gits...@pobox.com> wrote: > Duy Nguyen <pclo...@gmail.com> writes: > >> Target revision should be available in the index. But this gives me an >> idea to another thing that bugs me: sending the list to the hook means &g

Re: [PATCH v1] test-drop-caches: simplify delay loading of NtSetSystemInformation

On Mon, Apr 30, 2018 at 4:26 PM, Ben Peart wrote: > Take advantage of the recent addition of support for lazy loading functions > on Windows to simplfy the loading of NtSetSystemInformation. > > Signed-off-by: Ben Peart > --- > > Notes: > Base

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

On Mon, Apr 30, 2018 at 4:42 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Sun, Apr 29, 2018 at 10:53 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >>> > @@ -1412,12 +1422,13 @@ int unpack_trees(unsigned len, struct tree_desc >>

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

On Sun, Apr 29, 2018 at 10:53 PM, Johannes Schindelin wrote: >> > @@ -1412,12 +1422,13 @@ int unpack_trees(unsigned len, struct tree_desc >> > *t, struct unpack_trees_options >> > WRITE_TREE_SILENT | >> >

Re: [PATCH v5 09/10] help: use command-list.txt for the source of guides

Phillip (and others) the changes in this patch make "git help -g" now lists a lot more guides than just the "common" one as advertised (see below for the exact list). The man page for "git help -g" also mentions that it would list "useful" guides, not all guides. But we have no way to list all

Re: [PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

On Tue, Apr 24, 2018 at 8:50 AM, Elijah Newren wrote: > Currently, all callers of unpack_trees() set o->src_index == o->dst_index. > The code in unpack_trees() does not correctly handle them being different. > There are two separate issues: > > First, there is the possibility of

Re: [PATCH v4/wip 02/12] generate-cmds.sh: export all commands to command-list.h

On Wed, Apr 25, 2018 at 8:07 PM, Eric Sunshine wrote: > On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy > wrote: >> The current generate-cmds.sh generates just enough to print "git help" >> output. That is, it only extracts help text for common

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote: > For the record, we're using this with ebuilds and respective cache files > (which are expensive to generate). We are using separate repository > which combines sources and cache files to keep the development > repository

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 27, 2018 at 11:08 PM, Marc Branchaud wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud >> This is a limitation of the current post-checkout hook. $3==0 from the >> hook lets us know this is not a branch switch, but it does not

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 27, 2018 at 11:08 PM, Elijah Newren <new...@gmail.com> wrote: > On Fri, Apr 27, 2018 at 10:03 AM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud <marcn...@xiplink.com> wrote: >>> >>> * In a "f

Re: [PATCH 18/41] index-pack: abstract away hash function constant

On Fri, Apr 27, 2018 at 11:08 PM, brian m. carlson <sand...@crustytoothpaste.net> wrote: > On Thu, Apr 26, 2018 at 05:46:28PM +0200, Duy Nguyen wrote: >> On Wed, Apr 25, 2018 at 8:49 PM, Martin Ågren <martin.ag...@gmail.com> wrote: >> > Once that is accomplished, I

Re: [RFC PATCH] checkout: Force matching mtime between files

On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: >> The best approach to do so is to have those people do the "touch" >> thing in their own post-checkout hook. People who use Git as the >> source control system won't have to pay runtime cost of doing the >> touch

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 07:53:58PM +0200, SZEDER Gábor wrote: > BTW, wouldn't running > > git clone --template=/path/to/template/dir/with/hooks/ > > invoke the post-checkout hook in there? > Yes but it's cumbersome, preparing a template just for one extra hook. I never like this template

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 05:48:35PM +, Robin H. Johnson wrote: > On Thu, Apr 26, 2018 at 06:43:56PM +0200, Duy Nguyen wrote: > > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud <marcn...@xiplink.com> > > wrote: > > > Are we all that sure that the performance h

Re: [RFC PATCH] checkout: Force matching mtime between files

On Wed, Apr 25, 2018 at 10:41:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > 2. Add some config so we can have hook search paths, and ship with a > default search path for hooks shipped with git. I would go for something like this instead of search paths. This allows you to specify a path to

Re: [RFC PATCH] checkout: Force matching mtime between files

On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: > Are we all that sure that the performance hit is that drastic? After all, > we've just done write_entry(). Calling utime() at that point should just > hit the filesystem cache. I have a feeling this has "this is

Re: [PATCH 18/41] index-pack: abstract away hash function constant

On Wed, Apr 25, 2018 at 8:49 PM, Martin Ågren wrote: >> I agree that pack v2 is not going to have anything but SHA-1. However, >> writing all the code such that it's algorithm agnostic means that we can >> do testing of new algorithms by wholesale replacing the algorithm

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

On Wed, Apr 25, 2018 at 10:37 AM, Junio C Hamano wrote: > * nd/pack-objects-pack-struct (2018-04-16) 15 commits > ... > > "git pack-objects" needs to allocate tons of "struct object_entry" > while doing its work, and shrinking its size helps the performance > quite a bit. >

Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Wed, Apr 25, 2018 at 3:46 PM, SZEDER Gábor <szeder@gmail.com> wrote: > On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>> git-completion.bash will be upda

Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Wed, Apr 25, 2018 at 3:06 PM, SZEDER Gábor wrote: >> -__git_list_all_commands () > >> -__git_list_porcelain_commands () > > Users can have their own completion scriptlets for their own git > commands, and these should be able to rely on helper functions in >

Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen <pclo...@gmail.com> wrote: > git-completion.bash will be updated to ask git "give me the commands > in the mainporcelain, completable or external category". This also > addresses another thing that bugs me: I wanted an option

Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Mon, Apr 23, 2018 at 3:32 PM, SZEDER Gábor wrote: > But then I noticed that it's not an accurate description of the > current situation, because there is a wide grey area between > porcelains and plumbing, and the completion script doesn't "filter out > plumbing

Re: [RFC PATCH v10 32.5/36] unpack_trees: fix memory corruption with split_index when src != dst

On Mon, Apr 23, 2018 at 7:09 PM, Elijah Newren <new...@gmail.com> wrote: > Hi, > > On Sun, Apr 22, 2018 at 5:38 AM, Duy Nguyen <pclo...@gmail.com> wrote: >>> - there's a better, more performant fix or there is some way to actually >>> share a split_in

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones wrote: >>> I think you need to try a little harder than this! ;-) >> >> Yeah. I did think about grepping the output but decided not to because >> of gettext poison stuff and column output in "git help". If we do want >> to

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 4:45 PM, Ramsay Jones <ram...@ramsayjones.plus.com> wrote: > > > On 21/04/18 17:56, Duy Nguyen wrote: >> On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: >>> Changes: >>> >>> - remove the deprec

Re: [RFC PATCH v10 32.5/36] unpack_trees: fix memory corruption with split_index when src != dst

On Sat, Apr 21, 2018 at 9:37 PM, Elijah Newren wrote: > Currently, all callers of unpack_trees() set o->src_index == o->dst_index. > Since we create a temporary index in o->result, then discard o->dst_index > and overwrite it with o->result, when o->src_index == o->dst_index it

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: > Changes: > > - remove the deprecated column in command-list.txt. My change break it > anyway if anyone uses it. > - fix up failed tests that I marked in the RFC and kinda forgot about it. > - fix bashisms in

Re: [PATCH v2 1/2] completion: stop showing 'save' for stash by default

On Fri, Apr 20, 2018 at 1:25 AM, Thomas Gummerer wrote: > The 'save' subcommand in git stash has been deprecated in > fd2ebf14db ("stash: mark "git stash save" deprecated in the man page", > 2017-10-22). > > Stop showing it when the users enters 'git stash ' or 'git stash >

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Wed, Apr 18, 2018 at 12:47 AM, Philip Oakley wrote: >>> > Is that something I should add to my todo to add a 'guide' category > >>> > etc.? >>> >>> I added it too [1]. Not sure if you want anything more on top though. > > > What I've seen is looking good - I've not had as

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

On Wed, Apr 18, 2018 at 5:43 AM, Junio C Hamano wrote: > So, the earlier mention of "clone --no-checkout" sounded about not > losing this historical practice, but (desirabilty of magic number 4 > aside) this "show first handful of --no-foo" feature is not about > historical

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Tue, Apr 17, 2018 at 06:24:41PM +0200, Duy Nguyen wrote: > On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley <philipoak...@iee.org> wrote: > > From: "Duy Nguyen" <pclo...@gmail.com> : Saturday, April 14, 2018 4:44 PM > > > >> On Thu, Apr 12, 2018 at

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley <philipoak...@iee.org> wrote: > From: "Duy Nguyen" <pclo...@gmail.com> : Saturday, April 14, 2018 4:44 PM > >> On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley <philipoak...@iee.org> >> wrote: &

Re: [PATCH v2 3/6] generate-cmdlist.sh: keep all information in common-cmds.h

On Mon, Apr 16, 2018 at 8:28 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> @@ -23,28 +36,44 @@ sed -n ' >> ' "$1" >> printf '};\n\n' >> >> +echo "#define GROUP_NONE 0xff /* no common group */" > > Some later code forgets about this

Re: .gitattributes lookup doesn't respect GIT_WORK_TREE

On Mon, Apr 16, 2018 at 12:40 AM, Andreas Schwab wrote: > On Apr 16 2018, Junio C Hamano wrote: > >> I may be mistaken (I do not have the code in front of me right now) >> but IIRC after the setup.c code runs (which happens quite early in >> the sequence

Re: [PATCH/RFC 3/5] generate-cmdlist.sh: keep all information in common-cmds.h

On Mon, Apr 9, 2018 at 6:59 AM, Eric Sunshine wrote: >> +awk '{print $2;}' | > > At one time, Junio expressed concerns[2] about having an 'awk' > dependency in the build system (in fact, with regards to this same > generation process). Whether he still has such concerns

Re: [PATCH v1 0/2] fsexcludes: Add programmatic way to exclude files

On Tue, Apr 10, 2018 at 11:04 PM, Ben Peart wrote: > In git repos with large working directories an external file system monitor > (like fsmonitor or gvfs) can track what files in the working directory have > been > modified. This information can be used to speed up git

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley wrote: > I'm only just catching up, but does/can this series also capture the > non-command guides that are available in git so that the 'git help -g' can > begin to list them all? It currently does not. But I don't see why it

Re: [PATCH/RFC 3/5] generate-cmdlist.sh: keep all information in common-cmds.h

On Mon, Apr 9, 2018 at 6:59 AM, Eric Sunshine wrote: > On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy > wrote: >> common-cmds.h is used to extract the list of common commands (by >> group) and a one-line summary of each command. Some

Re: [PATCH 1/2] git-worktree.txt: recommend 'git worktree remove' over manual deletion

On Mon, Apr 9, 2018 at 9:33 AM, Eric Sunshine wrote: > When cc73385cf6 (worktree remove: new command, 2018-02-12) implemented > and documented 'git worktree remove', it forgot to update existing > instructions suggesting manual deletion. Fix this oversight by >

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

On Mon, Apr 9, 2018 at 12:21 PM, Junio C Hamano wrote: > * sb/packfiles-in-repository (2018-03-26) 12 commits > (merged to 'next' on 2018-03-30 at caa68db14d) > + packfile: keep prepare_packed_git() private > + packfile: allow find_pack_entry to handle arbitrary

Re: [PATCH/RFC 5/5] help: add "-a --verbose" to list all commands with synopsis

On Mon, Apr 9, 2018 at 11:55 AM, Eric Sunshine wrote: > On Mon, Apr 9, 2018 at 5:47 AM, Junio C Hamano wrote: >> Eric Sunshine writes: >>> On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy >>> wrote:

Re: [PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

On Sat, Apr 7, 2018 at 2:36 PM, Ævar Arnfjörð Bjarmason wrote: > Anyway, I see you've pushed a new version with DEVOPTS. I'll submit mine > on top of that once your new version lands (unless you want to try to > integrate it yourself). Actually I think I'll just drop both

Re: [PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

On Fri, Apr 6, 2018 at 11:42 PM, Jeff King <p...@peff.net> wrote: > On Tue, Apr 03, 2018 at 05:17:00PM +0200, Duy Nguyen wrote: > >> It's not that complex. With the EAGER_DEVELOPER patch removed, we can >> have something like this where eager devs just need to put &g

Re: [RFC PATCH 00/19] object-store refactoring 3 (replace objects, main ref store)

On Sat, Apr 7, 2018 at 1:21 AM, Stefan Beller wrote: * > diff --git a/repository.h b/repository.h > index 09df94a472..2922d3a28b 100644 > --- a/repository.h > +++ b/repository.h > @@ -26,6 +26,11 @@ struct repository { > */ > struct raw_object_store

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin wrote: > It is very frustrating to spend that much time with only little gains here > and there (and BusyBox-w32 is simply not robust enough yet, apart from > also not showing a significant improvement in

Re: [PATCH] t2028: tighten grep expression to make "move worktree" test more robust

On Tue, Apr 3, 2018 at 11:25 AM, Eric Sunshine wrote: > Following a rename of worktree "source" to "destination", the "move > worktree" test uses grep to verify that the output of "git worktree list > --porcelain" does not contain "source" (and does contain

Re: [PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

On Tue, Apr 03, 2018 at 11:19:46AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Mar 31 2018, Duy Nguyen wrote: > > > On Sat, Mar 31, 2018 at 6:40 PM, Ævar Arnfjörð Bjarmason > > <ava...@gmail.com> wrote: > >> Change the DEVELOPER flag, and the newly a

Re: [PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

On Sat, Mar 31, 2018 at 6:40 PM, Ævar Arnfjörð Bjarmason wrote: > Change the DEVELOPER flag, and the newly added EAGER_DEVELOPER flag > which (approximately) enables -Wextra so that any combination of them > and -Werror can be set. > > I've long wanted to use DEVELOPER=1 in my

Re: [PATCH v8 00/15] nd/pack-objects-pack-struct updates

On Sat, Mar 31, 2018 at 1:36 PM, Ævar Arnfjörð Bjarmason wrote: >> +GIT_TEST_SPLIT_INDEX forces split-index mode on the whole test suite. >> + >> GIT_TEST_FULL_IN_PACK_ARRAY exercises the uncommon pack-objects code >> path where there are more than 1024 packs even if the

<    2   3   4   5   6   7   8   9   10   11   >