On Fri, Dec 14, 2018 at 7:50 AM Jacob Keller wrote:
>
> On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo wrote:
> >
> > On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
> > >
> > > > > The current situation is definitely a problem. If I am in a worktree,
> > > > > using "head" should be the sa
On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo wrote:
>
> On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
> >
> > > > The current situation is definitely a problem. If I am in a worktree,
> > > > using "head" should be the same as "HEAD".
> >
> > By any chance, is your file system case insen
On Thu, 13 Dec 2018, Stefan Beller wrote:
> > cool, thanks for the feedback - I will then try to make it happen
> > quick one (so when I get to it I know): should I replicate all those
> > tests you have for other update strategies? (treating of config
> > specifications etc)
> If there is a
On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> Currently, users who do not have GPG installed have no way to discern
> signed from unsigned commits without examining raw commit data. I
> propose two new pretty-print placeholders to expose this information:
>
> %GR: full ("R"aw) contents
Duy Nguyen writes:
> If you make "head" work like "HEAD", then it should work for _all_
> commands, not just worktree, and "MASTER" should match
> "refs/heads/master" and so on. I don't think it's as simple as
> changing strcmp to strcasecmp. You would need to make ref management
> case-insensiti
Jonathan Tan writes:
> When fetching into a repository, a connectivity check is first made by
> check_exist_and_connected() in builtin/fetch.c that runs:
>
> git rev-list --objects --stdin --not --all --quiet <(list of objects)
>
> If the client repository has many refs, this command can be slo
"Randall S. Becker" writes:
> Hi all,
>
> I have a strange situation and need help with resolving funky characters in
> .git/config. My situation is this:
>
> [diff "*.dat"]
> textconv = enscribe-conv
> --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224
>
> Basically this i
Stefan Beller writes:
> From: Junio C Hamano
>
> In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
> config option, 2016-02-29), we made sure to keep the default behavior
> of a fetching at most one submodule at once when not setting the
> newly introduced `submodule.fetchJobs` c
Duy Nguyen writes:
> On Thu, Dec 13, 2018 at 7:08 PM Duy Nguyen wrote:
>> There's also a bug in my patch (-2 is already being used by
>> parse_opt_unknown_cb and my patch will change behavior of git-blame at
>> least in theory).
>
> Ah no. Too many magic numbers in parse-options.c code. It's wor
Sergey Organov writes:
> I came up with the following as a preparatory change. Looks acceptable?
>
> -- 8< --
>
> t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
>
> We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
> this method to for
Derrick Stolee writes:
>> FWIW, I personally do not think "is sensitive to CRLF" is too bad,
>> as my attempt to clarify it does not make it much better, e.g.
>>
>> The logic to read from these files in shell uses built-in
>> "read" command, which leaves CR at the end of these text
>>
Ævar Arnfjörð Bjarmason writes:
>> +# Other protocol versions (e.g. 2) allow fetching an unadvertised
>> +# object, so run this test with the default protocol version (0).
>> +test_must_fail env GIT_TEST_PROTOCOL_VERSION= git -C client fetch-pack
>> ../server \
>> $(git
Jeff King writes:
> This helper function looks for config in two places: transfer.hiderefs,
> or $section.hiderefs, where $section is passed in by the caller (and is
> "uploadpack" or "receive", depending on the context).
>
> In preparation for callers which do not even have that context (namely
Jeff King writes:
> In protocol v2, instead of just running "upload-pack", we have a generic
> "serve" loop which runs command requests from the client. What used to
> be "upload-pack" is now generally split into two operations: "ls-refs"
> and "fetch". The latter knows it must respect uploadpack
On Wed, Dec 12, 2018 at 10:14:53AM -0800, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The new test_oid machinery in the test library requires reading
> some information from t/oid-info/hash-info and t/oid-info/oid.
> The shell logic that reads from these files is sensitive t
On Thu, Dec 13, 2018 at 04:14:28PM -0500, Mike Rappazzo wrote:
> On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
> >
> > > > The current situation is definitely a problem. If I am in a worktree,
> > > > using "head" should be the same as "HEAD".
> >
> > By any chance, is your file system cas
On Thu, Dec 13, 2018 at 2:44 PM Yaroslav O Halchenko
wrote:
>
>
> On Thu, 13 Dec 2018, Stefan Beller wrote:
>
> > > and kaboom -- we have a new test. If we decide to test more -- just tune
> > > up
> > > test_expect_unchanged_submodule_status and done -- all the tests remain
> > > sufficiently p
On Thu, 13 Dec 2018, Stefan Beller wrote:
> > and kaboom -- we have a new test. If we decide to test more -- just tune up
> > test_expect_unchanged_submodule_status and done -- all the tests remain
> > sufficiently prescribed.
> > What do you think?
> That is pretty cool. Maybe my gut reactio
On 2018.12.12 17:17, Masaya Suzuki wrote:
> On Wed, Dec 12, 2018 at 3:02 AM Jeff King wrote:
> > This ERR handling has been moved to a very low level. What happens if
> > we're passing arbitrary data via the packet_read() code? Could we
> > erroneously trigger an error if a packfile happens to hav
On Thu, Dec 13, 2018 at 9:19 AM Yaroslav Halchenko wrote:
>
> Example - on http://datasets.datalad.org we have a few hundred datasets
> organized into a hierarchy as git submodules. Each git submodules carries
> its
> own .git/ directory so they are "self sufficient" and we could readily assess
Clarify description of %G? = "U" to say it can mean good signature but
untrusted key.
Make wording consistent between %G* placeholders and other placeholders
by removing the verb "show".
Signed-off-by: John Passaro
---
Documentation/pretty-formats.txt | 13 +++--
1 file changed, 7 inser
Test that when GPG cannot be run, new placeholders %GR and %G+ are
unaffected, %G? always returns 'N', and other GPG-related placeholders
return blank.
As of e5a329a279 ("run-command: report exec failure" 2018-12-11), if GPG
cannot be run and placeholders requiring GPG are given, git complains to
Add new pretty-format placeholders %GR and %G+ to support inspecting
gpgsig commit header in pretty format, even if GPG is not available.
Signed-off-by: John Passaro
---
Documentation/pretty-formats.txt | 2 ++
pretty.c | 36 ++--
2 files chan
Currently, users who do not have GPG installed have no way to discern
signed from unsigned commits without examining raw commit data. I
propose two new pretty-print placeholders to expose this information:
%GR: full ("R"aw) contents of gpgsig header
%G+: Y/N if the commit has nonempty gpgsig heade
Test that %GR output ("Raw" contents of "gpgsig" header) looks like
ASCII-armored GPG signature.
Test %G+ (Y/N for presence/absence of "gpgsig" header) by adding it to
existing format tests for signed commits.
Signed-off-by: John Passaro
---
t/t7510-signed-commit.sh | 30 +++
On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
>
> > > The current situation is definitely a problem. If I am in a worktree,
> > > using "head" should be the same as "HEAD".
>
> By any chance, is your file system case insensitive?
> That is usually the source of confusion for these discussi
On Thu, Dec 13, 2018 at 3:43 PM Duy Nguyen wrote:
>
> On Thu, Dec 13, 2018 at 9:34 PM Mike Rappazzo wrote:
> >
> > On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
> > >
> > > On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> > > wrote:
> > > >
> > > > From: Michael Rappazzo
> > The current situation is definitely a problem. If I am in a worktree,
> > using "head" should be the same as "HEAD".
By any chance, is your file system case insensitive?
That is usually the source of confusion for these discussions.
Maybe in worktree code we have a spillover between path
res
On Thu, Dec 13, 2018 at 8:42 AM Yaroslav O Halchenko
wrote:
>
> Thank you Stefan for the review and please pardon my delay with the
> reply, and sorry it got a bit too long by the end ;)
>
> On Wed, 12 Dec 2018, Stefan Beller wrote:
> > Thanks for the patches. The first patch looks good to me!
>
>
On Thu, Dec 13, 2018 at 9:34 PM Mike Rappazzo wrote:
>
> On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
> >
> > On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> > wrote:
> > >
> > > From: Michael Rappazzo
> > >
> > > On a worktree which is not the primary, using the symbol
On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
>
> On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> wrote:
> >
> > From: Michael Rappazzo
> >
> > On a worktree which is not the primary, using the symbolic-ref 'head' was
> > incorrectly pointing to the main worktree's HEAD.
On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
wrote:
>
> From: Michael Rappazzo
>
> On a worktree which is not the primary, using the symbolic-ref 'head' was
> incorrectly pointing to the main worktree's HEAD. The same was true for
> any other case of the word 'Head'.
>
> Sig
From: Michael Rappazzo
On a worktree which is not the primary, using the symbolic-ref 'head' was
incorrectly pointing to the main worktree's HEAD. The same was true for
any other case of the word 'Head'.
Signed-off-by: Michael Rappazzo
---
refs.c | 8
t/t1415-worktr
On a worktree which is not the primary, using the symbolic-ref 'head' was
incorrectly pointing to the main worktree's HEAD. The same was true for any
other casing of the word 'Head'.
Signed-off-by: Michael Rappazzo rappa...@gmail.com [rappa...@gmail.com]
Michael Rappazzo (1):
worktree refs: fix
Just realized that I haven't replied to this yet...
> - I'm a little worried this may happen again with future features. The
> root cause is that "ls-refs" follows a different code path than the
> ref advertisement for "upload-pack". So if we add any new config,
> it needs to go both
Regarding the subject, I think you mean "add a special setup var", not
"add a special setup where".
> +GIT_TEST_PROTOCOL_VERSION=<'protocol.version' config value>, when set,
> +runs the test suite with the given protocol.version. E.g. "0", "1" or
> +"2". Can be set to the empty string within tests
Signed-off-by: Josh Steadmon
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 6b72f37c29..bbcfc2bc9f 100644
--- a/Makefile
+++ b/Makefile
@@ -3104,7 +3104,7 @@ cover_db_html: cover_db
# An example command to build against libFuzzer from L
Breaks load_commit_graph_one() into a new function,
parse_commit_graph(). The latter function operates on arbitrary buffers,
which makes it suitable as a fuzzing target. Since parse_commit_graph()
is only called by load_commit_graph_one() (and the fuzzer described
below), we omit error messages tha
fuzz-commit-graph identified a case where Git will read past the end of
a buffer containing a commit graph if the graph's header has an
incorrect chunk count. A simple bounds check in parse_commit_graph()
prevents this.
Signed-off-by: Josh Steadmon
---
commit-graph.c | 14 --
Add a new fuzz test for the commit graph and fix a buffer read-overflow
that it discovered. Additionally, fix the Makefile instructions for
building fuzzers.
Changes since V3:
* Improve portability of the new test functionality.
* Fix broken &&-chains in tests.
Changes since V2:
* Avoid poi
From: Ben Peart
To make git perform well on the very largest repos, we must make git
operations O(modified) instead of O(size of repo). This takes advantage of
the fact that the number of files a developer has modified (especially
in very large repos) is typically a tiny fraction of the overall
Am 13.12.18 um 07:25 schrieb Johannes Sixt:
Am 13.12.18 um 03:48 schrieb Junio C Hamano:
So,... what's the conclusion? The patch in the context of my tree
would be a no-op, and we'd need a prerequisite change to the support
function to accompany this patch to be effective?
Correct, that is my
William Hubbs wrote:
> Is the git team on an irc channel somewhere,
Some like to use #git-devel on freenode.
> or should I start sending
> patches that I know are incomplete to the list?
Yeah, that's fine. Include [WIP/PATCH] in the subject line to
Hi Jonathan,
On Fri, Dec 07, 2018 at 02:44:28PM -0800, Jonathan Nieder wrote:
> William Hubbs wrote:
> > On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
>
> >> There *is* a way to get what you want that is super easy and will
> >> definitely work: if you sit down and do it ;-
Hi Andrew,
On Thu, 13 Dec 2018, Andrew Kharchenko wrote:
> I found a bug in Git v. 2.20.0 and 2.19.x at least, where pre-commit hook
> does not work properly.
>
> OS: macOS High Sierra
> Git: 2.20.0, 2.19.x
>
> Description: pre-commit file should be marked as executable in order to
> recreate
On Thu, Dec 13, 2018 at 2:03 PM Stefan Beller wrote:
> In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
> config option, 2016-02-29), we made sure to keep the default behavior
> of a fetching at most one submodule at once when not setting the
s/of a/of/
> newly introduced `submo
From: Junio C Hamano
In a028a1930c (fetching submodules: respect `submodule.fetchJobs`
config option, 2016-02-29), we made sure to keep the default behavior
of a fetching at most one submodule at once when not setting the
newly introduced `submodule.fetchJobs` config.
This regressed in 90efe595c
When fetching into a repository, a connectivity check is first made by
check_exist_and_connected() in builtin/fetch.c that runs:
git rev-list --objects --stdin --not --all --quiet <(list of objects)
If the client repository has many refs, this command can be slow,
regardless of the nature of th
On Thu, Dec 13, 2018 at 6:17 AM Junio C Hamano wrote:
>
> Sjon Hortensius writes:
>
> > When switching to 2.20 our `git submodule update' (which clones
> > through ssh) broke because our ssh-server rejected the ~20
> > simultaneous connections the git-client makes. This seems to be caused
> > by
On Thu, Dec 13, 2018 at 7:08 PM Duy Nguyen wrote:
> There's also a bug in my patch (-2 is already being used by
> parse_opt_unknown_cb and my patch will change behavior of git-blame at
> least in theory).
Ah no. Too many magic numbers in parse-options.c code. It's working
fine but I'll need to gi
On Thu, Dec 13, 2018 at 3:05 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Thu, Dec 13 2018, Junio C Hamano wrote:
>
> > Here is an excerpt from a draft edition of "What's cooking" report
> > for topics that are about an immediate 2.20.1 maintenance release,
> > with five topics that I plan to merge
setup_git_directory_gently() expects two types of failures to
discover a git directory (e.g. .git/):
- GIT_DIR_HIT_CEILING: could not find a git directory in any
parent directories of the cwd.
- GIT_DIR_HIT_MOUNT_POINT: could not find a git directory in
any parent directories u
Example - on http://datasets.datalad.org we have a few hundred datasets
organized into a hierarchy as git submodules. Each git submodules carries its
own .git/ directory so they are "self sufficient" and we could readily assess
their sizes, and "cut the tree" at any level without looking for the
On Wed, 12 Dec 2018, Stefan Beller wrote:
> > But again, I must confess, that either I forgot or just do not see a
> > clear use-case/demand for submodule.update config myself any longer,
> ok, let's drop that patch then.
ok, But I will cherish it in my memory so whenever the use case
comes ba
Thank you Stefan for the review and please pardon my delay with the
reply, and sorry it got a bit too long by the end ;)
On Wed, 12 Dec 2018, Stefan Beller wrote:
> Thanks for the patches. The first patch looks good to me!
Great!
> > [PATCH 2/2] RF+ENH(TST): compare the entire list of submodule
On 12/12/2018 9:38 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
From: Derrick Stolee
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is sensitive
On 12/12/2018 8:27 PM, Jeff King wrote:
On Wed, Dec 12, 2018 at 11:58:12AM -0800, Jonathan Tan wrote:
Yeah, this was the part that took me a bit to figure out, as well. The
optimization here is really just avoiding a call to lookup_commit(),
which will do a single hash-table lookup. I wonder if
Hello, Junio.
On Thu, Dec 13, 2018 at 02:47:36PM +0900, Junio C Hamano wrote:
> Tejun Heo writes:
>
> > Hmmm... I see. I still have a bit of trouble seeing why doing it that
> > way is better tho. Wouldn't new-object-hook be simpler? They'll
> > achieve about the same thing but one would need
On December 13, 2018 10:08, I wrote:
> I have a strange situation and need help with resolving funky characters
in
> .git/config. My situation is this:
>
> [diff "*.dat"]
> textconv = enscribe-conv
> --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224
>
> Basically this is
On Thu, Dec 13 2018, Ævar Arnfjörð Bjarmason wrote:
Now that we have this maybe we should discuss why these tests show
different things:
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index 086f2c40f6..8b1217ea26 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
There's one t5400-send-pack.sh test which is broken under
GIT_TEST_PROTOCOL_VERSION=1. It's easier to just coerce it to run
under protocol 1. The difference in the output is that there'll be a
"version 1" line which'll make the subsequent "test_cmp". See
protocol.version in git-config(1) which note
Mark those tests that have behavior differences or bugs under
protocol.version=2.
Whether or not these tests should exhibit different behavior is
outside the scope of this change. Some (such as t5500-fetch-pack.sh)
are intentionally different, but others (such as
t7406-submodule-update.sh and t551
The "env --unset=*" argument isn't portable. Neither Solaris or AIX
have it, and probably not a bunch of other POSIX-like OS's.
Using this was suggested on-list[1]. Let's add a check for it so it
doesn't sneak into the codebase in the future.
1. https://public-inbox.org/git/cover.1544573604.git.j
From: Jeff King
In protocol v2, instead of just running "upload-pack", we have a generic
"serve" loop which runs command requests from the client. What used to
be "upload-pack" is now generally split into two operations: "ls-refs"
and "fetch". The latter knows it must respect uploadpack.* config,
From: Jonathan Tan
Currently, if support for running Git's entire test suite with protocol
v2 were added, some tests would fail because the fetch-pack CLI command
dies if it encounters protocol v2. To avoid this, teach fetch-pack
support for protocol v2.
Signed-off-by: Jonathan Tan
Signed-off-b
From: Jeff King
In the v2 protocol, upload-pack's advertisement has been moved to the
"ls-refs" command. That command does not respect hidden-ref config (like
transfer.hiderefs) at all, and advertises everything.
While there are some features that are not supported in v2 (e.g., v2
always allows
I figured it would be easier for everyone if I rolled this all into
one series instead of Junio & us needing to keep track of what's based
on what.
The only change I made to Jeff's patches is my SOB and adding a
paragraph to the end of his 3/3 saying that the v2 push protocol
doesn't have the same
From: Jeff King
This helper function looks for config in two places: transfer.hiderefs,
or $section.hiderefs, where $section is passed in by the caller (and is
"uploadpack" or "receive", depending on the context).
In preparation for callers which do not even have that context (namely
the "git-se
Add a GIT_TEST_PROTOCOL_VERSION=X test mode which is equivalent to
running with protocol.version=X. This is needed to spot regressions
and differences such as "ls-refs" behaving differently with
transfer.hideRefs. See
https://public-inbox.org/git/20181211104236.ga6...@sigill.intra.peff.net/
for a f
Sergey Organov writes:
> Junio C Hamano writes:
>
>> Sergey Organov writes:
>>
[...]
>>
>> The change to the code itself looks sane, but applying this patch
>> alone will break existing tests whose expectations must be updated,
>> and this new behaviour must be protected by a new test (or two
Hi all,
I have a strange situation and need help with resolving funky characters in
.git/config. My situation is this:
[diff "*.dat"]
textconv = enscribe-conv
--format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224
Basically this is a formatter for diff so that I can show str
Hello,
I found a bug in Git v. 2.20.0 and 2.19.x at least, where pre-commit hook does
not work properly.
OS: macOS High Sierra
Git: 2.20.0, 2.19.x
Description: pre-commit file should be marked as executable in order to
recreate the bug. When executing “git commit”, it silently exits without an
--
Hallo
Groeten van Funding Trusts Finance, we zijn gevestigde en
goedgekeurde Britse leningmaatschappijen, door de jaren heen hebben we
een goed begrip ontwikkeld van uw behoeften en individuele behoeften. we
hebben ons gecommitteerd om onze klanten eerlijk te behandelen en een
servi
Sjon Hortensius writes:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended) change in
> https://github.com/git/git/commi
On Thu, Dec 13 2018, Junio C Hamano wrote:
> Here is an excerpt from a draft edition of "What's cooking" report
> for topics that are about an immediate 2.20.1 maintenance release,
> with five topics that I plan to merge to 'next' and then to 'maint'
> soonish (they're all marked as "Will merge
The oneline notwithstanding, 13374987dd (completion: use _gitcompbuiltin for
format-patch, 2018-11-03) changed also the way send-email options are
completed, by asking the git send-email command itself what options it
offers.
Necessarily, this must fail when built with NO_PERL because send-email
From: Johannes Schindelin
The oneline notwithstanding, 13374987dd (completion: use _gitcompbuiltin
for format-patch, 2018-11-03) changed also the way send-email options
are completed, by asking the git send-email command itself what options
it offers.
Necessarily, this must fail when built with
On Thu, Dec 13 2018, Sjon Hortensius wrote:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended) change in
> https://git
Hi Gábor,
On Thu, 13 Dec 2018, SZEDER Gábor wrote:
> On Thu, Dec 13, 2018 at 05:01:11AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
> > The oneline notwithstanding,13374987dd (completion: use
> > _gitcompbuiltin for format-patch, 2018-11-03) changed also the way
> > send-email options a
Hi CB,
On Thu, 13 Dec 2018, CB Bailey wrote:
> From: CB Bailey
>
> People who have changed their name or email address will usually know
> that they need to set 'log.mailmap' in order to have their new details
> reflected for old commits with 'git log', but others who interact with
> them may n
Hi Gábor,
On Thu, 13 Dec 2018, SZEDER Gábor wrote:
> On Thu, Dec 13, 2018 at 02:01:15PM +0100, Johannes Schindelin wrote:
> >
> > On Wed, 12 Dec 2018, SZEDER Gábor wrote:
> >
> > > On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget
> > > wrote:
> > > > From: Derrick Stol
On Thu, Dec 13, 2018 at 05:01:11AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> The oneline notwithstanding,13374987dd (completion: use _gitcompbuiltin for
> format-patch, 2018-11-03) changed also the way send-email options are
> completed, by asking the git send-email command itself what
On Thu, Dec 13, 2018 at 02:01:15PM +0100, Johannes Schindelin wrote:
> Hi Gábor,
>
> On Wed, 12 Dec 2018, SZEDER Gábor wrote:
>
> > On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget
> > wrote:
> > > From: Derrick Stolee
> > >
> > > The new test_oid machinery in the test
Hi,
On Thu, 13 Dec 2018, Johannes Schindelin wrote:
> On Thu, 13 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
>
> > On Thu, Oct 25 2018, Johannes Schindelin via GitGitGadget wrote:
> >
> > > From: Johannes Schindelin
> > >
> > > As of version 7.56.0, curl supports being compiled with multiple SSL
Hi Ævar,
On Thu, 13 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Oct 25 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > As of version 7.56.0, curl supports being compiled with multiple SSL
> > backends.
> >
> > This patch adds the Git side of that
Hi Gábor,
On Wed, 12 Dec 2018, SZEDER Gábor wrote:
> On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget
> wrote:
> > From: Derrick Stolee
> >
> > The new test_oid machinery in the test library requires reading
> > some information from t/oid-info/hash-info and t/oid-info
From: Johannes Schindelin
With NO_PERL, the `git send-email` script errors out with code 128,
mentioning that Git was built without Perl support.
Therefore, when the completion tries to ask for possible completions via
`git send-email --git-completion-helper`, it won't provide what is
necessary
The oneline notwithstanding,13374987dd (completion: use _gitcompbuiltin for
format-patch, 2018-11-03) changed also the way send-email options are
completed, by asking the git send-email command itself what options it
offers.
Necessarily, this must fail when built with NO_PERL because send-email
i
Hi Junio,
On Thu, 13 Dec 2018, Junio C Hamano wrote:
> * ds/hash-independent-tests-fix (2018-12-12) 1 commit
> - .gitattributes: ensure t/oid-info/* has eol=lf
>
> Test portability fix.
>
> [...]
>
> * js/mailinfo-format-flowed-fix (2018-12-13) 1 commit
> - t4256: mark support files as LF-onl
Fx
Sent from my iPhone
On Thu, Dec 13, 2018 at 12:09:40PM +, CB Bailey wrote:
> I had a dig around in the mailing list archives and couldn't find any
> specific reason not to use a mailmap in log where one is in use. I did
> find this message which suggests that it makes sense to make it the
> default for human-consu
From: CB Bailey
People who have changed their name or email address will usually know
that they need to set 'log.mailmap' in order to have their new details
reflected for old commits with 'git log', but others who interact with
them may not know or care enough to enable this option.
Change the d
Hi Junio,
On Thu, 13 Dec 2018, Junio C Hamano wrote:
>I am taking that https://travis-ci.org/git/git/jobs/466908193
>that succeeded on Windows as a sign that this is now OK there.
I concur,
Dscho
On Thu, Oct 25 2018, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> As of version 7.56.0, curl supports being compiled with multiple SSL
> backends.
>
> This patch adds the Git side of that feature: by setting http.sslBackend
> to "openssl" or "schannel", Git for Wi
When switching to 2.20 our `git submodule update' (which clones
through ssh) broke because our ssh-server rejected the ~20
simultaneous connections the git-client makes. This seems to be caused
by a (possibly unintended) change in
https://github.com/git/git/commit/90efe595c53f4bb1851371344c35eff71f
Jeff King writes:
> On Thu, Dec 13, 2018 at 03:36:53AM +0900, Junio C Hamano wrote:
>
>> test_expect_success 'start_command reports ENOENT (slash)' '
>> -test-tool run-command start-command-ENOENT ./does-not-exist
>> +test-tool run-command start-command-ENOENT ./does-not-exist 2>err &&
>
On Wed, Dec 12, 2018 at 10:27:40AM -0500, John Passaro wrote:
> Thank you for this incredibly quick fix.
>
> I see the fix made it to pu as 6b206be3e5 ("run-command: report exec
> failure" 2018-12-11). For what it's worth, it fixes the issue as far
> as I'm concerned and I'm very glad to see the
On Thu, Dec 13, 2018 at 03:36:53AM +0900, Junio C Hamano wrote:
> In 321fd823 ("run-command: mark path lookup errors with ENOENT",
> 2018-10-24), we rewrote the logic to execute a command by looking
> in the directories on $PATH; as a side effect, a request to run a
> command that is not found on
On Wed, Dec 12, 2018 at 05:17:01PM -0800, Masaya Suzuki wrote:
> > This is a change in the spec with an accompanying change in the code,
> > which raises the question: what do other implementations do with this
> > change (both older Git, and implementations like JGit, libgit2, etc)?
>
> JGit is
99 matches
Mail list logo
