[PATCH v2 5/5] builtin/config: introduce `color` type specifier

As of this commit, the canonical way to retreive an ANSI-compatible color escape sequence from a configuration file is with the `--get-color` action. This is to allow Git to "fall back" on a default value for the color should the given section not exist in the specified configuration(s). With

[PATCH v2 0/5] builtin/config.c: combined series '--type', '--default'

Hi, Here is an amended version of my combined series to add '--type' and '--default'. My apologies for the re-roll, I thought that I had looked everything over closely enough :-). Since last time: * Correct an obviously-wrong assignment into '*to_type' [1]. I have moved both of these

[PATCH v2 2/5] builtin/config.c: support `--type=` as preferred alias for `--`

`git config` has long allowed the ability for callers to provide a 'type specifier', which instructs `git config` to (1) ensure that incoming values can be interpreted as that type, and (2) that outgoing values are canonicalized under that type. In another series, we propose to extend this

[PATCH v2 4/5] config.c: introduce 'git_config_color' to parse ANSI colors

In preparation for adding `--type=color` to the `git-config(1)` builtin, let's introduce a color parsing utility, `git_config_color` in a similar fashion to `git_config_`. Signed-off-by: Taylor Blau --- config.c | 10 ++ config.h | 1 + 2 files changed, 11

[PATCH v2 1/5] builtin/config.c: treat type specifiers singularly

Internally, we represent `git config`'s type specifiers as a bitset using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique allows for the representation of multiple type specifiers in the `int types` field, but this multi-representation is left unused. In fact, `git config` will

[PATCH v2 3/5] builtin/config: introduce `--default`

For some use cases, callers of the `git-config(1)` builtin would like to fallback to default values when the variable asked for does not exist. In addition, users would like to use existing type specifiers to ensure that values are parsed correctly when they do exist in the configuration. For

Re: [PATCH 5/5] builtin/config: introduce `color` type specifier

Taylor Blau writes: > diff --git a/builtin/config.c b/builtin/config.c > index d7acf912cd..ec5c11293b 100644 > --- a/builtin/config.c > +++ b/builtin/config.c > @@ -61,6 +61,7 @@ static int show_origin; > #define TYPE_BOOL_OR_INT 3 > #define TYPE_PATH4 >

Re: [PATCH 2/5] builtin/config.c: support `--type=` as preferred alias for `--type`

Taylor Blau writes: > Subject: Re: [PATCH 2/5] builtin/config.c: support `--type=` as > preferred alias for `--type` I'd retitle while queuing, as the last 'type' is a placeholder for concrete types like above. > +static int option_parse_type(const struct option *opt,

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

Elijah Newren writes: > On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamano wrote: > >> * en/unpack-trees-split-index-fix (2018-04-24) 1 commit >> * en/rename-directory-detection-reboot (2018-04-25) 36 commits > ... > Would you still like a re-roll? Not really.

[PATCH 0/5] builtin/config.c: combined series '--type', '--default'

Hi, Attached is a combination of my two series to add [--type=] and [--default=] to 'git-config(1)'. I have not changed anything in these patches since their last review in [1], [2], other than to: * Ensure that they merge cleanly into 'master' and, * Incorporate the patch that I sent to

[PATCH 4/5] config.c: introduce 'git_config_color' to parse ANSI colors

In preparation for adding `--type=color` to the `git-config(1)` builtin, let's introduce a color parsing utility, `git_config_color` in a similar fashion to `git_config_`. Signed-off-by: Taylor Blau --- config.c | 10 ++ config.h | 1 + 2 files changed, 11

[PATCH 5/5] builtin/config: introduce `color` type specifier

As of this commit, the canonical way to retreive an ANSI-compatible color escape sequence from a configuration file is with the `--get-color` action. This is to allow Git to "fall back" on a default value for the color should the given section not exist in the specified configuration(s). With

[PATCH 3/5] builtin/config: introduce `--default`

For some use cases, callers of the `git-config(1)` builtin would like to fallback to default values when the variable asked for does not exist. In addition, users would like to use existing type specifiers to ensure that values are parsed correctly when they do exist in the configuration. For

[PATCH 1/5] builtin/config.c: treat type specifiers singularly

Internally, we represent `git config`'s type specifiers as a bitset using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique allows for the representation of multiple type specifiers in the `int types` field, but this multi-representation is left unused. In fact, `git config` will

[PATCH 2/5] builtin/config.c: support `--type=` as preferred alias for `--type`

`git config` has long allowed the ability for callers to provide a 'type specifier', which instructs `git config` to (1) ensure that incoming values can be interpreted as that type, and (2) that outgoing values are canonicalized under that type. In another series, we propose to extend this

Re: [PATCH v5 00/11] Deprecate .git/info/grafts

Johannes Schindelin writes: > -if (export_object(_oid, type, raw, tmpfile)) > -return -1; > -if (launch_editor(tmpfile, NULL, NULL) < 0) > -return error("editing object file failed"); > -if (import_object(_oid, type, raw,

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

Johannes Schindelin writes: > Changes since v8: > > - Disentangled the patch introducing `label`/`reset` from the one > introducing `merge` again (this was one stupid, tired `git commit > --amend` too many). > > - Augmented the commit message of "introduce the

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Derrick Stolee writes: > Define compare_commits_by_gen_then_commit_date(), which uses generation > numbers as a primary comparison and commit date to break ties (or as a > comparison when both commits do not have computed generation numbers). > > Since the commit-graph

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

Derrick Stolee writes: > @@ -439,6 +439,9 @@ static void write_graph_chunk_data(struct hashfile *f, > int hash_len, > else > packedDate[0] = 0; > > + if ((*list)->generation != GENERATION_NUMBER_INFINITY) > +

Re: [PATCH 01/11] t9902-completion: add tests demonstrating issues with quoted pathnames

SZEDER Gábor writes: > These new tests, however, are primarily interested in the inner > workings of __git_complete_index_file() in the presence of escapes > and/or quotes in the path to be completed and/or in the output of 'git > ls-files'. For these kind of tests we

Re: [PATCH v3] Make running git under other debugger-like programs easy

Johannes Schindelin writes: >> ... >> >> There is also a handy shortcut of GIT_DEBUGGER=1 meaning the same as >> GIT_DEBUGGER="gdb --args" >> >> Original-patch-by: Johannes Schindelin >> Signed-off-by: Elijah Newren >

Re: [PATCH v2 0/2] add additional config settings for merge

Ben Peart writes: > To be clear, this documentation change isn't trying to document any > changes to the code or behavior - it is just an attempt to clarify > what the existing behavior is. Yeah, I know, and I do think the new text is a good first step in the right

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

Marc Branchaud writes: >> But Git is not an archiver (tar), but is a source code control >> system, so I do not think we should spend any extra cycles to >> "improve" its behaviour wrt the relative ordering, at least for the >> default case. Only those who rely on having

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

On Wed, Apr 25, 2018 at 05:37:52PM +0900, Junio C Hamano wrote: > * bc/object-id (2018-04-24) 41 commits > - merge-one-file: compute empty blob object ID > - add--interactive: compute the empty tree value > - Update shell scripts to compute empty tree object ID > - sha1_file: only expose empty

Re: [PATCH 01/11] t9902-completion: add tests demonstrating issues with quoted pathnames

On Wed, Apr 18, 2018 at 3:22 AM, Junio C Hamano wrote: > SZEDER Gábor writes: >>> Do we want to test a more common case of a filename that is two >>> words with SP in between, i.e. >>> >>> $ >'hello world' && git add hel >>> >>> or is it known to

Re: [PATCHv3 0/9] object store: oid_object_info is the next contender

On Wed, 25 Apr 2018 11:20:57 -0700 Stefan Beller wrote: > v3: > * fixed and extended the commit message of last commit > * fixed the last patch, as Jonathan Tan suggested, see interdiff: Thanks, all my comments have been addressed. Reviewed-by: Jonathan Tan

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

On Wed, Apr 25, 2018 at 11:18:26AM -0400, 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 thing, and we

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 11:21 schrieb Phillip Wood: On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly in the

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 09:41 schrieb Johannes Schindelin: Hi Hannes, On Wed, 25 Apr 2018, Johannes Sixt wrote: Am 25.04.2018 um 02:05 schrieb Junio C Hamano: Johannes Sixt writes: It is not uncommon to request that the output remains visible in the terminal. I ran `git log` and

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

On 25 April 2018 at 01:51, brian m. carlson wrote: > On Tue, Apr 24, 2018 at 11:50:16AM +0200, Martin Ågren wrote: >> On 24 April 2018 at 01:39, brian m. carlson >> wrote: >> > The code for reading certain pack v2 offsets had a

Re: [PATCH v4/wip 06/12] git: accept multiple --list-cmds options

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > Later on we may support non-overlapping command groups to > --list-cmds. Allow the user to execute just one "git" process and get > multiple groups. This may matter for git-completion.bash on Windows > because we

[PATCHv3 7/9] packfile: add repository argument to unpack_entry

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

[PATCHv3 8/9] packfile: add repository argument to cache_or_unpack_entry

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

[PATCHv3 4/9] packfile: add repository argument to packed_to_object_type

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

[PATCHv3 5/9] packfile: add repository argument to packed_object_info

From: Jonathan Nieder Add a repository argument to allow callers of packed_object_info to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with

Re: [PATCH v4/wip 10/12] help: use command-list.txt for the source of guides

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > 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

[PATCHv3 2/9] cache.h: add repository argument to oid_object_info

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

[PATCHv3 9/9] cache.h: allow oid_object_info to handle arbitrary repositories

This involves also adapting oid_object_info_extended and a some internal functions that are used to implement these. It all has to happen in one patch, because of a single recursive chain of calls visits all these functions. oid_object_info_extended is also used in partial clones, which allow

[PATCHv3 6/9] packfile: add repository argument to read_object

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

[PATCHv3 3/9] packfile: add repository argument to retry_bad_packed_offset

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

[PATCHv3 0/9] object store: oid_object_info is the next contender

v3: * fixed and extended the commit message of last commit * fixed the last patch, as Jonathan Tan suggested, see interdiff: $ git diff remotes/origin/sb/oid-object-info (which is v2) diff --git c/sha1_file.c w/sha1_file.c index 94123e0299..dcd6b879ac 100644 --- c/sha1_file.c

[PATCHv3 1/9] cache.h: add repository argument to oid_object_info_extended

Add a repository argument to allow oid_object_info_extended callers 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: Stefan Beller

Re: [PATCH v4/wip 08/12] git: support --list-cmds=

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > 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 >

Re: [PATCH v4/wip 01/12] generate-cmds.sh: factor out synopsis extract code

On Wed, Apr 25, 2018 at 7:59 PM Eric Sunshine wrote: > On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy > wrote: > > This makes it easier to reuse the same code in another place (very > > soon). > > > > Signed-off-by: Nguyễn Thái Ngọc Duy

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

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 commands. > > The script is now updated to extract help text for all commands and >

Re: [PATCH v4/wip 01/12] generate-cmds.sh: factor out synopsis extract code

On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy wrote: > This makes it easier to reuse the same code in another place (very > soon). > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh > @@ -1,5 +1,17

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

On 04/25, Ævar Arnfjörð Bjarmason wrote: > > * bw/protocol-v2 (2018-03-15) 35 commits > > (merged to 'next' on 2018-04-11 at 23ee234a2c) > > + remote-curl: don't request v2 when pushing > > + remote-curl: implement stateless-connect command > > + http: eliminate "# service" line when using

Re: git https and github

On 25.04.18 02:32, Lev wrote: > Hi list, > > > I'm struggling with git connecting to Github. > > The problem might be SSL/TLS related. > > https://githubengineering.com/crypto-removal-notice/ > > I suspect that my setup still uses tlsv1 or tlsv1.1. > > I've tried to explicitly set git to use

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

On 25/04/18 13:48, Johannes Schindelin wrote: Hi Phillip, On Mon, 23 Apr 2018, Phillip Wood wrote: On 23/04/18 19:11, Stefan Beller wrote: On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin wrote: Eric Sunshine pointed out that I had such a commit message in

[PATCH v4/wip 05/12] git.c: convert --list-*builtins 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. Signed-off-by: Nguyễn Thái Ngọc Duy --- contrib/completion/git-completion.bash | 2 +- git.c | 12 +++-

[PATCH v4/wip 09/12] 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 v4/wip 11/12] command-list.txt: add new category "complete"

This category, combined with 'external' and 'mainporcelain', is intended to replace the "porcelain command list" in git-completion.bash. In other words, these are the commands that will show up by default when you type "git ". Compared to the current list in git-completion.bash (which is

[PATCH v4/wip 10/12] 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 lists guides in git.txt, but I'll leave that for now. Signed-off-by: Nguyễn Thái

[PATCH v4/wip 04/12] 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. Signed-off-by: Nguyễn Thái Ngọc Duy --- .gitignore | 1 - Makefile| 17 ++---

[PATCH v4/wip 12/12] 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. Note that the current completion script incorrectly classifies filter-branch as porcelain and t9902 tests this behavior. We keep it this way in t9902

[PATCH v4/wip 06/12] git: accept multiple --list-cmds options

Later on we may support non-overlapping command groups to --list-cmds. Allow the user to execute just one "git" process and get multiple groups. This may matter for git-completion.bash on Windows because we don't want the user to way for long when TAB-ing and Windows is slow on launching new

[PATCH v4/wip 02/12] 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 v4/wip 08/12] git: support --list-cmds=

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 v4/wip 07/12] completion: implement and use --list-cmds=all

Instead of parsing "git help -a" output, which is tricky to get right, less elegant and also slow, make git provide the list in machine-friendly form. Signed-off-by: Nguyễn Thái Ngọc Duy --- contrib/completion/git-completion.bash | 2 +- git.c

[PATCH v4/wip 03/12] 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 v4/wip 01/12] generate-cmds.sh: factor out synopsis extract code

This makes it easier to reuse the same code in another place (very soon). Signed-off-by: Nguyễn Thái Ngọc Duy --- generate-cmdlist.sh | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh index

[PATCH v4/wip 00/12] Keep all info in command-list.txt in git binary

This is not exactly v4 and likely broken. But I've made several debatable changes and would like your opinions before making even more changes in this direction. In 03/12 I made a format change in command-list.txt. The group description is no longer in this file but in help.c instead. This

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

Hi Junio, On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamano wrote: > * en/unpack-trees-split-index-fix (2018-04-24) 1 commit > - unpack_trees: fix breakage when o->src_index != o->dst_index > > The split-index feature had a long-standing and dormant bug in > certain use of

[PATCH v2] perf/aggregate: use Getopt::Long for option parsing

When passing an option '--foo' that it does not recognize, the aggregate.perl script should die with an helpful error message like: Unknown option: foo ./aggregate.perl [options] [--] [...] [--] \ [...] > Options: --codespeed * Format output for Codespeed --reponame *

Re: [PATCH v2 1/2] merge: Add merge.renames config setting

On Tue, Apr 24, 2018 at 1:31 PM, Ben Peart wrote: > On 4/24/2018 2:59 PM, Elijah Newren wrote: >> On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart >> wrote: >>> >>> diff --git a/builtin/merge.c b/builtin/merge.c >>> index 8746c5e3e8..3be52cd316 100644 >>>

Re: [PATCH v2 0/2] add additional config settings for merge

On 4/24/2018 8:13 PM, Junio C Hamano wrote: Ben Peart writes: diff.renameLimit:: The number of files to consider when performing the copy/rename - detection; equivalent to the 'git diff' option `-l`. + detection; equivalent to the 'git diff'

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

On 2018-04-25 04:48 AM, Junio C Hamano wrote: "Robin H. Johnson" writes: In the thread from 6 years ago, you asked about tar's behavior for mtimes. 'tar xf' restores mtimes from the tar archive, so relative ordering after restore would be the same, and would only rebuild

Re: GSoC students and mentors in 2018

On Tue, Apr 24, 2018 at 2:46 AM, Stefan Beller wrote: > Hi Git community, > > This year we'll participate once again in Google Summer or Code! > We'll have 3 students and 3 mentors, which is more than in recent years. > > Paul-Sebastian Ungureanu mentored by DScho, wants to

Re: java diffs show no method context

Le 25/04/2018 à 14:53, Ulrich Windl a écrit : > Hi! > > This is for git 2.13.6, and it may be an FAQ or frequent feature request. > Anyway: > I'm new to Java, and writing my first project using Git, I found that "git > diff" only reports the class in the diff context, but not the method (as

Re: GSoC students and mentors in 2018

Le 23/04/2018 à 23:01, Stefan Beller a écrit : > Hi Git community, > > This year we'll participate once again in Google Summer or Code! > We'll have 3 students and 3 mentors, which is more than in recent years. > > Paul-Sebastian Ungureanu mentored by DScho, wants to convert git-stash > into a

Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

On 4/24/2018 7:57 PM, Junio C Hamano wrote: Ben Peart writes: That said, it makes sense to me to do this when rename detection is turned off. In fact, I think you'd automatically want to set aggressive to true whenever rename detection is turned off (whether by your

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

On Wed, Apr 25, 2018 at 3:46 PM, SZEDER Gábor wrote: > On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen wrote: >> On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote: >>> git-completion.bash will be updated to ask git "give me the commands

Re: [PATCH v2 1/1] completion: load completion file for external subcommand

On Mon, Apr 23, 2018 at 5:12 PM, SZEDER Gábor wrote: > On Thu, Apr 19, 2018 at 9:07 PM, Florian Gamböck wrote: >> On 2018-04-18 21:51, SZEDER Gábor wrote: >>> I believe the main bash-completion repository can be found at: >>> >>>

Re: [PATCH v4 00/10] Compute and consume generation numbers

As promised, here is the diff from v3. Thanks, -Stolee -- >8 -- diff --git a/builtin/merge.c b/builtin/merge.c index 7e1da6c6ea..b819756946 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -1148,6 +1148,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)     branch =

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 >

[PATCH v4 09/10] merge: check config before loading commits

Now that we use generation numbers from the commit-graph, we must ensure that all commits that exist in the commit-graph are loaded from that file instead of from the object database. Since the commit-graph file is only checked if core.commitGraph is true, we must check the default config before

[PATCH v4 10/10] commit-graph.txt: update design document

We now calculate generation numbers in the commit-graph file and use them in paint_down_to_common(). Expand the section on generation numbers to discuss how the three special generation numbers GENERATION_NUMBER_INFINITY, _ZERO, and _MAX interact with other generation numbers. Signed-off-by:

[PATCH v4 04/10] commit: use generations in paint_down_to_common()

Define compare_commits_by_gen_then_commit_date(), which uses generation numbers as a primary comparison and commit date to break ties (or as a comparison when both commits do not have computed generation numbers). Since the commit-graph file is closed under reachability, we know that all commits

[PATCH v4 07/10] commit: use generation numbers for in_merge_bases()

The containment algorithm for 'git branch --contains' is different from that for 'git tag --contains' in that it uses is_descendant_of() instead of contains_tag_algo(). The expensive portion of the branch algorithm is computing merge bases. When a commit-graph file exists with generation numbers

[PATCH v4 05/10] commit-graph: always load commit-graph information

Most code paths load commits using lookup_commit() and then parse_commit(). In some cases, including some branch lookups, the commit is parsed using parse_object_buffer() which side-steps parse_commit() in favor of parse_commit_buffer(). With generation numbers in the commit-graph, we need to

[PATCH v4 08/10] commit: add short-circuit to paint_down_to_common()

When running 'git branch --contains', the in_merge_bases_many() method calls paint_down_to_common() to discover if a specific commit is reachable from a set of branches. Commits with lower generation number are not needed to correctly answer the containment query of in_merge_bases_many(). Add a

[PATCH v4 06/10] ref-filter: use generation number for --contains

A commit A can reach a commit B only if the generation number of A is strictly larger than the generation number of B. This condition allows significantly short-circuiting commit-graph walks. Use generation number for '--contains' type queries. On a copy of the Linux repository where HEAD is

[PATCH v4 02/10] commit: add generation number to struct commmit

The generation number of a commit is defined recursively as follows: * If a commit A has no parents, then the generation number of A is one. * If a commit A has parents, then the generation number of A is one more than the maximum generation number among the parents of A. Add a uint32_t

[PATCH v4 00/10] Compute and consume generation numbers

Thanks for the feedback on the previous version. I think this series is stabilizing nicely. I'll reply to this message with an inter-diff as it is not too large to share but would clutter this cover letter. Thanks, -Stolee -- >8 -- This is the one of several "small" patches that follow the

[PATCH v4 03/10] commit-graph: compute generation numbers

While preparing commits to be written into a commit-graph file, compute the generation numbers using a depth-first strategy. The only commits that are walked in this depth-first search are those without a precomputed generation number. Thus, computation time will be relative to the number of new

[PATCH v4 01/10] ref-filter: fix outdated comment on in_commit_list

The in_commit_list() method does not check the parents of the candidate for containment in the list. Fix the comment that incorrectly states that it does. Reported-by: Jakub Narebski Signed-off-by: Derrick Stolee --- ref-filter.c | 2 +- 1 file changed,

Re: [PATCH v3 5/9] ref-filter: use generation number for --contains

On 4/24/2018 2:56 PM, Jakub Narebski wrote: Derrick Stolee writes: One way to fix this is to call 'prepare_commit_graph()' directly and then test that 'commit_graph' is non-null before performing any parses. I'm not thrilled with how that couples the commit-graph

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

On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen wrote: > On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote: >> git-completion.bash will be updated to ask git "give me the commands >> in the mainporcelain, completable or external category". This also >> addresses

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

On Sat, Apr 21, 2018 at 6:54 PM, Nguyễn Thái Ngọc Duy wrote: > diff --git a/contrib/completion/git-completion.bash > b/contrib/completion/git-completion.bash > index a5f13ade20..7d17ca23f6 100644 > --- a/contrib/completion/git-completion.bash > +++

java diffs show no method context

Hi! This is for git 2.13.6, and it may be an FAQ or frequent feature request. Anyway: I'm new to Java, and writing my first project using Git, I found that "git diff" only reports the class in the diff context, but not the method (as seen for C, for example). I'd wish to have the method where

Re: [PATCH v1] perf/aggregate: tighten option parsing

On Sat, Apr 21, 2018 at 5:50 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >>> Not necessarily worth a re-roll. >> >> Not that it matters in this case, but just as a bit of Perl rx pedantry, >> yes his is tighter & more correct. You didn't

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

Hi Phillip, On Mon, 23 Apr 2018, Phillip Wood wrote: > On 23/04/18 19:11, Stefan Beller wrote: > > > > On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin > > wrote: > > > Eric Sunshine pointed out that I had such a commit message in > > >

js/rebase-recreate-merge, was Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

Hi Junio, On Wed, 25 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-04-24) 16 commits > - rebase -i --rebase-merges: add a section to the man page > - rebase -i: introduce --rebase-merges=[no-]rebase-cousins > - pull: accept --rebase=merges to recreate the branch topology

`iconv` should have the encoding `ISO646-SE2`

I installed from `Git-2.16.2-64-bit.exe` from git-scm.com. `iconv` is included in this package. I think `iconv` should have the encoding `ISO646-SE2`. Ubuntu 16.04 has this encoding. I use it to read old Swedish text files, which there are a lot of e.g.: `curl -s

[PATCH v9 14/17] rebase --rebase-merges: avoid "empty merges"

The `git merge` command does not allow merging commits that are already reachable from HEAD: `git merge HEAD^`, for example, will report that we are already up to date and not change a thing. In an interactive rebase, such a merge could occur previously, e.g. when competing (or slightly modified)

[PATCH v9 17/17] rebase -i --rebase-merges: add a section to the man page

The --rebase-merges mode is probably not half as intuitive to use as its inventor hopes, so let's document it some. Signed-off-by: Johannes Schindelin --- Documentation/git-rebase.txt | 135 +++ 1 file changed, 135 insertions(+) diff

[PATCH v9 16/17] rebase -i: introduce --rebase-merges=[no-]rebase-cousins

When running `git rebase --rebase-merges` non-interactively with an ancestor of HEAD as (or leaving the todo list unmodified), we would ideally recreate the exact same commits as before the rebase. However, if there are commits in the commit range .. that do not have as direct ancestor (i.e. if

[PATCH v9 15/17] pull: accept --rebase=merges to recreate the branch topology

Similar to the `preserve` mode simply passing the `--preserve-merges` option to the `rebase` command, the `merges` mode simply passes the `--rebase-merges` option. This will allow users to conveniently rebase non-trivial commit topologies when pulling new commits, without flattening them.

[PATCH v9 13/17] sequencer: handle post-rewrite for merge commands

In the previous patches, we implemented the basic functionality of the `git rebase -i --rebase-merges` command, in particular the `merge` command to create merge commits in the sequencer. The interactive rebase is a lot more these days, though, than a simple cherry-pick in a loop. For example, it

[PATCH v9 12/17] sequencer: make refs generated by the `label` command worktree-local

This allows for rebases to be run in parallel in separate worktrees (think: interrupted in the middle of one rebase, being asked to perform a different rebase, adding a separate worktree just for that job). Signed-off-by: Johannes Schindelin --- refs.c

  1   2   >