Re: cherry-pick --no-commit does not work well with --continue in case of conflicts

Ilya Kantor writes: > P.S. I assume, `cherry-pick -n ` is meant to merge given > commits' changes into the current working directory and the index, > without making new commits, for any given set of commits, hope that's right? Hmph. One step in cherry-pick should refuse to

Re: [PATCH 8/8] fetch: stop clobbering existing tags without --force

Ævar Arnfjörð Bjarmason writes: > > Tags need not be pointing at commits so there is no way to > > guarantee "fast-forward" anyway. The observation the above statement makes is not incorrect per-se, but it does not justify "anything goes". "nothing is allowed unless

Re: [PATCH 5/8] push doc: correct lies about how push refspecs work

Ævar Arnfjörð Bjarmason writes: > + > The is often the name of the branch you would want to push, but > -it can be any arbitrary "SHA-1 expression", such as `master~4` or > -`HEAD` (see linkgit:gitrevisions[7]). > +it can be any arbitrary "SHA-1 expression" referring to a

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

On Tuesday 08 May 2018 07:28 AM, brian m. carlson wrote: > An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to > individual persons", 2013-08-12), noted that there were two name > spellings and two email addresses and mapped the crustytoothpaste.net > address to the

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

Ævar Arnfjörð Bjarmason writes: > Change the test that asserts that lightweight tags can only be > clobbered by a force-push to check do the same tests for annotated > tags. > > There used to be less exhaustive tests for this with the code added in > 40eff17999 ("push: require

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

Nguyễn Thái Ngọc Duy writes: > The help command currently hard codes the list of guides and their > summary in C. Let's move this list to command-list.txt. This lets us > extract summary lines from Documentation/git*.txt. This also > potentially lets us list guides in

Re: [PATCH v6 08/13] git: support --list-cmds=list-

Nguyễn Thái Ngọc Duy writes: > This allows us to select any group of commands by a category defined > in command-list.txt. This is an internal/hidden option so we don't > have to be picky about the category name or worried about exposing too > much. > > This will be used

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

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 > status. But, what would be a good form for such

Re: [PATCH v6 05/13] git.c: convert --list-* to --list-cmds=*

Nguyễn Thái Ngọc Duy writes: > Even if these are hidden options, let's make them a bit more generic > since we're introducing more listing types shortly. The code is > structured to allow combining multiple listing types together because > we will soon add more types the

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

On Mon, May 07, 2018 at 11:44:29PM -0400, Jeff King wrote: > On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote: > > > Hence I propose "git range-diff", similar to topic-diff, that > > was proposed earlier. > > > > * it "diffs ranges" of commits. > > * it can also deal with

Re: [PATCH v6 02/13] generate-cmds.sh: export all commands to command-list.h

Nguyễn Thái Ngọc Duy writes: > The current generate-cmds.sh generates just enough to print "git help" > output. That is, it only extracts help text for common commands. > > The script is now updated to extract help text for all commands and > keep command classification a new

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

On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote: > Hence I propose "git range-diff", similar to topic-diff, that > was proposed earlier. > > * it "diffs ranges" of commits. > * it can also deal with out-of-git things like patch series, > but that is a mere by product and may not

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

Todd Zullinger writes: > Hi Matthew, > > Matthew Coleman wrote: >> I haven't seen any discussion about this recently. What >> are the chances of getting it merged? I'd like to see this >> included in 2.18. > > Junio's last few "What's cooking" updates have mentioned it: > >> *

Re: main url for linking to git source?

Konstantin Ryabitsev writes: > 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 bandwidth

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

"brian m. carlson" writes: > An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to > individual persons", 2013-08-12), noted that there were two name > spellings and two email addresses and mapped the crustytoothpaste.net > address to the

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

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 version because of the (lack of) > prefix on the refspec does not

Re: main url for linking to git source?

On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote: > On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote: > > There I would try to mirror Junios list of "public repositories" > > https://git-blame.blogspot.com/p/git-public-repositories.html > > without officially endorsing

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

Ævar Arnfjörð Bjarmason writes: > Improve the tests added in dbfeddb12e ("push: require force for refs > under refs/tags/", 2012-11-29) to assert that the same behavior > applies various forms other refspecs, and that "+" in a refspec will > override the "--no-force" option

Re: [GSoC] Yet another blog series about the GSoC

On Tue, May 8, 2018 at 12:20 AM, Stefan Beller wrote: > Hi Pratik, Hi Stefan, > On Sat, May 5, 2018 at 5:24 AM, Pratik Karki wrote: >> On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote: >>> Hi everybody, >>> >>> as my fellow

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

Hi Matthew, Matthew Coleman wrote: > I haven't seen any discussion about this recently. What > are the chances of getting it merged? I'd like to see this > included in 2.18. Junio's last few "What's cooking" updates have mentioned it: > * sg/completion-clear-cached (2018-04-18) 1 commit >

Re: [PATCH v2 12/18] branch-diff: use color for the commit pairs

Hi Johannes, Johannes Schindelin wrote: > Hi Todd, > > On Sat, 5 May 2018, Todd Zullinger wrote: > >>> @@ -430,6 +451,8 @@ int cmd_branch_diff(int argc, const char **argv, const >>> char *prefix) >>> struct string_list branch1 = STRING_LIST_INIT_DUP; >>> struct string_list branch2 =

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

An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to individual persons", 2013-08-12), noted that there were two name spellings and two email addresses and mapped the crustytoothpaste.net address to the crustytoothpaste.ath.cx address. The latter is an older, obsolete address,

Re: main url for linking to git source?

On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote: > There I would try to mirror Junios list of "public repositories" > https://git-blame.blogspot.com/p/git-public-repositories.html > without officially endorsing one over another. I think I would also prefer a list of available

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

On Mon, May 07, 2018 at 06:11:43AM +0200, Martin Ågren wrote: > On 6 May 2018 at 22:42, brian m. carlson wrote: > > When creating a literal block from an indented block without any sort of > > delimiters, Asciidoctor strips off all leading whitespace, resulting in >

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

Stefan Beller writes: > The replacement with mem-pool might be easier than making sure > that alloc.c has no globals and handles allocations per repository > correctly. It would make the sb/object-store-alloc series shorter than > it currently is, and maybe easier to review

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

Elijah Newren writes: >> Rename detection logic in "diff" family that is used in "merge" has >> learned to guess when all of x/a, x/b and x/c have moved to z/a, >> z/b and z/c, it is likely that x/d added in the meantime would also >> want to move to z/d by taking the hint

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

Elijah Newren writes: > I'm actually curious what the "Will merge to 'master'" and "Will merge > to 'next'" are intended to mean in general. I thought it meant that > the topic would be merged the following week barring further > discussion, but that hasn't always been the

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

On Mon, May 7, 2018 at 5:37 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> So I think we could just replace it for now and optimize again later, if it >>> turns out to be a problem. I think the easiest optimisation is to increase >>> the allocation

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

Duy Nguyen writes: >> So I think we could just replace it for now and optimize again later, if it >> turns out to be a problem. I think the easiest optimisation is to increase >> the allocation size of having a lot more objects per mp_block. > > Yeah. I also tested this from a

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

Jeff King writes: > One of the things I don't like about "git branch --diff" is that this > feature is not _just_ about branches at all. I actually wouldn't be that much against the word "branch" in "branch-diff" on the ground that we are typically not feeding branches to the

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

On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote: > On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option > > prints only the matching components of each line. It writes multiple > > lines if

Re: [PATCH 1/2] grep.c: extract show_line_header()

On Sat, May 05, 2018 at 03:30:51AM -0400, Eric Sunshine wrote: > On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > > Teach 'git-grep(1)' how to print a line header multiple times from > > show_line() in preparation for it learning '--only-matching'. > > > >

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

On Mon, May 07, 2018 at 11:13:12PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt > > index 18b494731f..5409a24399 100644 > > --- a/Documentation/git-grep.txt > > +++ b/Documentation/git-grep.txt > >

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

On Mon, May 07, 2018 at 12:25:09PM -0700, Stefan Beller wrote: > brian, > > sorry to break you there. I was the author of the patch Junio found, > organizing > the .mailmap file was one of my starter contributions. I recall asking all the > people if they were ok with it their names combined in

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

On Mon, May 07, 2018 at 12:37:05PM +0900, Junio C Hamano wrote: > I initially reacted to "was reversed" with "yikes, did we break the > mailmap reader and we need to update the file?", but apparently that > is not what this patch is about. I think what is happening here is > that cdb6b5ac

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

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 > something like this at the top of the file: > > if hash for storage is SHA-1 then >

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

On Sun, May 06, 2018 at 07:56:42PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sat, May 05 2018, Taylor Blau wrote: > > > > + test_expect_success "grep -w $L (with --{line,column}-number)" ' > > It's now --column in v4 but this still refers to v3 --column-number. Thanks, I certainly missed

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

Hi Stefan, On 08/05/2018 00:24, Stefan Beller wrote: > > > List, rename, delete -- all these seem more as basic CRUD operations, > > where comparison is a more complex one. And not to get me wrong - I > > could see "branch diff" being part of "branch", but not really when > > "diff" already

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

On Sat, May 05, 2018 at 08:15:03AM +0200, Duy Nguyen wrote: > 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

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

On Sun, May 06, 2018 at 08:03:01PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sun, May 06 2018, Martin Ågren wrote: > > > On 5 May 2018 at 04:43, Taylor Blau wrote: > >> Take advantage of 'git-grep(1)''s new option, '--column' in order to > >> teach Peff's 'git-jump' script

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

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 tests and > > disable them when we're using a different hash. In the future, we can > >

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

On Mon, May 07, 2018 at 05:45:00AM -0400, Jeff King wrote: > Isn't that basically what this patch is, though? Or at least a step in > that direction? For generic signing support, you need: > > 1. A way to tell Git to recognize that a signature exists, and what > type it is. > > 2. A way

[PATCH v2 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 --- alloc.c | 2 +- cache.h

[PATCH v2 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 v2 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 --- alloc.c | 2 +- cache.h

[PATCH v2 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 --- alloc.c | 2

[PATCH v2 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 --- alloc.c | 2 +- cache.h

[PATCH v2 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 v2 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 v2 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 --- object.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/object.c b/object.c index

[PATCH v2 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 --- alloc.c | 2 +-

[PATCH v2 00/13] object store: alloc

v2: * I decided to stick with alloc.c and not migrate it to the mem-pool for now. The reasoning for that is that mem-pool.h would introduce some alignment waste, which I really did not want to. * renamed to struct parsed_object_pool; * free'd the additional memory of trees and commits. * do

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

Reviewed-by: Jonathan Tan Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller --- object.c | 12 ++-- object.h | 3 +-- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/object.c b/object.c index

[PATCH v2 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 --- alloc.c | 4 ++--

[PATCH v2 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 --- alloc.c | 2 +- blob.c

[PATCH v2 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.

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

On Mon, May 7, 2018 at 3:05 PM, Igor Djordjevic wrote: > List, rename, delete -- all these seem more as basic CRUD operations, > where comparison is a more complex one. And not to get me wrong - I > could see "branch diff" being part of "branch", but not really when

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

Hi Dscho, On 07/05/2018 03:34, Johannes Schindelin wrote: > > > > I think Todd's idea to shift it from a full-blown builtin to a cmdmode > > > of `branch` makes tons of sense. > > > > I don`t know, I still find it a bit strange that in order to "diff > > something", you go to "something" and

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

On 07/05/2018 09:48, Jeff King wrote: > > > > Let's, please, not fall into the trap of polluting git-branch with > > > utterly unrelated functionality, as has happened a few times with > > > other Git commands. Let's especially not do so merely for the sake of > > > tab-completion. git-branch is

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

On 7 May 2018 at 17:24, Duy Nguyen wrote: > On Sun, May 6, 2018 at 9:32 PM, Martin Ågren wrote: >> On 6 May 2018 at 19:42, Duy Nguyen wrote: >> Thank you Duy for your comments. How about I write the commit message >> like so: > >

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

Hi Junio, On Mon, May 7, 2018 at 7:05 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> This applies on top of sb/oid-object-info and is the logical continuum of >> the series that it builds on; this brings the object store into more of >> Gits code,

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

On Mon, May 7, 2018 at 8:28 AM, Duy Nguyen wrote: >>> I do hear you. Especially since I hate `git cherry` every single time that >>> I try to tab-complete `git cherry-pick`. >> >> Me too. :) > > Just so you know I'm also not happy with that "git cherry". Since I'm > updating

Dearest

Dearest, I am Sister Renee Shine, I contacted you regards to the total sum of(3 million USD) which I signed and donated in your custody as the beneficiary,I was diagnosed with the cancer of the esophagus it has defied all forms of medical treatment and at this point i have few weeks to live

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

On Sun, May 6, 2018 at 8:37 PM, Junio C Hamano wrote: > "brian m. carlson" writes: > >> The order of addresses in the mailmap file was reversed, leading to git >> preferring the crustytoothpaste.ath.cx address, which is obsolete, over >> the

Re: Weak option parsing in `git submodule`

On Sun, May 6, 2018 at 11:10 AM, Kaartic Sivaraam wrote: > I recently faced the consequence of the weak option parsing done by in > `git submodule`. Initially tried to add a new submodule using the `git > submodule add` sub-command in the following way, > > $ git

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

+cc Michael, who did extensive work in the refs.c code. On Sun, May 6, 2018 at 7:10 AM, Martin Ågren wrote: > If we could not take the lock, we add an error to the `strbuf err` and > return. However, this code is dead. The reason is that we take the lock > using

Re: [PATCH v2 00/18] Add `branch-diff`, a `tbdiff` lookalike

On Mon, May 7, 2018 at 10:50 AM, SZEDER Gábor wrote: >> 2) Your completion commands for branch-diff will only complete one >> revision range, not two. e.g. >> git branch-diff origin/master..my-topic@{2} origin/master..my-top >> won't complete "my-topic" as I'd expect. >

Re: [GSoC] Yet another blog series about the GSoC

Hi Pratik, On Sat, May 5, 2018 at 5:24 AM, Pratik Karki wrote: > On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote: >> Hi everybody, >> >> as my fellow students, I started a blog series about my GSoC project[1]. >> First, I wanted to post them

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

On May 6, 2018 9:56:31 AM MDT, "Martin Ågren" wrote: >On 6 May 2018 at 17:48, David Turner wrote: >> On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote: >>> While at it, make the lock non-static. > >> Re making the lock static, I wonder about the

Re: main url for linking to git source?

Hi Jeff, On Sun, May 6, 2018 at 11:37 PM, Jeff King wrote: > The git-scm.com site currently links to https://github.com/git/git for > the (non-tarball) source code. Somebody raised the question[1] of > whether it should point to kernel.org instead. Do people find one > interface

[PATCH v6 03/13] help: use command-list.h for common command list

The previous commit added code generation for all_cmd_desc[] which includes almost everything we need to generate common command list. Convert help code to use that array instead and drop common_cmds[] array. The description of each common command group is removed from command-list.txt. This

[PATCH v6 08/13] git: support --list-cmds=list-

This allows us to select any group of commands by a category defined in command-list.txt. This is an internal/hidden option so we don't have to be picky about the category name or worried about exposing too much. This will be used later by git-completion.bash to retrieve certain command groups.

[PATCH v6 11/13] command-list.txt: documentation and guide line

This is intended to help anybody who needs to update command-list.txt. It gives a brief introduction of all attributes a command can take. --- command-list.txt | 44 1 file changed, 44 insertions(+) diff --git a/command-list.txt b/command-list.txt

[PATCH v6 10/13] help: use command-list.txt for the source of guides

The help command currently hard codes the list of guides and their summary in C. Let's move this list to command-list.txt. This lets us extract summary lines from Documentation/git*.txt. This also potentially lets us list guides in git.txt, but I'll leave that for now. ---

[PATCH v6 13/13] completion: allow to customize the completable command list

By default we show porcelain, external commands and a couple others that are also popular. If you are not happy with this list, you can now customize it. See the big comment block for details. PS. perhaps I should make aliases a group too, which makes it possible to _not_ complete aliases by

[PATCH v6 12/13] completion: let git provide the completable command list

Instead of maintaining a separate list of command classification, which often could go out of date, let's centralize the information back in git. While the function in git-completion.bash implies "list porcelain commands", that's not exactly what it does. It gets all commands (aka

[PATCH v6 02/13] generate-cmds.sh: export all commands to command-list.h

The current generate-cmds.sh generates just enough to print "git help" output. That is, it only extracts help text for common commands. The script is now updated to extract help text for all commands and keep command classification a new file, command-list.h. This will be useful later: - "git

[PATCH v6 04/13] Remove common-cmds.h

After the last patch, common-cmds.h is no longer used (and it was actually broken). Remove all related code. command-list.h will take its place from now on. --- .gitignore | 1 - Makefile| 17 ++--- generate-cmdlist.sh | 46

[PATCH v6 07/13] completion: implement and use --list-cmds=main,others

Instead of parsing "git help -a" output, which is tricky to get right, less elegant and also slow, make git provide the list in a machine-friendly form. This adds two separate listing types, main and others, instead of just "all" for more flexibility. --- contrib/completion/git-completion.bash |

[PATCH v6 05/13] git.c: convert --list-* to --list-cmds=*

Even if these are hidden options, let's make them a bit more generic since we're introducing more listing types shortly. The code is structured to allow combining multiple listing types together because we will soon add more types the 'builtins'. 'parseopt' remains separate because it has

[PATCH v6 06/13] git --list-cmds: collect command list in a string_list

Instead of printing the command directly one by one, keep them in a list and print at the end. This allows more modification before we print out (e.g. sorting, removing duplicates or even excluding some items). --- git.c | 22 +- 1 file changed, 17 insertions(+), 5

[PATCH v6 09/13] help: add "-a --verbose" to list all commands with synopsis

This lists all recognized commands [1] by category. The group order follows closely git.txt. [1] We may actually show commands that are not built (e.g. if you set NO_PERL you don't have git-instaweb but it's still listed here). I ignore the problem because on Linux a git package could be split

[PATCH v6 00/13] Keep all info in command-list.txt in git binary

v6 is now "feature complete". v6 adds - documentation in command-list.txt so people know how to update it - support for config key completion.commands, which consists of extra commands. It could also be used for excluding some commands. Interdiff diff --git a/command-list.txt

[PATCH v6 01/13] generate-cmds.sh: factor out synopsis extract code

This makes it easier to reuse the same code in another place (very soon). --- generate-cmdlist.sh | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh index eeea4b67ea..31b6d886cb 100755 --- a/generate-cmdlist.sh +++

Re: [PATCH v2 00/18] Add `branch-diff`, a `tbdiff` lookalike

> 2) Your completion commands for branch-diff will only complete one > revision range, not two. e.g. > git branch-diff origin/master..my-topic@{2} origin/master..my-top > won't complete "my-topic" as I'd expect. It does complete two revision ranges, but if you want to look at reflogs, then

Re: [PATCH v2 00/18] Add `branch-diff`, a `tbdiff` lookalike

Hi Dscho, On Sat, May 5, 2018 at 1:03 PM, Johannes Schindelin wrote: > Hi Elijah, > > On Fri, 4 May 2018, Elijah Newren wrote: > >> - tbdiff aligned output columns better when there were more than 9 >> patches (I'll comment more on patch 09/18) > > I added a new

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

Hello, On 06.05.2018 16:22, Kaartic Sivaraam wrote: The blog looks pretty well written. I also read your proposal. It also seems to be pretty much well written. I like the way you explain things. Particularly, you seem to be explaining the problem and the way you're about to approach it well.

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

Hi, On Mon, May 7, 2018 at 8:20 AM, Derrick Stolee wrote: > On 5/7/2018 10:58 AM, Junio C Hamano wrote: >> Will merge to 'master'. > > These have been queued for master for a few weeks. Is anything delaying > them? I'm actually curious what the "Will merge to 'master'" and

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

Hi Junio, On Mon, May 7, 2018 at 7:58 AM, Junio C Hamano wrote: > * en/rename-directory-detection-reboot (2018-04-25) 36 commits > - merge-recursive: fix check for skipability of working tree updates > - merge-recursive: make "Auto-merging" comment show for other merges > -

[PATCH] fixup! merge-recursive: add get_directory_renames()

--- merge-recursive.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index 5f42c677d5..9b9a4b8213 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1851,7 +1851,7 @@ static struct hashmap *get_directory_renames(struct

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 wrote: > On 6 May 2018 at 19:42, Duy Nguyen wrote: >> On Sun, May 6, 2018 at 7:26 PM, Duy Nguyen wrote: >>> On Sun, May 6, 2018 at 4:10 PM, Martin Ågren wrote:

Re: Is support for 10.8 dropped?

Hi guys, I am going to try and build the OpenSSL and Git locally. Search brought me here: https://wiki.openssl.org/index.php/Compilation_and_Installation#OS_X. Which options do I absolutely have to have for configuring OpenSSL? Should I exclude "no--ssl2"? "no-ssl3"? Thank you. On Mon, Apr 23,

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

On 5/7/2018 10:58 AM, Junio C Hamano wrote: * ds/generation-numbers (2018-05-02) 11 commits - commit-graph.txt: update design document - merge: check config before loading commits - commit: use generation number in remove_redundant() - commit: add short-circuit to paint_down_to_common()

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

Jeff King writes: > On Tue, Apr 17, 2018 at 12:12:12AM +, brian m. carlson wrote: > >> > That argues more strongly that we would regret unless we make the >> > end-user configuration to at least the whole string (which later can >> > be promoted to "a pattern that matches the

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

Johannes Schindelin writes: > It would be easy to introduce, but I am wary about its usefulness. > Unless you re-generate the branch from patches (which I guess you do a > lot, but I don't), you are likely to compare incomplete patch series: say, > when you call `git

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

I haven't seen any discussion about this recently. What are the chances of getting it merged? I'd like to see this included in 2.18. >> To get the names of all '$__git_builtin_*' variables caching --options >> of builtin commands in order to unset them, 8b0eaa41f2 (completion: >> clear cached

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

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. You can find the changes

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

On 5/4/2018 3:40 PM, Jakub Narebski wrote: Hello, With early parts of commit-graph feature (ds/commit-graph and ds/lazy-load-trees) close to being merged into "master", see https://public-inbox.org/git/xmqq4ljtz87g@gitster-ct.c.googlers.com/ I think it would be good idea to think what other

Re: [PATCH] tests: introduce test_unset_prereq, for debugging

SZEDER Gábor writes: >> For convenience, the following two methods are now supported ways to >> pretend that a prereq is not met: >> >> test_set_prereq !GPG >> >> and >> >> test_unset_prereq GPG > > I'm not sure this is the right way to do this. > > I wanted to

  1   2   >