Hi,
I downloaded git-2.21.0-intel-universal-mavericks.dmg, ran through the
installation proces, ended with the screen 'successfully installed’, but cannot
find the application anywhere on my system.
I have macOS Mojave Version 10.14.3.
Please advice.
Thank you,
Sofie
On 6/4/2019 4:41 PM, Barret Rhoden wrote:
> Hi -
>
> On 6/4/19 12:38 PM, Barret Rhoden wrote:
> However, the only thing we are really testing is that git blame didn't crash.
This would not be enough.
> There is no detectable change to the output. AFAIK, blame_coalesce() is a
> performance enh
On Tue, Jun 04, 2019 at 07:14:18PM -0400, Jeff King wrote:
> Right, that has to be a real colon because it's syntactically
> significant (but a colon in the username _must_ be encoded). That strbuf
> function doesn't really understand whole URLs, and it's up to the caller
> to assemble the parts.
>
Teach difftool and mergetool about VS Code and VS Code Insiders
Signed-off-by: Wen Bei Li
---
Hello Johannes, thank you for reviewing my patch. It's the first time I've done
this via email.
I've added `code-insiders` as you suggested, but I wasn't sure if I should send
it as a v2.
I used this c
On Tue, Jun 04, 2019 at 03:59:21PM -0700, Matthew DeVore wrote:
> > I think you'll find that -Wunused-function complains, though, if nobody
> > is calling it. I wasn't sure if what you showed in the interdiff was
> > meant to be final (I had to add a few other variable declarations to
> > make it
On Tue, Jun 04, 2019 at 02:51:08PM -0400, Jeff King wrote:
> > The purpose of has_reserved_character is to allow for future
> > extensibility if someone decides to implement a more sophisticated DSL
> > and give meaning to these characters. That may be a long-shot, but it
> > seems worth it.
>
> I
On Tue, Jun 4, 2019 at 2:07 PM SZEDER Gábor wrote:
>
> On Tue, Jun 04, 2019 at 01:27:50PM -0700, Elijah Newren wrote:
> > Changes since v1:
> > * Minor tweaks suggested by SZEDER
>
> > diff --git a/t/t6042-merge-rename-corner-cases.sh
> > b/t/t6042-merge-rename-corner-cases.sh
> > index 09dfa8b
SZEDER Gábor writes:
>> +test_must_fail git merge-file \
>> +-L "HEAD" \
>> +-L "" \
>> +-L "A^0" \
>> +ours empty theirs &&
>> +git hash-object b >actual &&
>> +git hash-object our
First message had incorrect recipient list. Re-sending with non-typo'd Jeff's
e-mail address.
Someone also politely reminded me off-band that I should make subsequent
versions of patchsets be respond-to on the cover-letter of v1 of that patchset.
I will do that from next time.
On Tue, Jun 04, 2019 at 01:27:50PM -0700, Elijah Newren wrote:
> Changes since v1:
> * Minor tweaks suggested by SZEDER
> diff --git a/t/t6042-merge-rename-corner-cases.sh
> b/t/t6042-merge-rename-corner-cases.sh
> index 09dfa8bd92..3fe2cd91dc 100755
> --- a/t/t6042-merge-rename-corner-cases.sh
On Sun, Jun 02, 2019 at 06:58:48PM +0200, René Scharfe wrote:
> > That sounds about right. It's basically every version of every tree that
> > has a symlink. Did it make a noticeable difference in timing? Indexing
> > the whole kernel history is already a horribly slow process. :)
>
> Right, I di
Hi -
On 6/4/19 12:38 PM, Barret Rhoden wrote:
I'll try to come up with a test, independent of my blame-ignore work,
that can get in that block.
I have a test that covers blame_coalesce(), which works both with and
without my blame-ignore commit that started this thread.
However, the only th
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), we actually switched from
(oid,mode,path) triplets to a diff_filespec -- but most callsites in the
patch only needed to worry about oid and mode so the commit message
focused on that. The overs
Matthew DeVore writes:
> url_decode_internal could have been tricked into reading past the length
> of the **query buffer if there are fewer than 2 characters after a % (in
> a null-terminated string, % would have to be the last character).
> Prevent this from happening by checking len before dec
On Tue, Jun 4, 2019 at 12:26 AM Elijah Newren wrote:
> On Mon, Jun 3, 2019 at 7:30 PM SZEDER Gábor wrote:
> > > - filespec_from_entry(&tmp, ci->ren1->src_entry, other_stage);
> > > - tmp.path = a->path;
> >
> > Note that 'tmp.path' used to be set ...
> >
> > > -
> > > prev_path_des
Johannes Schindelin writes:
>> On hold.
>> cf. <20190514180349.17245-1-phillip.wood...@gmail.com>
>
> Maybe you meant to say "Will cook in `next`" here?
I meant to label it as "On hold" (as the author asked us not to look
at it during the -rc freeze; see the reference), and haven't found
an ex
On Tue, Jun 4, 2019 at 6:14 AM SZEDER Gábor wrote:
>
> On Tue, Jun 04, 2019 at 12:26:14AM -0700, Elijah Newren wrote:
> > Of course, this wasn't the only bug; it also showed we had a glaring
> > whole in our test coverage -- there's a dearth of tests for rename/add
> > conflicts, and in particular
Hi Junio,
On Mon, 3 Jun 2019, Junio C Hamano wrote:
> * pw/rebase-abort-clean-rewritten (2019-05-15) 4 commits
> - rebase --abort/--quit: cleanup refs/rewritten
> - sequencer: return errors from sequencer_remove_state()
> - rebase: warn if state directory cannot be removed
> - rebase: fix a m
Felipe Contreras writes:
> Commit e198b3a740 changed the behavior of fetch with regards to tags.
> Before, null oids where not ignored, now they are, regardless of whether
> the refs have been explicitly cleared or not.
>
> e198b3a740 (fetch: replace string-list used as a look-up table with a
On Tue, Jun 4, 2019 at 9:35 AM Jeff King wrote:
>
> On Mon, Jun 03, 2019 at 09:13:25PM -0500, Felipe Contreras wrote:
> > I'm not exactly sure the solution is the one we want, but hopefull it gives
> > an
> > idea as to what is needed.
>
> It looks good to me. Thanks for fixing this.
>
> The bre
On Tue, Jun 04, 2019 at 10:19:52AM -0700, Matthew DeVore wrote:
> On Tue, Jun 04, 2019 at 12:13:32PM -0400, Jeff King wrote:
> > > - return has_reserved_character(subspec, errbuf) ||
> > > - url_decode(subspec, errbuf) ||
> > > - gently_parse_list_objects_filter(
> > > -
This roll-up includes simple but important fixes from Brian Carlson and René
Scharfe.
- fix typo of "NUL" in commit heading
- re-enable %-decoding in non-NULL-terminated strings
Matthew DeVore (2):
url: do not read past end of buffer
url: do not allow %00 to represent NUL in URLs
url.c |
There is no reason to allow %00 to terminate a string, so do not allow it.
Otherwise, we end up returning arbitrary content in the string (that which is
after the %00) which is effectively hidden from callers and can escape sanity
checks and validation, and possible be used in tandem with a securit
url_decode_internal could have been tricked into reading past the length
of the **query buffer if there are fewer than 2 characters after a % (in
a null-terminated string, % would have to be the last character).
Prevent this from happening by checking len before decoding the %
sequence.
Helped-by:
On Tue, Jun 04, 2019 at 01:02:43AM +, brian m. carlson wrote:
> It looks like several of the places we do this are in the credential
> manager code, and I think I can agree that usernames and passwords
> should not contain NUL characters (for Basic auth, RFC 7617 prohibits
> it). It also seems
gitignore.txt: make slash-rules more readable
Renew paragraphs relevant for pattern with slash.
Aim to make it more clear and to avoid possible
pitfalls for the reader. Add some examples.
Signed-off-by: Dr. Adam Nielsen
---
Documentation/gitignore.txt | 66
On Tue, Jun 04, 2019 at 07:01:01AM +0200, René Scharfe wrote:
> It's a bit hard to see with the (extended, but still) limited context,
> but url_decode_internal() effectively returns a NUL-terminated string,
> even though it does use a strbuf parameter named "out" for temporary
> storage. So calle
Hi Philip
On 04.06.19 14:34, Philip Oakley wrote:
I think the rules end up being difficult because we describe them from a
coders implementation viewpoint, rather than a users descriptive
viewpoint. Thus we avoided things like the difficult to code slashes in
the front/middle, and we get caugh
On Tue, Jun 04, 2019 at 07:00:34AM +0200, René Scharfe wrote:
> Am 03.06.19 um 22:45 schrieb Matthew DeVore:
> > url_decode_internal could have been tricked into reading past the length
> > of the **query buffer if there are fewer than 2 characters after a % (in
> > a null-terminated string, % woul
On Tue, Jun 04, 2019 at 12:13:32PM -0400, Jeff King wrote:
> > - return has_reserved_character(subspec, errbuf) ||
> > - url_decode(subspec, errbuf) ||
> > - gently_parse_list_objects_filter(
> > - &filter_options->sub[new_index], subspec->buf, errbuf);
> > +
On 6/3/19 2:40 PM, Derrick Stolee wrote:
On 6/3/2019 2:11 PM, Barret Rhoden wrote:
Hi -
On 5/30/19 2:24 PM, Derrick Stolee wrote:
8934ac8c 1190) ent->ignored == next->ignored &&
8934ac8c 1191) ent->unblamable == next->unblamable) {
These lines are part of this diff:
--- a/blame.c
+++
On Mon, Jun 03, 2019 at 03:22:47PM -0700, Matthew DeVore wrote:
> On Mon, Jun 03, 2019 at 08:34:35AM -0400, Jeff King wrote:
> > Great. We might want to stop there, but it's possible could reuse even
> > more code. I didn't look closely before, but it seems this code is
> > decoding a URL. We alre
Hi Miguel,
On Tue, 4 Jun 2019, Miguel Ojeda wrote:
> The ForEachMacros list can reasonably be generated grepping
> the C source code for macros with 'for_each' in their name.
>
> Taken almost verbatim from the .clang-format file in the Linux kernel.
>
> Signed-off-by: Miguel Ojeda
> ---
> We wro
Hi Johannes,
Thanks for the comments. I update the patch ant re-post.
Tigran.
- Original Message -
> From: "Johannes Schindelin"
> To: "Tigran Mkrtchyan"
> Cc: "git" , "Jonathan Nieder"
> Sent: Tuesday, June 4, 2019 4:33:08 PM
> Subject: Re: [PATCH v2] tag: add tag.gpgSign config o
Am 03.06.19 um 16:25 schrieb Drew DeVault:
> @@ -2195,6 +2206,8 @@ int cmd_am(int argc, const char **argv, const char
> *prefix)
> 0, PARSE_OPT_NONEG),
> OPT_BOOL('c', "scissors", &state.scissors,
> N_("strip everything before a scissors li
On 6/4/2019 10:43 AM, Johannes Schindelin wrote:
> Hi Stolee,
>
> On Mon, 3 Jun 2019, Derrick Stolee via GitGitGadget wrote:
>
>> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
>> 'large' as a value. This enables several config values that are
>> beneficial for la
Hi. I am using ssl certificates in order to work with git. The problem is that
on Linux when I trying to work with repository it git asks me passphrase of my
certificate, but on windows it’s don’t work properly. I’m using the same key on
windows and Linux, and windows git client don’t asks to en
Team,
I was a bit too tired last night to wait for the trusty Azure Pipelines to
finish publishing this preview, so with a bit of delay, here comes the
announcement:
https://github.com/git-for-windows/git/releases/tag/v2.22.0-rc3.windows.1
Thanks,
Johannes
On Mon, 3 Jun 2019, Junio C Hamano wro
Hi Stolee,
On Mon, 3 Jun 2019, Derrick Stolee via GitGitGadget wrote:
> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
> 'large' as a value. This enables several config values that are
> beneficial for large repos.
I find `core.size` a bit non-descriptive. Maybe
On Mon, Jun 03, 2019 at 09:13:25PM -0500, Felipe Contreras wrote:
> I noticed a regression with running tests for git-remote-hg; can't seem to be
> able to fetch tags.
>
> Probably all remote helpers that use the import method are affected, if not
> all.
>
> The following patches are meant to te
Hi Tigran,
On Tue, 4 Jun 2019, Tigran Mkrtchyan wrote:
> As may CI/CD tools don't allow to control command line options when
s/may/many/, maybe?
> executing `git tag` command, a default value in the configuration file
> will allow to enforce tag signing if required.
>
> The new config-file opti
On Mon, Jun 03, 2019 at 09:13:30PM -0500, Felipe Contreras wrote:
> Commit e198b3a740 changed the behavior of fetch with regards to tags.
> Before, null oids where not ignored, now they are, regardless of whether
> the refs have been explicitly cleared or not.
>
> e198b3a740 (fetch: replace str
On Mon, Jun 03, 2019 at 09:13:27PM -0500, Felipe Contreras wrote:
> This used to work, but commit e198b3a740 broke it.
>
> e198b3a740 (fetch: replace string-list used as a look-up table with a
> hashmap)
>
> Probably all remote helpers that use the import method are affected, but
> we didn't
On Mon, Jun 03, 2019 at 09:13:26PM -0500, Felipe Contreras wrote:
> diff --git a/t/t5801/git-remote-testgit b/t/t5801/git-remote-testgit
> index 752c763eb6..f2b551dfaf 100755
> --- a/t/t5801/git-remote-testgit
> +++ b/t/t5801/git-remote-testgit
> @@ -11,13 +11,10 @@ fi
> url=$2
>
> dir="$GIT_D
On Tue, Jun 4, 2019 at 8:03 AM Johannes Sixt wrote:
>
> Am 04.06.19 um 00:00 schrieb Drew DeVault:
> > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:
> >> I have to wonder how --check works when 'am' applies multiple patches.
> >>
> >> When the second patch in a patch series depends on that t
Before this patch, there is inconsistency between the status messages with
hints and the ones without hints: there is an empty line between the title
and the file list if hints are presented, but there isn't one if there are
no hints.
This patch remove the inconsistency by removing the empty lines
From: John Lin
Before this patch, there is inconsistency between the status
messages with hints and the ones without hints: there is an
empty line between the title and the file list if hints are
presented, but there isn't one if there are no hints.
This patch remove the inconsistency by removin
Hi Wen Bei Li,
On Mon, 3 Jun 2019, Wen Bei Li wrote:
> Teach difftool and mergetool about VS Code.
> ---
Even if it is a very short commit message (see e.g.
https://github.com/git-for-windows/git/commit/581d2fd9f2d6 for a typical
commit message in Git's repository), I think it is okay.
Personal
Hi,
On Tue, 4 Jun 2019, Johannes Sixt wrote:
> Am 04.06.19 um 00:00 schrieb Drew DeVault:
> > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:
> >> I have to wonder how --check works when 'am' applies multiple patches.
> >>
> >> When the second patch in a patch series depends on that the first
Hi John Lin,
On Mon, 3 Jun 2019, 林自均 wrote:
> Thank you for your kind and detailed explanation. I really appreciate
> that. By the way, I just saw it passed all the Azure Pipeline checks.
> Please consider merging it into nd/switch-and-restore. Thank you.
Could you issue a new `/submit`, now tha
Hi Phillip,
On Mon, 3 Jun 2019, Phillip Wood wrote:
> On 03/06/2019 14:40, Johannes Schindelin wrote:
> >
> > On Sun, 2 Jun 2019, Phillip Wood wrote:
> >
> > > On 22/03/2019 14:06, Johannes Schindelin wrote:
> > >
> > > > On Thu, 13 Sep 2018, Phillip Wood wrote:
> > > >
> > > > > On 03/09/2018 20
On Tue, Jun 04, 2019 at 12:26:14AM -0700, Elijah Newren wrote:
> Of course, this wasn't the only bug; it also showed we had a glaring
> whole in our test coverage -- there's a dearth of tests for rename/add
> conflicts, and in particular none involving content merges for the
> rename side. So, I c
Hi Adam,
On 31/05/2019 08:44, Dr. Adam Nielsen wrote:
gitignore.txt: make slash-rules more readable
Remove meta-rule in a paragraph for trailing-slash.
Be precise whenever a trailing slash would make a
difference. Improve paragraph for pattern without slash.
Remove rule for leading slash because
As may CI/CD tools don't allow to control command line options when
executing `git tag` command, a default value in the configuration file
will allow to enforce tag signing if required.
The new config-file option tag.gpgSign enforces signed tags. Additional
command line option --no-gpg-sign is add
As there was some interest on my original pull request on github[1],
I decided to rebase, update the commit message and re-post this patch.
[1] https://github.com/git/git/pull/419
On 03/06/2019 19:01, Junio C Hamano wrote:
Philip Oakley writes:
From a user perspective, implementation issues shouldn't be part of
the description unless absolutely essential.
Most user aren't aware of the implementation so don't grok/understand
what the fuss is about and ignore it...
Oh,
> Ben: Could you rerun all your special testcases to make sure things
> are good with this patch too? It'd be much appreciated.
Many thanks for the super fast turnaround Elijah and Szeder!
I can confirm with 2.22.0-rc3 plus your patch this failing testcase
now passes, and indeed our entire Git t
On Mon, Jun 3, 2019 at 7:30 PM SZEDER Gábor wrote:
>
> On Tue, Jun 04, 2019 at 11:32:24AM +1000, Ben Humphreys wrote:
> > Hi folks,
> >
> > I’m one of the Bitbucket Server developers and I just wanted to let
> > you know of one of our test cases that is now failing on the 2.22.0
> > release candid
58 matches
Mail list logo
