Re: Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

On Thu, Apr 5, 2018 at 4:18 PM, Bryan Turner wrote: > On Thu, Apr 5, 2018 at 12:42 PM, Thierry Moreau > wrote: >> Dear GIT enthusiasts! >> >> This ends up with a "git checkout" command aborting. A bit frustrating at >> the early stage of GIT

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Apr 04, 2018 at 07:02:38PM -0700, Taylor Blau wrote: > +test_expect_success '--no-type unsets type specifiers' ' > + echo "10" > expect && > + git config --type=bool --no-type core.number >actual && > + test_cmp expect actual > +' Actually, one minor nit (not worth a re-roll,

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

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_) > config_with_options(collect_config, , > _config_source, _options); > > + if (!values.nr && default_value) { > +

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Apr 4, 2018 at 10:00 PM, Taylor Blau wrote: > [...] > In this patch, we prefer `--type=[int|bool|bool-or-int|...]` over > `--int`, `--bool`, and etc. This allows the aforementioned upcoming > patch to support querying a color value with a default via `--type=color >

[PATCH v2 3/4] Add a test to verify that push errors are colorful

This actually only tests whether the push errors/hints are colored if the respective color.* config settings are `always`, but in the regular case they default to `auto` (in which case we color the messages when stderr is connected to an interactive terminal), therefore these tests should suffice.

[PATCH v2 2/4] push: colorize errors

From: Ryan Dammrose This is an attempt to resolve an issue I experience with people that are new to Git -- especially colleagues in a team setting -- where they miss that their push to a remote location failed because the failure and success both return a block of white

[PATCH v2 4/4] Document the new color.* settings to colorize push errors/hints

Let's make it easier for users to find out how to customize these colors. Signed-off-by: Johannes Schindelin --- Documentation/config.txt | 28 1 file changed, 28 insertions(+) diff --git a/Documentation/config.txt

[PATCH v2 0/4] Colorize push errors

To help users discern large chunks of white text (when the push succeeds) from large chunks of white text (when the push fails), let's add some color to the latter. The original contribution came in via Pull Request from the Git for Windows project:

[PATCH v2 1/4] color: introduce support for colorizing stderr

So far, we only ever asked whether stdout wants to be colorful. In the upcoming patches, we will want to make push errors more prominent, which are printed to stderr, though. So let's refactor the want_color() function into a want_color_fd() function (which expects to be called with fd == 1 or fd

Re: [PATCH v2 2/4] push: colorize errors

On Thu, Apr 5, 2018 at 3:48 PM, Johannes Schindelin wrote: > From: Ryan Dammrose > > This is an attempt to resolve an issue I experience with people that are > new to Git -- especially colleagues in a team setting -- where they miss > that

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

On Wed, Apr 4, 2018 at 10:59 PM, Taylor Blau wrote: > [...] > This commit (and those following it in this series) aim to eventually > replace `--get-color` with a consistent alternative. By introducing > `--default`, we allow the `--get-color` action to be promoted to a >

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 06:29:18PM -0400, Eric Sunshine wrote: > > +ensure that the variable(s) are of the given type and convert the value to > > the > > +canonical form. If no type specifier is passed, no checks or > > transformations are > > +performed on the value. > > @@ -160,30 +158,34 @@

Re: [PATCH v3] git-svn: allow empty email-address using authors-prog and authors-file

Andreas Heiduk wrote: > Am 05.04.2018 um 09:51 schrieb Eric Wong: > > Can you confirm it's OK for you? Thanks. > > Looks good, works for me. > > Do you squash this patch with with my commit or do you need a reroll? Nope, no need to reroll. Pushed to my repo for Junio.

Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

Dear GIT enthusiasts! This ends up with a "git checkout" command aborting. A bit frustrating at the early stage of GIT learning curve. My first goal is to clone repositories locally in order to explore the various linux kernel versions, with the rich GIT metadata. Thus, I clone: $ git

Re: Errors testing on macOS High Sierra version 10.13.4

On Wed, Apr 4, 2018 at 1:06 PM, Wink Saville wrote: > I built git on a mac osx laptop and got some errors when testing. > I ran ./ci/run-build-and-tests.sh and three of the tests had failures > that appear to be associated with character encoding: > ... > Of course on travis-ci

Re: [PATCH v4 0/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 05:58:00PM -0400, Jeff King wrote: > On Wed, Apr 04, 2018 at 07:00:34PM -0700, Taylor Blau wrote: > > > I have attached a fourth re-roll of my series to introduce > > "--type=" in "git config", and prefer it to "--". > > > > In particular, since the last update, I have

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 06:12:02PM -0400, Jeff King wrote: > On Wed, Apr 04, 2018 at 07:02:38PM -0700, Taylor Blau wrote: > > > +test_expect_success '--no-type unsets type specifiers' ' > > + echo "10" > expect && > > + git config --type=bool --no-type core.number >actual && > > + test_cmp

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

On Thu, Apr 05, 2018 at 06:52:29PM -0400, Eric Sunshine wrote: > On Thu, Apr 5, 2018 at 6:36 PM, Jeff King wrote: > > On Wed, Apr 04, 2018 at 07:59:17PM -0700, Taylor Blau wrote: > >> + if (type == TYPE_COLOR) { > >> + char v[COLOR_MAXLEN]; > >> + if

Is support for 10.8 dropped?

Hi, ALL, I am a successful user of git and my project is locad on GitHub (still in development). I have console git client installed on all 3 major platforms - Windows, Linux and Mac. Up until recently everything was working fine. However about a month ago I started experiencing issues with

Re: Is support for 10.8 dropped?

On Thu, Apr 5, 2018 at 3:48 PM, Igor Korot wrote: > Is support for 10.8 dropped? Until about a year ago, I was still periodically building Git from source on MacOS 10.5, and there hasn't been any outright effort to drop support for older MacOS, so I expect that 10.8 is still

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

On Wed, Apr 04, 2018 at 06:53:04PM -0700, Taylor Blau wrote: > > I understand that you're doing this to avoid complaining about "--int > > --type=int", but exactly how that case is supported should be an > > implementation detail; it doesn't need to bleed into the UI as an > > unnecessary and

Re: Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

On Thu, Apr 5, 2018 at 12:42 PM, Thierry Moreau wrote: > Dear GIT enthusiasts! > > This ends up with a "git checkout" command aborting. A bit frustrating at > the early stage of GIT learning curve. > > My first goal is to clone repositories locally in order to

Re: [RFC PATCH 2/7] dir.c: fix off-by-one error in match_pathspec_item

On Thu, Apr 5, 2018 at 12:04 PM, Jeff King wrote: > On Thu, Apr 05, 2018 at 11:36:45AM -0700, Elijah Newren wrote: > >> > Do we care about matching the name "foo" against the patchspec_item "foo/"? >> > >> > That matches now, but wouldn't after your patch. >> >> So I should

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

Hi Johannes, On Thu, Apr 5, 2018 at 12:57 PM, Johannes Schindelin wrote: > I wonder whether a better approach would be to add an optional argument to > that `debug` function (which is intended to have `git` as first argument, > anyway, or at least a command/function

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

On Thu, Apr 5, 2018 at 12:32 PM, Johannes Schindelin wrote: > Hi Wink, > Note: I have nothing to do with including it. That is the sole discretion > of Junio (who is offline for a week or two, if I understood correctly). > > Ciao, > Johannes txs, I understand.

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

Hi Elijah, On Thu, 5 Apr 2018, Elijah Newren wrote: > This allows us to run git, when using the script from bin-wrappers, under > other programs. A few examples: >GIT_WRAPPER=nemiver git $ARGS >GIT_WRAPPER="valgrind --tool=memcheck --track-origins=yes" git $ARGS > > Yes, we already

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

On Wed, Apr 04, 2018 at 07:59:17PM -0700, Taylor Blau wrote: > 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 >

Re: [PATCH v4 0/3] Teach `--default` to `git-config(1)`

On Wed, Apr 04, 2018 at 07:58:45PM -0700, Taylor Blau wrote: > Hi, > > Attached is a fourth re-roll of my series to add "--default" and > "--type=color" to "git config" in order to replace: > > $ git config --get-color [default] > > with > > $ git config [--default=] --type=color I

Re: [PATCH v4 0/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Apr 04, 2018 at 07:00:34PM -0700, Taylor Blau wrote: > I have attached a fourth re-roll of my series to introduce > "--type=" in "git config", and prefer it to "--". > > In particular, since the last update, I have changed the following: > > - Clearer wording in the second patch per

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

On Thu, Apr 5, 2018 at 6:36 PM, Jeff King wrote: > On Wed, Apr 04, 2018 at 07:59:17PM -0700, Taylor Blau wrote: >> + if (type == TYPE_COLOR) { >> + char v[COLOR_MAXLEN]; >> + if (!git_config_color(v, key, value)) >> + /* >> +

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 06:40:51PM -0400, Jeff King wrote: > On Thu, Apr 05, 2018 at 06:29:18PM -0400, Eric Sunshine wrote: > > > > +ensure that the variable(s) are of the given type and convert the value > > > to the > > > +canonical form. If no type specifier is passed, no checks or > > >

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 06:29:18PM -0400, Eric Sunshine wrote: > On Wed, Apr 4, 2018 at 10:00 PM, Taylor Blau wrote: > > [...] > > In this patch, we prefer `--type=[int|bool|bool-or-int|...]` over > > `--int`, `--bool`, and etc. This allows the aforementioned upcoming > > patch

Re: Errors testing on macOS High Sierra version 10.13.4

On Thu, Apr 5, 2018 at 2:33 PM, Eric Sunshine wrote: > On Wed, Apr 4, 2018 at 1:06 PM, Wink Saville wrote: >> I built git on a mac osx laptop and got some errors when testing. >> I ran ./ci/run-build-and-tests.sh and three of the tests had failures >>

[PATCH v5 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

`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 add extend this

[PATCH v5 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 v5 0/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

Hi, (Apologies for the noise of accidentally sending an empty template cover letter. Here is the real one :-).) Attached is my fifth, and anticipated final re-roll of my series to add "--type=" to "git config" in an effort to replace "--bool" with "--type=bool". I have changed the following

[PATCH v5 0/2] *** SUBJECT HERE ***

*** BLURB HERE *** Taylor Blau (2): builtin/config.c: treat type specifiers singularly builtin/config.c: prefer `--type=bool` over `--bool`, etc. Documentation/git-config.txt | 74 +++--- builtin/config.c | 77 +++-

Hello

Good Day To You, Am Mr.Ali.Please i need your kind Assistance. I will be very glad if you can assist me to receive this sum of ( $22. Million US dollars.) into your bank account for the benefit of our both families, reply me if you are ready to receive this fund. Thanks

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

On Thu, Apr 05, 2018 at 06:40:03PM -0400, Eric Sunshine wrote: > On Wed, Apr 4, 2018 at 10:59 PM, Taylor Blau wrote: > > [...] > > This commit (and those following it in this series) aim to eventually > > replace `--get-color` with a consistent alternative. By introducing > >

Re: Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

On 05/04/18 11:34 PM, Bryan Turner wrote: On Thu, Apr 5, 2018 at 4:18 PM, Bryan Turner wrote: So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory. If your goal is to have worktrees for various versions, that

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 06:12:02PM -0400, Jeff King wrote: > On Wed, Apr 04, 2018 at 07:02:38PM -0700, Taylor Blau wrote: > > > +test_expect_success '--no-type unsets type specifiers' ' > > + echo "10" > expect && > > + git config --type=bool --no-type core.number >actual && > > + test_cmp

Re: [PATCH v5 0/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Thu, Apr 05, 2018 at 10:29:01PM -0700, Taylor Blau wrote: > Hi, Ack. Clearly I am still getting used to things outside of Git LFS. I have sent this topic in response to my series to add "--default" instead of the appropriate series. I'll avoid re-sending it in an effort to reduce further

Re: [PATCH v5 0/2] *** SUBJECT HERE ***

On Thu, Apr 5, 2018 at 10:27 PM, Taylor Blau wrote: > *** BLURB HERE *** > Missing subject and cover letter stuff.. did you submit before you were ready? or did you not mean to include the cover letter? :) -Jake > Taylor Blau (2): > builtin/config.c: treat type specifiers

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

On Thu, Apr 05, 2018 at 06:29:49PM -0400, Jeff King wrote: > 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_) > > config_with_options(collect_config, , > >

Re: [PATCH] specify encoding for sed command

On Thu, Apr 05 2018, Stephon Harris wrote: > Fixes issue with seeing `sed: RE error: illegal byte sequence` when running > git-completion.bash > --- > contrib/completion/git-completion.bash | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH] specify encoding for sed command

On Thu, Apr 5, 2018 at 8:53 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Apr 05 2018, Stephon Harris wrote: > >> Fixes issue with seeing `sed: RE error: illegal byte sequence` when running >> git-completion.bash Please: - prefix the subject line with "completion:". -

Re: [PATCH] specify encoding for sed command

On Thu, Apr 5, 2018 at 2:53 AM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Apr 05 2018, Stephon Harris wrote: >> Fixes issue with seeing `sed: RE error: illegal byte sequence` when running >> git-completion.bash > > This is getting closer to the issue than your previous patch,

Re: How to undo previously set configuration?

On Thu, Apr 05 2018, Olaf Hering wrote: > Am Thu, 05 Apr 2018 10:42:15 +0200 > schrieb Ævar Arnfjörð Bjarmason : > >> I've been meaning to work on this but haven't figured out a good syntax for >> it (suggestions welcome!). > > Just prefix the knob with something like "no." or

Re: How to configure sendemail for no-auth?

astian: > Olaf Hering:> My ~/.gitconfig looks like this, because all cloned > repositories require these settings: >> [sendemail] >> from = Olaf Hering >> envelopesender = o...@aepfle.de >> chainreplyto = false >> ccover = yes >>

Re: How to configure sendemail for no-auth?

Olaf Hering: > My ~/.gitconfig looks like this, because all cloned repositories require > these settings: > [sendemail] > from = Olaf Hering > envelopesender = o...@aepfle.de > chainreplyto = false > ccover = yes > smtpencryption = tls >

Please can i trust you?

Good Day, How are u doing today ? Apologies! I am a military woman ,seeking your kind assistance to move the sum of ($7M USD) to you, as far as i can be assured that my money will be safe in your care until i complete my service here in Afghanistan and come over next month. This is legitimate, and

Great News!

We have a great news about your E-mail address!!! You Won $950,500.00 USD on Amnesty International Kenya online E-mail Promotion. For more details about your prize claims, file with the following; Names: Country: Tel: Regards, Mr. David Ford

RE: How to undo previously set configuration?

On April 5, 2018 7:21 AM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Apr 05 2018, Olaf Hering wrote: > > > Am Thu, 05 Apr 2018 10:42:15 +0200 > > schrieb Ævar Arnfjörð Bjarmason : > > > >> I've been meaning to work on this but haven't figured out a good syntax > for it

Re: [PATCH v7 14/14] commit-graph: implement "--additive" option

On Mon, Apr 2, 2018 at 10:34 PM, Derrick Stolee wrote: > +With the `--append` option, include all commits that are present in the > +$ git rev-parse HEAD | git commit-graph write --stdin-commits --append > + N_("git commit-graph write [--object-dir ] [--append] >

Re: [PATCH v5 2/5] stash: convert apply to builtin

On Thu, Apr 5, 2018 at 9:59 AM, Christian Couder wrote: > On Thu, Apr 5, 2018 at 9:50 AM, Christian Couder > wrote: >> >> So maybe we can get rid of `result` and have something like: >> >>if (argc < 1) { >>

How to undo previously set configuration?

On Thu, Apr 05 2018, Olaf Hering wrote: [Changed subject] > My ~/.gitconfig looks like this, because all cloned repositories require > these settings: > [sendemail] > from = Olaf Hering > envelopesender = o...@aepfle.de > chainreplyto = false >

How to configure sendemail for no-auth?

My ~/.gitconfig looks like this, because all cloned repositories require these settings: [sendemail] from = Olaf Hering envelopesender = o...@aepfle.de chainreplyto = false ccover = yes smtpencryption = tls smtpdomain = sender

Re: [PATCH v5 2/5] stash: convert apply to builtin

On Thu, Apr 5, 2018 at 4:28 AM, Joel Teichroeb wrote: > Add a bulitin helper for performing stash commands. Converting > all at once proved hard to review, so starting with just apply > let conversion get started without the other command being > finished. > > The helper is

Re: [PATCH v3] git-svn: allow empty email-address using authors-prog and authors-file

Thanks for the update. The patch itself looks good, but I noticed one --show-item isn't supported on SVN 1.8.10 for me. I've tested the following on both SVN 1.8.10 and 1.9.5: --- a/t/t9138-git-svn-authors-prog.sh +++ b/t/t9138-git-svn-authors-prog.sh @@ -83,7 +83,8 @@ test_expect_success

Re: [PATCH v5 2/5] stash: convert apply to builtin

On Thu, Apr 5, 2018 at 9:50 AM, Christian Couder wrote: > > So maybe we can get rid of `result` and have something like: > >if (argc < 1) { >error(_("at least one argument is required")); >

Re: How to undo previously set configuration?

Am Thu, 05 Apr 2018 10:42:15 +0200 schrieb Ævar Arnfjörð Bjarmason : > I've been meaning to work on this but haven't figured out a good syntax for > it (suggestions welcome!). Just prefix the knob with something like "no." or "-" or whatever to indicate that it never

From: Mr.Ahmed Owain

Good Day, Please accept my apologies for writing you a surprise letter.I am Mr.Ahmed Owain, account Manager with an investment bank here in Burkina Faso.I have a very important business I want to discuss with you.There is a draft account opened in my firm by a long-time client of our bank.I have

Re: [PATCH v5 2/5] stash: convert apply to builtin

Hi Christian, [please cull a *lot* more of the quoted mail when you do not reference any of it... Thanks] On Thu, 5 Apr 2018, Christian Couder wrote: > On Thu, Apr 5, 2018 at 4:28 AM, Joel Teichroeb wrote: > > > > [...] > > + > > + revision = info->revision.buf; > > +

[PATCH] mergetools: add support for guiffy

Add guiffy as difftool and mergetool guiffy is available on Windows, Linux, and MacOS Signed-off-by: Bill Ritcher --- mergetools/guiffy | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 mergetools/guiffy diff --git a/mergetools/guiffy

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

On Thu, Apr 5, 2018 at 6:37 AM, Johannes Schindelin wrote: > After thinking about this more, I am a lot less opposed to including this > in Git's source code. However, as it is not necessary for Git's > functionality, it should probably go into contrib/, and I would

Great News!!

We have a great news about your E-mail address!!! You Won $950,500.00 USD on Amnesty International Kenya online E-mail Promotion. For more details about your prize claims, file with the following; Names: Country: Tel: Regards, Mr. David Ford

Re: How to undo previously set configuration?

Am Thu, 05 Apr 2018 13:21:02 +0200 schrieb Ævar Arnfjörð Bjarmason : > I'm assuming you mean something like: > [user] > # This is an error > -email Yes. Just some flag to say "whatever value this variable has from earlier parsing, forget it in case it

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

Hi Wink, On Fri, 30 Mar 2018, Wink Saville wrote: > On Fri, Mar 30, 2018 at 3:34 AM, Johannes Schindelin > wrote: > > > > On Tue, 27 Mar 2018, Wink Saville wrote: > > > >> Add bdl-lib.sh which provides functions to assit in debugging git > >> shell scripts and tests.

Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

On 01.04.18 15:24, Lars Schneider wrote: >> TRUE or false are values, but just wrong ones. >> If this test is removed, the user will see "failed to encode "TRUE" to >> "UTF-8", >> which should give enough information to fix it. > > I see your point. However, I would like to stop the processing

Re: [PATCH] mergetools: add support for guiffy

On Thu, Apr 05, 2018 at 08:55:01AM -0500, Bill Ritcher wrote: > Add guiffy as difftool and mergetool > > guiffy is available on Windows, Linux, and MacOS > > Signed-off-by: Bill Ritcher > --- > mergetools/guiffy | 18 ++ > 1 file changed, 18

[RFC PATCH 2/7] dir.c: fix off-by-one error in match_pathspec_item

For a pathspec like 'foo/bar' comparing against a path named "foo/", namelen will be 4, and match[namelen] will be 'b'. The correct location of the directory separator is namelen-1. The reason the code worked anyway was that the following code immediately checked whether the first matchlen

[RFC PATCH 0/7] Fix `git clean` with pathspecs

Sometimes, multiple `git clean $ARGS` invocations (with the exact same flags and parameters for each invocation) are needed to properly clean out the desired files. Sometimes, `git clean $PATHS` just refuses to clean the files it was explicitly told to clean. This patch series aims to address

Re: [RFC PATCH 2/7] dir.c: fix off-by-one error in match_pathspec_item

On Thu, Apr 05, 2018 at 10:34:41AM -0700, Elijah Newren wrote: > For a pathspec like 'foo/bar' comparing against a path named "foo/", > namelen will be 4, and match[namelen] will be 'b'. The correct location > of the directory separator is namelen-1. > > The reason the code worked anyway was

Re: [PATCH 2/2] Documentation: Normalize spelling of 'normalised'

On Thu, Apr 5, 2018 at 10:20 AM, Elijah Newren wrote: > This could be a localization issue, but we had about four dozen > "normalize"s (or variants, e.g. normalized, renormalize, etc.), and only > one "normalised" (no other variants), so normalize normalised into > normalized.

Re: Timing issue in t5570 "daemon log records all attributes"

On Wed, Apr 04, 2018 at 11:57:52PM +0200, Jan Palus wrote: > On 03.04.2018 16:32, Jeff King wrote: > > I'm tempted to say we should just scrap this test. It was added > > relatively recently and only shows the fix for a pretty minor bug. > > It's probably not worth the contortions to make it

[PATCH 2/2] Documentation: Normalize spelling of 'normalised'

This could be a localization issue, but we had about four dozen "normalize"s (or variants, e.g. normalized, renormalize, etc.), and only one "normalised" (no other variants), so normalize normalised into normalized. Signed-off-by: Elijah Newren --- Documentation/git-mktree.txt

[PATCH 1/2] Documentation: Fix several one-character-off spelling errors

Signed-off-by: Elijah Newren --- Documentation/diff-options.txt| 4 ++-- Documentation/git-fetch-pack.txt | 2 +- Documentation/git-for-each-ref.txt| 2 +- Documentation/git-send-email.txt | 2 +-

[PATCH] 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: GIT_WRAPPER=nemiver git $ARGS GIT_WRAPPER="valgrind --tool=memcheck --track-origins=yes" git $ARGS Yes, we already have GIT_TEST_GDB (which could potentially be replaced with

Re: How to undo previously set configuration?

On Thu, Apr 05, 2018 at 03:25:25PM +0200, Olaf Hering wrote: > Am Thu, 05 Apr 2018 13:21:02 +0200 > schrieb Ævar Arnfjörð Bjarmason : > > > I'm assuming you mean something like: > > [user] > > # This is an error > > -email > > Yes. Just some flag to say

[RFC PATCH 1/7] dir.c: Fix typo in comment

Signed-off-by: Elijah Newren --- dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dir.c b/dir.c index dedbf5d476..19212129f0 100644 --- a/dir.c +++ b/dir.c @@ -138,7 +138,7 @@ static size_t common_prefix_len(const struct pathspec *pathspec) *

[RFC PATCH 3/7] t7300: Add some testcases showing failure to clean specified pathspecs

Someone brought me a testcase where multiple git-clean invocations were required to clean out unwanted files: mkdir d{1,2} touch d{1,2}/ut touch d1/t && git add d1/t With this setup, the user would need to run git clean -ffd */ut twice to delete both ut files. A little testing showed some

[RFC PATCH 4/7] dir: Directories should be checked for matching pathspecs too

Even if a directory doesn't match a pathspec, it is possible, depending on the precise pathspecs, that some file underneath it might. So we special case and recurse into the directory for such situations. However, we previously always added any untracked directory that we recursed into to the

[RFC PATCH 6/7] dir: If our pathspec might match files under a dir, recurse into it

For git clean, if a directory is entirely untracked and the user did not specify -d (corresponding to DIR_SHOW_IGNORED_TOO), then we usually do not want to remove that directory and thus do not recurse into it. However, if the user manually specified specific (or even globbed) paths somewhere

[RFC PATCH 7/7] If we do not want globs to recurse into subdirs without -d...

If folks prefer this behavior, I'll squash this patch into the previous. Otherwise, I'll just drop this patch from the series. --- dir.c| 2 +- t/t7300-clean.sh | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/dir.c b/dir.c index f55e24f149..bad75e9fbd 100644

[RFC PATCH 5/7] dir: Make the DO_MATCH_SUBMODULE code reusable for a non-submodule case

The specific checks done in match_pathspec_item for the DO_MATCH_SUBMODULE case are useful for other cases which have nothing to do with submodules. Rename this constant; a subsequent commit will make use of this change. Signed-off-by: Elijah Newren --- dir.c | 6 +++--- 1

Re: [PATCH v3] git-svn: allow empty email-address using authors-prog and authors-file

Am 05.04.2018 um 09:51 schrieb Eric Wong: > Thanks for the update. The patch itself looks good, but I > noticed one --show-item isn't supported on SVN 1.8.10 for me. --show-item is indeed a 1.9.0 thing: https://subversion.apache.org/docs/release-notes/1.9.html#svn-info-item > I've tested the

Re: [RFC PATCH 2/7] dir.c: fix off-by-one error in match_pathspec_item

On Thu, Apr 5, 2018 at 10:49 AM, Jeff King wrote: >> diff --git a/dir.c b/dir.c >> index 19212129f0..c915a69385 100644 >> --- a/dir.c >> +++ b/dir.c >> @@ -384,7 +384,7 @@ static int match_pathspec_item(const struct >> pathspec_item *item, int prefix, >> if (flags &

Re: [RFC PATCH 4/7] dir: Directories should be checked for matching pathspecs too

On Thu, Apr 05, 2018 at 10:34:43AM -0700, Elijah Newren wrote: > Even if a directory doesn't match a pathspec, it is possible, depending > on the precise pathspecs, that some file underneath it might. So we > special case and recurse into the directory for such situations. However, > we

Re: [RFC PATCH 2/7] dir.c: fix off-by-one error in match_pathspec_item

On Thu, Apr 05, 2018 at 11:36:45AM -0700, Elijah Newren wrote: > > Do we care about matching the name "foo" against the patchspec_item "foo/"? > > > > That matches now, but wouldn't after your patch. > > Technically, the tests pass anyway due to the fallback behavior > mentioned in the commit

Re: [RFC PATCH 4/7] dir: Directories should be checked for matching pathspecs too

On Thu, Apr 5, 2018 at 11:58 AM, Jeff King wrote: > It sounds like correct_untracked_entries() is doing the wrong thing, and > it should be aware of the pathspec-matching when culling entries. In > other words, my understanding was that read_directory() does not > necessarily

Re: [RFC PATCH 4/7] dir: Directories should be checked for matching pathspecs too

On Thu, Apr 05, 2018 at 12:15:59PM -0700, Elijah Newren wrote: > On Thu, Apr 5, 2018 at 11:58 AM, Jeff King wrote: > > > It sounds like correct_untracked_entries() is doing the wrong thing, and > > it should be aware of the pathspec-matching when culling entries. In > > other

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

Hi Wink, On Thu, 5 Apr 2018, Wink Saville wrote: > On Thu, Apr 5, 2018 at 6:37 AM, Johannes Schindelin > wrote: > > After thinking about this more, I am a lot less opposed to including this > > in Git's source code. However, as it is not necessary for Git's > >