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
smtppass = smt
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 being implemented as a
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 'autho
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"));
>usage_with_options(git_stash_helper_usage, options);
Maybe we could
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) {
>>error(_("at least one argument is required"));
>>us
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]
> [--stdin-packs|--stdin-c
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
> ccover = yes
>
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 t
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 happened.
Olaf
pgpfQgIWe
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, but
> there's still s
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:".
- nit: replace "running"
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
>> smtpencryption = tls
>>
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
> smtpdomain
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 "-" or whatever to
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
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 (suggestions welcome!).
> >
>
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
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
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 really exists". Just
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;
> > +
> > + if (get_
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.
> >
> > Interesting idea. It
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 b/mergetools/guiffy
new file mo
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 much
> rather have a more descr
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 "whatever value th
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 race-
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 ri
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 insertions(+)
> create mode 100644 m
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 +-
Documentation/git-status.txt
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 | 2 +-
1 file cha
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
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 lis
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 under
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
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 file changed, 3 insert
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)
* ":(icase)path" is t
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 the
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 charac
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.
This and the previo
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 tha
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 GIT_WRAPPE
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 fo
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 & DO_MATCH_SUBMODULE) {
>>
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 previous
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 mes
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 promise to cull full
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 words, my understan
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
> > functionality, it should probably
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. Thanks all.
The follow
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 OSX.
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 clo
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 have
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 probably make the chec
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 that does not start with a da
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 there are no failur
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 supported
by the Git
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 not-
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 Er
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,
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 ex
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 chang
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
> --default=`
>
> Sig
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, &values,
> &given_config_source, &config_options);
>
> + if (!values.nr && d
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
> shoul
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 thin
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
> `--type=color` type speci
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 @@
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:
https://github.com/git-for-windows/git/
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.
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 text.
An example is if I
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 b/Documentation/config.txt
index 4e0cff87f62..40e38
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
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))
>> + /*
>> + * T
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 (!git_config_color
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 explore the
> various linux kernel ve
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.
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 learning curve.
>>
>> My first goal is to clone reposit
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 their push to a remote location failed because the failur
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
>> that appear to be associated with character e
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
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 implies
the git worktree [1] c
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 ex
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 to support querying
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
> > > trans
*** 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 +++-
t/t1
`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 fun
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 n
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 sinc
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 noise
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, &values,
> > &give
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 singularly
> built
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
> > `--default`, we allow
On Thu, Apr 05, 2018 at 06:36:20PM -0400, Jeff King wrote:
> 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
On Thu, Apr 05, 2018 at 06:53:20PM -0400, Jeff King wrote:
> 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) {
> > >> +
On Fri, Apr 6, 2018 at 1:29 AM, Taylor Blau wrote:
> builtin/config.c: prefer `--type=bool` over `--bool`, etc.
This patch isn't just preferring --type; it's actually introducing the
functionality. Perhaps:
builtin/config.c: support --type= as preferred alias for --
(Not worth a re-roll.)
Hi,
Attached is the fifth re-roll of my series to add "--default" and
"--type=color" to "git config" in order to introduce a consistency
between type-specifiers and the historic "--get-color".
I have changed the following since the last series:
- Replace exit() with die() in the case where the
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 exam
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 insertions(+)
diff --git a/co
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 the
Hi,
Here is v6 of this series. I have sent it in direct response to v4
correctly (since v5 was sent elsewhere by mistake).
It contains responses to Eric's feedback in [1].
Thanks,
Taylor
[1]:
https://public-inbox.org/git/20180324005556.8145-1...@ttaylorr.com/T/#mab6aee239c023445fd72693728b566
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 n
1 - 100 of 103 matches
Mail list logo
