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
> >
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
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, ,
> >
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
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
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
`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
*** 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 +++-
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
> > >
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
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
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
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 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
>>
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
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
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 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
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
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))
>> + /*
>> +
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
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
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.
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
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:
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 @@
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
>
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
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
>
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) {
> +
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
>
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
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
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 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
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
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
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
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
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
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
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
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
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.
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
> >
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
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
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
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
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 &
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
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
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
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.
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
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
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)
*
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
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
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
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
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
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
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 +-
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
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
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
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
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
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
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.
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;
> > +
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
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
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
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
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 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
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
>>
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
>
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:".
-
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,
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
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
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
>
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]
>
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) {
>>
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"));
>
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
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
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
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
92 matches
Mail list logo