Re: Windows > git.exe > the result of "git branch" does not always highlight the current branch

Am 09.04.2018 um 21:26 schrieb Hari Lubovac: It appears to be just a reporting issue. Probably not a big deal, but I thought I should report this, if it hasn't been noticed: when a branch is switched to by being named with non-original character-casing, then it's not clear which branch is

Re: [PATCH v7 1/2] builtin/config.c: treat type specifiers singularly

On Mon, Apr 9, 2018 at 10:12 PM, Taylor Blau wrote: > On Tue, Apr 10, 2018 at 10:22:25AM +0900, Junio C Hamano wrote: >> I suspect that it may be OK to switch to last-one-wins, but then we >> should give a justification that is a bit stronger than "we want to >> avoid

Re: [PATCH 06/16] replace-object: check_replace_refs is safe in multi repo environment

Stefan Beller writes: > In ecef23 (inline lookup_replace_object() calls, 2011-05-15) a > shortcut for checking the object replacement was added by setting > check_replace_refs to 0 once the replacements were evaluated to > not exist. This works fine in with the assumption

Re: [PATCH 05/16] replace-object: eliminate replace objects prepared flag

Stefan Beller writes: > By making the oidmap a pointer, we eliminate the need for > the global boolean variable 'replace_object_prepared'. That is not quite a justification for this change, as making it a pointer (and paying for the malloc(3) overhead) is not the only way to

Re: [PATCH 03/16] replace-object: move replace_map to object store

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > object-store.h | 8 > replace-object.c | 17 +++-- > replace-object.h | 9 + > 3 files changed, 24 insertions(+), 10 deletions(-) > create mode 100644

Re: [PATCH 02/16] replace_object.c: rename to use dash in file name

Stefan Beller writes: > This is more consistent with the project style. The majority of > Git's source files use dashes in preference to underscores in their file > names. > > Noticed while adding a header corresponding to this file. > > Signed-off-by: Jonathan Nieder

Re: [PATCH 01/16] replace_object: use oidmap

Stefan Beller writes: > -static struct replace_object { > - struct object_id original; > +struct replace_object { > + struct oidmap_entry original; > struct object_id replacement; > -} **replace_object; > - > -static int replace_object_alloc, replace_object_nr;

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

On Tue, Apr 10, 2018 at 10:44:18AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > `git config` has long allowed the ability for callers to provide a 'type > > specifier', which instructs `git config` to (1) ensure that incoming > > values are satisfiable under that

Re: [PATCH v7 1/2] builtin/config.c: treat type specifiers singularly

On Tue, Apr 10, 2018 at 10:22:25AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > 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

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

Taylor Blau writes: > diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt > index b644a44ae9..7c8365e377 100644 > --- a/Documentation/git-config.txt > +++ b/Documentation/git-config.txt > @@ -177,6 +177,10 @@ Valid ``'s include: >~/` from the command

Re: [PATCH v6 1/3] builtin/config: introduce `--default`

Taylor Blau writes: > 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

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

Taylor Blau writes: > `git config` has long allowed the ability for callers to provide a 'type > specifier', which instructs `git config` to (1) ensure that incoming > values are satisfiable under that type, and (2) that outgoing values are > canonicalized under that type.

Re: [PATCH v7 1/2] builtin/config.c: treat type specifiers singularly

Taylor Blau writes: > 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

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

[Re-sending, making sure the annoying rich text mode isn't turned on in gmail...] Hi Dscho, On Mon, Apr 9, 2018 at 2:19 PM, Johannes Schindelin wrote: > Hi Elijah, > > On Mon, 9 Apr 2018, Elijah Newren wrote: > >> debug () { >> - GIT_TEST_GDB=1 "$@" <&6 >&5

Re: [PATCH v4 1/3] builtin/config: introduce `--default`

On Mon, Apr 09, 2018 at 08:18:18AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Apr 04, 2018 at 07:59:12PM -0700, Taylor Blau wrote: > > > >> @@ -286,6 +288,16 @@ static int get_value(const char *key_, const char > >> *regex_) > >>

[PATCH v6 1/3] 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 v6 3/3] 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 v6 2/3] 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 v6 3/3] 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 v6 0/3] Teach `--default` to `git-config(1)`

Hi, Attached is the sixth re-roll of my series to add '--type=color' as a valid option to 'git-config(1)'. I have changed the following since v5 (an inter-diff is available below for easier consumption): - Update prose in Documentation/git-config.txt to match Eric's suggestions. -

Re: [PATCHv2 00/16] object-store refactoring 3 (replace objects, main ref store)

On Mon, Apr 9, 2018 at 4:25 PM, Brandon Williams wrote: > On 04/09, Stefan Beller wrote: > > I've looked through the series and it looks good. My only concern is > making sure that the ref-store is in a good place to be embedded into > the repository struct. > Michael knows

Re: [PATCH 12/16] refs: store the main ref store inside the repository struct

On 04/09, Stefan Beller wrote: > Hi Brandon, > > On Mon, Apr 9, 2018 at 4:24 PM, Brandon Williams wrote: > > >> - main_ref_store = ref_store_init(get_git_dir(), REF_STORE_ALL_CAPS); > >> - return main_ref_store; > >> + r->main_ref_store = ref_store_init(r->gitdir,

Re: [PATCH 12/16] refs: store the main ref store inside the repository struct

Hi Brandon, On Mon, Apr 9, 2018 at 4:24 PM, Brandon Williams wrote: >> - main_ref_store = ref_store_init(get_git_dir(), REF_STORE_ALL_CAPS); >> - return main_ref_store; >> + r->main_ref_store = ref_store_init(r->gitdir, REF_STORE_ALL_CAPS); >> + return

Re: [PATCHv2 00/16] object-store refactoring 3 (replace objects, main ref store)

On 04/09, Stefan Beller wrote: I've looked through the series and it looks good. My only concern is making sure that the ref-store is in a good place to be embedded into the repository struct. > v2: > This applies on top of a merge of > origin/bc/object-id and origin/sb/packfiles-in-repository,

Re: [PATCH 12/16] refs: store the main ref store inside the repository struct

On 04/09, Stefan Beller wrote: > Signed-off-by: Stefan Beller > --- > refs.c | 13 + > refs.h | 4 +--- > repository.h | 3 +++ > 3 files changed, 9 insertions(+), 11 deletions(-) > > diff --git a/refs.c b/refs.c > index f58b9fb7df..b5be754a97

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

On Mon, Apr 9, 2018 at 6:46 PM, Taylor Blau wrote: > Attached is the seventh re-roll of my series to support '--type=' > instead of '--' in 'git-config(1)'. > > Since v6, I have changed only the wording in > Documentation/git-config.txt, which Eric and I reached consensus upon

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

Hi, Attached is the seventh re-roll of my series to support '--type=' instead of '--' in 'git-config(1)'. Since v6, I have changed only the wording in Documentation/git-config.txt, which Eric and I reached consensus upon in a sub-thread [1]. Per Eric's suggestion, I have also included an

[PATCH v7 1/2] 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 v7 2/2] 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 are satisfiable under that type, and (2) that outgoing values are canonicalized under that type. In another series, we propose to extend this

[PATCH 10/16] replace-object: add repository argument to do_lookup_replace_object

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

[PATCH 05/16] replace-object: eliminate replace objects prepared flag

By making the oidmap a pointer, we eliminate the need for the global boolean variable 'replace_object_prepared'. Signed-off-by: Stefan Beller --- object-store.h | 2 +- replace-object.c | 16 +--- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git

[PATCH 04/16] object-store: move lookup_replace_object to replace-object.h

lookup_replace_object is a low-level function that most users of the object store do not need to use directly. Move it to replace-object.h to avoid a dependency loop in an upcoming change to its inline definition that will make use of repository.h. Signed-off-by: Stefan Beller

[PATCH 11/16] replace-object: add repository argument to lookup_replace_object

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

[PATCH 16/16] replace-object: allow lookup_replace_object to handle arbitrary repositories

Signed-off-by: Stefan Beller --- replace-object.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/replace-object.h b/replace-object.h index 3520fd7ff7..9f607a929b 100644 --- a/replace-object.h +++ b/replace-object.h @@ -23,14 +23,14 @@ extern

[PATCH 02/16] replace_object.c: rename to use dash in file name

This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Noticed while adding a header corresponding to this file. Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller

[PATCH 12/16] refs: store the main ref store inside the repository struct

Signed-off-by: Stefan Beller --- refs.c | 13 + refs.h | 4 +--- repository.h | 3 +++ 3 files changed, 9 insertions(+), 11 deletions(-) diff --git a/refs.c b/refs.c index f58b9fb7df..b5be754a97 100644 --- a/refs.c +++ b/refs.c @@ -1608,9 +1608,6 @@

[PATCH 06/16] replace-object: check_replace_refs is safe in multi repo environment

In ecef23 (inline lookup_replace_object() calls, 2011-05-15) a shortcut for checking the object replacement was added by setting check_replace_refs to 0 once the replacements were evaluated to not exist. This works fine in with the assumption of only one repository in existence. The

[PATCHv2 00/16] object-store refactoring 3 (replace objects, main ref store)

v2: This applies on top of a merge of origin/bc/object-id and origin/sb/packfiles-in-repository, both of which are pending merge to master. It is also available at https://github.com/stefanbeller/git/tree/object-store-3 * removed whitespaces as noted by Stolee * incorporated Renes patch as the

[PATCH 15/16] replace-object: allow do_lookup_replace_object to handle arbitrary repositories

Signed-off-by: Stefan Beller --- replace-object.c | 7 --- replace-object.h | 4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/replace-object.c b/replace-object.c index eae52c66f3..246b98cd4f 100644 --- a/replace-object.c +++ b/replace-object.c @@

[PATCH 09/16] replace-object: add repository argument to prepare_replace_object

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

[PATCH 07/16] refs: add repository argument to get_main_ref_store

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

[PATCH 14/16] replace-object: allow prepare_replace_object to handle arbitrary repositories

Signed-off-by: Stefan Beller --- replace-object.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/replace-object.c b/replace-object.c index adfed78901..eae52c66f3 100644 --- a/replace-object.c +++ b/replace-object.c @@ -31,18 +31,16 @@ static

[PATCH 08/16] refs: add repository argument to for_each_replace_ref

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

[PATCH 13/16] refs: allow for_each_replace_ref to handle arbitrary repositories

Signed-off-by: Stefan Beller --- refs.c | 4 ++-- refs.h | 4 +--- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/refs.c b/refs.c index b5be754a97..bed5f88405 100644 --- a/refs.c +++ b/refs.c @@ -1415,9 +1415,9 @@ int refs_for_each_fullref_in(struct ref_store

[PATCH 03/16] replace-object: move replace_map to object store

Signed-off-by: Stefan Beller --- object-store.h | 8 replace-object.c | 17 +++-- replace-object.h | 9 + 3 files changed, 24 insertions(+), 10 deletions(-) create mode 100644 replace-object.h diff --git a/object-store.h b/object-store.h

[PATCH 01/16] replace_object: use oidmap

From: René Scharfe Load the replace objects into an oidmap to allow for easy lookups in constant time. Signed-off-by: Rene Scharfe Signed-off-by: Stefan Beller --- replace_object.c | 76 ++-- 1 file

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

Ramsay Jones writes: > On 09/04/18 14:37, Derrick Stolee wrote: >> On 4/9/2018 6:21 AM, Junio C Hamano wrote: >>> * ds/commit-graph (2018-04-02) 16 commits >>>   - commit-graph: implement "--additive" option >>> ... >>>   Ready??? >>>   It seems that this topic is

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

Florian Gamböck writes: > On 2018-04-09 18:36, Junio C Hamano wrote: >> Florian Gamböck writes: >> >> > Good point. I could go even further and ditch the if-construct: >> > >> >! declare -f $completion_func && declare -f __load_completion && >> >

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Mon, Apr 9, 2018 at 3:30 PM, Thomas Gummerer wrote: > On 04/08, Eric Sunshine wrote: >> As with Junio, I'm fine with this hidden option (for now), however, I >> think you can take this a step further. Rather than having a (hidden) >> git-reset option which suppresses

Re: Great Investment Offer

Hello In my search for a business partner i got your contact in google search. My client is willing to invest $10 Million to $500 million but my client said he need a trusted partner who he can have a meeting at the point of releasing his funds. I told my client that you have a good profile

Re: [PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

On Mon, Apr 9, 2018 at 3:44 PM, Thomas Gummerer wrote: > On 04/08, Eric Sunshine wrote: >> This is making me wonder if "Checking out branch" is perhaps the wrong >> terminology. What if it said something like this instead: >> >> $ git worktree add ../next >>

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

Hi, On Mon, 9 Apr 2018, Johannes Schindelin wrote: > On Mon, 9 Apr 2018, Junio C Hamano wrote: > > > * js/rebase-recreate-merge (2018-02-23) 12 commits (merged to 'next' > > on 2018-03-15 at 3d1671756f) + rebase -i: introduce > > --recreate-merges=[no-]rebase-cousins + pull: accept

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

Hi Elijah, On Mon, 9 Apr 2018, Elijah Newren wrote: > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh > index 1701fe2a06..0591d9a7f8 100644 > --- a/t/test-lib-functions.sh > +++ b/t/test-lib-functions.sh > @@ -145,12 +145,28 @@ test_pause () { > "$SHELL_PATH" <&6 >&5 2>&7 >

Re: [PATCH 6/8] gpg-interface: find the last gpg signature line

On Mon, Apr 9, 2018 at 4:41 PM, Ben Toews wrote: > From: Jeff King > > A signed tag has a detached signature like this: > > object ... > [...more header...] > > This is the tag body. > > -BEGIN PGP SIGNATURE- > [opaque gpg data] > -END

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

Hi Ben, On Mon, Apr 9, 2018 at 1:41 PM, Ben Toews wrote: > From: Ben Toews > > Currently you can only sign commits and tags using "gpg". > You can _almost_ plug in a related tool like "gpgsm" (which > uses S/MIME-style signatures instead of PGP) using >

Re: [PATCH 1/8] gpg-interface: handle bool user.signingkey

On Mon, Apr 9, 2018 at 4:41 PM, Ben Toews wrote: > From: Jeff King > > The config handler for user.signingkey does not check for a > boolean value, and thus: > > git -c user.signingkey tag > > will segfault. We could fix this and even shorten the code > by

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

From: Ben Toews Currently you can only sign commits and tags using "gpg". You can _almost_ plug in a related tool like "gpgsm" (which uses S/MIME-style signatures instead of PGP) using gpg.program, as it has command-line compatibility. But there are a few rough edges: 1.

[PATCH 1/8] gpg-interface: handle bool user.signingkey

From: Jeff King The config handler for user.signingkey does not check for a boolean value, and thus: git -c user.signingkey tag will segfault. We could fix this and even shorten the code by using git_config_string(). But our set_signing_key() helper is used by other code

[PATCH 3/8] gpg-interface: use size_t for signature buffer size

From: Jeff King Even though our object sizes (from which these buffers would come) are typically "unsigned long", this is something we'd like to eventually fix (since it's only 32-bits even on 64-bit Windows). It makes more sense to use size_t when taking an in-memory buffer. ---

[PATCH 2/8] gpg-interface: modernize function declarations

From: Jeff King Let's drop "extern" from our declarations, which brings us in line with our modern style guidelines. While we're here, let's wrap some of the overly long lines, and move docstrings for public functions to their declarations, since they document the interface. ---

[PATCH 4/8] gpg-interface: fix const-correctness of "eol" pointer

From: Jeff King We accidentally shed the "const" of our buffer by passing it through memchr. Let's fix that, and while we're at it, move our variable declaration inside the loop, which is the only place that uses it. --- gpg-interface.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH 6/8] gpg-interface: find the last gpg signature line

From: Jeff King A signed tag has a detached signature like this: object ... [...more header...] This is the tag body. -BEGIN PGP SIGNATURE- [opaque gpg data] -END PGP SIGNATURE- Our parser finds the _first_ line that appears to start a PGP signature

[PATCH 7/8] gpg-interface: prepare for parsing arbitrary PEM blocks

From: Jeff King In preparation for handling more PEM blocks besides "PGP SIGNATURE" and "PGP MESSAGE', let's break up the parsing to parameterize the actual block type. --- gpg-interface.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git

[PATCH 0/8] gpg-interface: Multiple signing tools

This series extends the configuration to allow Git to better work with multiple signing tools. Ben Toews (1): gpg-interface: handle alternative signature types Jeff King (7): gpg-interface: handle bool user.signingkey gpg-interface: modernize function declarations gpg-interface: use

[PATCH 5/8] gpg-interface: extract gpg line matching helper

From: Jeff King Let's separate the actual line-by-line parsing of signatures from the notion of "is this a gpg signature line". That will make it easier to do more refactoring of this loop in future patches. --- gpg-interface.c | 9 +++-- 1 file changed, 7 insertions(+), 2

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

Hi Junio, On Mon, 9 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-02-23) 12 commits > (merged to 'next' on 2018-03-15 at 3d1671756f) > + rebase -i: introduce --recreate-merges=[no-]rebase-cousins > + pull: accept --rebase=recreate to recreate the branch topology > +

Re: [PATCH] Fix condition for redirecting stderr

On 09.04.2018 04:23, Todd Zullinger wrote: > Lucas Werkmeister wrote: >> Since the --log-destination option was added in 0c591cacb ("daemon: add >> --log-destination=(stderr|syslog|none)", 2018-02-04) with the explicit >> goal of allowing logging to stderr when running in inetd mode, we should >>

Re: Windows > git.exe > the result of "git branch" does not always highlight the current branch

I don't know which party compiled it. I'm pretty sure I downloaded the installer from https://git-scm.com/downloads, although it might have come shipped with Microsoft Visual Studio, which I use. I forgot this detail earlier: git --version git version 2.16.1.windows.2 I'm a little behind; maybe

Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand

On 2018-04-09 11:26, Stefan Beller wrote: Since bash-completion started to use dynamical loading of completion scripts somewhere around v2.0, it is no longer sufficient to drop a completion script of a subcommand into the standard completions path, /usr/share/bash-completion/completions, since

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote: > On Sun, Apr 8, 2018 at 10:24 AM, Thomas Gummerer wrote: > > On 04/08, Eric Sunshine wrote: > >> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer > >> wrote: > > Let me think through some of the cases here, of 'git

Re: [PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote: > On Sun, Apr 1, 2018 at 9:11 AM, Thomas Gummerer wrote: > > So while playing with it a bit more I found one case where the new UI > > is not ideal and a bit confusing. Namely when the new check out dwim > > kicks in, but there is already a

Re: Windows > git.exe > the result of "git branch" does not always highlight the current branch

Hi Hari, thanks for reporting a bug! On Mon, Apr 9, 2018 at 12:26 PM, Hari Lubovac wrote: > It appears to be just a reporting issue. Probably not a big deal, but > I thought I should report this, if it hasn't been noticed: when a > branch is switched to by being named with

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote: > On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer > wrote: > > This round should fix all the UI issues Eric found in the last round. > > The changes I made in a bit more detail: > > > > - added a new commit introducing a new hidden

Windows > git.exe > the result of "git branch" does not always highlight the current branch

It appears to be just a reporting issue. Probably not a big deal, but I thought I should report this, if it hasn't been noticed: when a branch is switched to by being named with non-original character-casing, then it's not clear which branch is current. Example: C:\repo>git branch * bar foo

[PATCH v2] Make running git under other debugger-like programs easy

This allows us to run git, when using the script from bin-wrappers, under other programs. A few examples for usage within testsuite scripts: debug git checkout master debug --debugger=nemiver git $ARGS debug -d "valgrind --tool-memcheck --track-origins=yes" git $ARGS Or, if someone has

Re: [PATCH 06/19] refs: add repository argument to get_main_ref_store

Hi Eric, On Fri, Apr 6, 2018 at 11:53 PM, Eric Sunshine wrote: >> >> # Conflicts: >> # t/helper/test-ref-store.c > > Meh. Fixed in a reroll.

Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand

On Sun, Apr 8, 2018 at 11:26 AM, Florian Gamböck wrote: > Adding external subcommands to Git is as easy as to put an executable > file git-foo into PATH. Packaging such subcommands for a Linux > distribution can be achieved by unpacking the executable into /usr/bin > of the user's

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: Want to start contributing to git through this task: "Use dir-iterator to avoid explicit recursiv

On Mon, Apr 9, 2018 at 9:51 AM, vaibhav kurhe wrote: > https://git.github.io/SoC-2018-Microprojects/. > Out of the tasks listed down in above URL, I found this one interesting:- > "Use dir-iterator to avoid explicit recursive directory traversal" > I cloned the git repo

Re: [PATCH v2 03/10] commit: add generation number to struct commmit

On Mon, Apr 9, 2018 at 9:42 AM, Derrick Stolee wrote: > 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 >

Re: Is offloading to GPU a worthwhile feature?

On 04/08/18 09:59, Jakub Narebski wrote: >> This is an entirely idle pondering kind of question, but I wanted to >> ask. I recently discovered that some edge providers are starting to >> offer systems with GPU cards in them -- primarily for clients that need >> to provide streaming video content,

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

Hi René, On Fri, Apr 6, 2018 at 9:58 PM, René Scharfe wrote: > Am 07.04.2018 um 01:21 schrieb Stefan Beller: >> This applies on top of 464416a2eaadf84d2bfdf795007863d03b222b7c >> (sb/packfiles-in-repository). >> It is also available at >>

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

On Sat, Apr 7, 2018 at 2:50 AM, Duy Nguyen wrote: > 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

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

+cc list On Mon, Apr 9, 2018 at 1:39 AM, Johannes Schindelin wrote: > Hi Stefan, > > On Fri, 6 Apr 2018, Stefan Beller wrote: > >> See cfc62fc98c (sha1_file: add repository argument to link_alt_odb_entry, >> 2018-03-23) for explanation. > > "See ... for explanation."

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

On Mon, Apr 9, 2018 at 6:15 AM, Derrick Stolee wrote: > I don't understand how folding the patches makes the correctness clearer, > since the rename (1/4) is checked by the compiler and the Coccinelle script > (3/4) only works after that rename is complete. > > The only thing I

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

On Mon, Apr 9, 2018 at 8:31 AM, Duy Nguyen wrote: > 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()

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

On 09/04/18 14:37, Derrick Stolee wrote: > On 4/9/2018 6:21 AM, Junio C Hamano wrote: >> * ds/commit-graph (2018-04-02) 16 commits >>   - commit-graph: implement "--additive" option >>   - commit-graph: build graph from starting commits >>   - commit-graph: read only from specific pack-indexes

[PATCH v2 08/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 v2 09/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 v2 10/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 v2 02/10] merge: check config before loading commits

In anticipation of using 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

[PATCH v2 07/10] commit-graph.txt: update future work

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 two "special" generation numbers GENERATION_NUMBER_INFINITY and *_ZERO interact with other generation numbers. Signed-off-by: Derrick

[PATCH v2 05/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 v2 04/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 v2 06/10] commit.c: use generation to halt paint walk

In paint_down_to_common(), the walk is halted when the queue contains only stale commits. The queue_has_nonstale() method iterates over the entire queue looking for a nonstale commit. In a wide commit graph where the two sides share many commits in common, but have deep sets of different commits,

[PATCH v2 03/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 v2 01/10] object.c: parse commit in graph first

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(). Before adding generation numbers to the commit-graph, we

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

Thanks for the lively discussion of this patch series in v1! I've incorporated the feedback from the previous round, added patches [7/6] and [8/6], expanded the discussion of generation numbers in the design document, and added another speedup for 'git branch --contains'. One major difference: I

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 >

  1   2   >