Hi Dscho,
Install went Ok.
Did a quick test on the config locations and `git config -l
-show-origin` has 'lost' the ProgramData location as planned.
The minor pedant did notice that the new location is listed slightly
differently from the release notes.
`file:C:/Program Files/Git/mingw64/..
Hi Jadian,
On Fri, Aug 09, 2019 at 12:31:12AM -0500, Jadian Radiator wrote:
> Git For Windows' installer can't see my Atom installation.
> I got Atom directly from Atom's official site.
This is the Git mailing list, which does not answers questions about Git
for Windows, or Atom, both of which ar
On Fri, Aug 02, 2019 at 09:53:55AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > We'll also want to update the docs. And as Todd suggests, we should
> > cover how to disable mailmap in tests.
> >
> > Signed-off-by: Jonathan Nieder
> > ---
>
> I avoided the "don't bother initial
Jonathan Nieder writes:
> We'll also want to update the docs. And as Todd suggests, we should
> cover how to disable mailmap in tests.
>
> Signed-off-by: Jonathan Nieder
> ---
I avoided the "don't bother initializing use_mailmap_config to
unknown" simplification, but I guess the change is clea
Junio C Hamano wrote:
> I suspect that you may have misread the "is interactive" bit in the
> original; that was used only to decide if we are going to warn.
Ah. That was indeed confusing. Anyway, it's nice to see the complexity
go away.
[...]
> +++ b/builtin/log.c
[...]
> @@ -214,12 +204,8 @@
Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
+ if (mailmap < 0)
mailmap = 0;
- }
>>>
>>> This should be "mailmap = 1" to match the commit message, no? (Which
>>> also implies we may want a new test).
>>
[...]
> +test_expect_success 'log.mai
Junio C Hamano writes:
> Jeff King writes:
>
>>> + if (mailmap < 0)
>>> mailmap = 0;
>>> - }
>>
>> This should be "mailmap = 1" to match the commit message, no? (Which
>> also implies we may want a new test).
>
> Gaa, of course.
-- >8 --
From: Junio C Hamano
Date: Thu, 1 Aug 20
Jeff King writes:
>> +if (mailmap < 0)
>> mailmap = 0;
>> -}
>
> This should be "mailmap = 1" to match the commit message, no? (Which
> also implies we may want a new test).
Gaa, of course.
> I'd also be OK with leaving it at "0" for now, making a note of the
> upcoming cha
Hi Bryan,
On Wed, 31 Jul 2019, Bryan Turner wrote:
> On Wed, Jul 31, 2019 at 5:43 AM Johannes Schindelin
> wrote:
> >
> > Hi,
> >
> > On Mon, 29 Jul 2019, Junio C Hamano wrote:
> >
> > > An early preview release Git v2.23.0-rc0 is now available for
> > > testing at the usual places. It is compr
Hi,
On Wed, 31 Jul 2019, Ariadne Conill wrote:
> Hello,
>
> On Wed, Jul 31, 2019 at 10:21 PM Junio C Hamano wrote:
> >
> > Jeff King writes:
> >
> > > This seems OK to me, though I kind of wonder if anybody really wants
> > > "auto". Unlike log.decorate, which changes the syntax, there is no re
On Thu, Aug 01, 2019 at 08:45:54AM -0700, Junio C Hamano wrote:
> While I think "revert to hardcoded default" may be a good idea, I do
> not think the hardcoded default you implemented that changes the
> behaviour based on the output destination makes much sense. If I
> want to eradicate jun...@c
Hello,
On Thu, Aug 1, 2019 at 10:46 AM Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
> > Although as Dscho mentions, it's particularly irritating because it is
> > not part of the paginated output.
> > ...
> > Let's bite the bullet and jump straight to --use-mailmap in case (4).
> >
> > Wh
Jonathan Nieder writes:
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
> ...
> Let's bite the bullet and jump straight to --use-mailmap in case (4).
>
> While at it, add a new log.mailmap setting "auto" that can be used to
> explicitly
Hello,
On Wed, Jul 31, 2019 at 10:21 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > This seems OK to me, though I kind of wonder if anybody really wants
> > "auto". Unlike log.decorate, which changes the syntax, there is no real
> > reason to avoid mailmap when somebody else is parsing the
Jeff King writes:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto". Unlike log.decorate, which changes the syntax, there is no real
> reason to avoid mailmap when somebody else is parsing the output. And I
> could imagine it is especially confusing if:
>
> git log
On Wed, Jul 31, 2019 at 08:38:14PM -0500, Ariadne Conill wrote:
> > Something like:
> >
> > Author: A U Thor
> > Original-Author: I M Mailmapped
> >
> > gives even more information while leaving the "Author:" line untouched.
> > But in introducing a new line, it may also be breaking somebody
Hello,
On Wed, Jul 31, 2019 at 8:00 PM Jeff King wrote:
>
> On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
>
> > Although as Dscho mentions, it's particularly irritating because it is
> > not part of the paginated output.
> >
> > I wonder if the ideal might not be to trigger it
Jeff King wrote:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto".
Sure. It's just the usual way of handling the lack of support for an
"unset" directive in git's config syntax (for example, if a script
author wants to test the default behavior).
Thanks,
Jonathan
On Wed, Jul 31, 2019 at 5:43 AM Johannes Schindelin
wrote:
>
> Hi,
>
> On Mon, 29 Jul 2019, Junio C Hamano wrote:
>
> > An early preview release Git v2.23.0-rc0 is now available for
> > testing at the usual places. It is comprised of 420 non-merge
> > commits since v2.22.0, contributed by 62 peop
On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
>
> I wonder if the ideal might not be to trigger it more selectively, when
> the output actually changed due to a reflog e
Hello,
On Wed, Jul 31, 2019 at 7:21 PM Jonathan Nieder wrote:
>
> Jeff King wrote:
>
> > I think part of what my annoyance is responding to (and your willingness
> > to just squelch this for everybody) is that switching this particular
> > default isn't really that big a deal, that it requires an
Jeff King wrote:
> I think part of what my annoyance is responding to (and your willingness
> to just squelch this for everybody) is that switching this particular
> default isn't really that big a deal, that it requires annoying people
> on every single "git log" invocation. Perhaps we would be b
On Wed, Jul 31, 2019 at 02:43:10PM +0200, Johannes Schindelin wrote:
> And a corresponding Git for Windows v2.23.0-rc0 can be found here:
>
> https://github.com/git-for-windows/git/releases/tag/v2.23.0-rc0.windows.1
>
> Please test!
>
> One (slightly annoying) issue I found already is that a `g
Hi Stefan,
On Thu, 22 Nov 2018, stefan.na...@atlas-elektronik.com wrote:
> Just a quick note:
>
> I installed v2.20.0-rc0 with these options:
>
> $ cat /etc/install-options.txt
> Editor Option: VIM
> Custom Editor Path:
> Path Option: Cmd
> SSH Option: OpenSSH
> CURL Option: OpenSSL
> CRLF Opti
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote:
> But that test code exists because Bitbucket Server provides a Java API
> [1][2] which allows third-party developers to easily build arbitrary
> Git commands to invoke for their own functionality. Setting
> `GitBranchCreateBuilder.refl
Just a quick note:
I installed v2.20.0-rc0 with these options:
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credentia
On Wed, Nov 21, 2018 at 6:20 AM Jeff King wrote:
>
> On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
>
> > I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> > both Linux and Windows, and the only failures were related to this
> > change:
> >
> > * "git branch -l "
On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
> I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> both Linux and Windows, and the only failures were related to this
> change:
>
> * "git branch -l " used to be a way to ask a reflog to be
>created while creat
On Tue, Nov 20, 2018 at 12:57 PM Johannes Schindelin
wrote:
>
> Team,
>
> On Sun, 18 Nov 2018, Junio C Hamano wrote:
>
> > An early preview release Git v2.20.0-rc0 is now available for
> > testing at the usual places. It is comprised of 887 non-merge
> > commits since v2.19.0, contributed by 71 p
On Fri, Sep 28 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Sep 27 2018, Jonathan Nieder wrote:
>
>>> That said, that seems to me like a lot of work to avoid adding some
>>> patches to "next" that belong in "next" anyway. I understand why the
>>> Git for Windows main
On Fri, Sep 28, 2018 at 09:57:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Another way to look at it, which is closer to what I was thinking about,
> is to just view GFW as some alternate universe "next" branch (which by
> my count is ~2-3k commits ahead of master[1]).
> 1. $ git log --max-parents
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 27 2018, Jonathan Nieder wrote:
>> That said, that seems to me like a lot of work to avoid adding some
>> patches to "next" that belong in "next" anyway. I understand why the
>> Git for Windows maintainer does not always have time to upstream
>> prompt
On Thu, Sep 27 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> So it's similar to various packages that have "alternates" and are semi
>> or permanently forked, like emacs & xemacs, JDK etc., although I can't
>> recall one offhand that's quite similar to GFW v.s. git.g
On Thu, Sep 27, 2018 at 6:24 PM Ævar Arnfjörð Bjarmason
wrote:
> My only stake in this is I thought it would be neat to be able to "apt
> install git-for-windows",
That's what private builds are for (or "PPA" if debian has an
equivalent). I already largely ignore any Windows reports because I
don
Hi,
Ævar Arnfjörð Bjarmason wrote:
> So it's similar to various packages that have "alternates" and are semi
> or permanently forked, like emacs & xemacs, JDK etc., although I can't
> recall one offhand that's quite similar to GFW v.s. git.git.
>
> My only stake in this is I thought it would be n
On Thu, Sep 27 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> GFW is a "friendly fork", but a permanent one it seems. The diff between
>> it and 2.19.0 proper is ~10k lines, and e.g. this last release had
>> experimental stash/rebase in C that 2.19.0 didn't.
>>
>> So it would
On 9/27/2018 12:01 PM, Ævar Arnfjörð Bjarmason wrote:
I had an IRC conversation with Johannes saying I didn't know Git For
Windows builds perfectly well for Linux, this just isn't advertised in
the ANNOUNCE E-Mails, so I hadn't tried.
We run CI to ensure it builds and tests on Mac OSX, too. Thi
Ævar Arnfjörð Bjarmason wrote:
> GFW is a "friendly fork", but a permanent one it seems. The diff between
> it and 2.19.0 proper is ~10k lines, and e.g. this last release had
> experimental stash/rebase in C that 2.19.0 didn't.
>
> So it would be great if this were packaged up by linux distro as s
Team,
On Fri, 24 Aug 2018, Johannes Schindelin wrote:
> while this mail talks about Git for Windows, please keep in mind that we
> try *very* hard to keep Git for Windows' master working correctly not only
> on Windows but also on macOS and Linux.
>
> I, for one, run Git built from Git for Windo
Am 10.01.2018 um 18:37 schrieb Johannes Schindelin:
On Tue, 9 Jan 2018, Junio C Hamano wrote:
Johannes Schindelin writes:
diff --git a/t/t0021/rot13-filter.pl b/t/t0021/rot13-filter.pl
index f1678851de9..470107248eb 100644
--- a/t/t0021/rot13-filter.pl
+++ b/t/t0021/rot13-filter.pl
@@ -31,7 +
> On 28 Oct 2017, at 18:40, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Fri, 27 Oct 2017, Lars Schneider wrote:
>
>>> On 27 Oct 2017, at 14:11, Lars Schneider wrote:
>>>
On 21 Oct 2017, at 00:22, Johannes Schindelin
wrote:
[cutting linux-kernel]
On Fri
Hi Lars,
On Fri, 27 Oct 2017, Lars Schneider wrote:
> > On 27 Oct 2017, at 14:11, Lars Schneider wrote:
> >
> >> On 21 Oct 2017, at 00:22, Johannes Schindelin
> >> wrote:
> >>
> >> [cutting linux-kernel]
> >>
> >> On Fri, 20 Oct 2017, Junio C Hamano wrote:
> >>
> >>> A release candidate Gi
> On 27 Oct 2017, at 14:11, Lars Schneider wrote:
>
>
>> On 21 Oct 2017, at 00:22, Johannes Schindelin
>> wrote:
>>
>> Hi team,
>>
>> [cutting linux-kernel]
>>
>> On Fri, 20 Oct 2017, Junio C Hamano wrote:
>>
>>> A release candidate Git v2.15.0-rc2 is now available for testing
>>> at the
> On 21 Oct 2017, at 00:22, Johannes Schindelin
> wrote:
>
> Hi team,
>
> [cutting linux-kernel]
>
> On Fri, 20 Oct 2017, Junio C Hamano wrote:
>
>> A release candidate Git v2.15.0-rc2 is now available for testing
>> at the usual places.
>
> The Git for Windows equivalent is now available f
Hi Bryan,
On Fri, 20 Oct 2017, Bryan Turner wrote:
> On Fri, Oct 20, 2017 at 3:22 PM, Johannes Schindelin
> wrote:
> >
> > On Fri, 20 Oct 2017, Junio C Hamano wrote:
> >
> >> A release candidate Git v2.15.0-rc2 is now available for testing at
> >> the usual places.
> >
> > The Git for Windows eq
Bryan Turner writes:
>> The Git for Windows equivalent is now available from
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_git-2Dfor-2Dwindows_git_releases_tag_v2.15.0-2Drc2.windows.1&d=DwIBAg&c=wBUwXtM9sKhff6UeHOQgvw&r=uBedA6EFFVX1HiLgmpdrBrv8bIDAScKjk1yk9LOASBM&m
On Fri, Oct 20, 2017 at 3:22 PM, Johannes Schindelin
wrote:
> Hi team,
>
> [cutting linux-kernel]
>
> On Fri, 20 Oct 2017, Junio C Hamano wrote:
>
>> A release candidate Git v2.15.0-rc2 is now available for testing
>> at the usual places.
>
> The Git for Windows equivalent is now available from
>
Hi Steve,
On Mon, 9 Oct 2017, Steve Hoelzer wrote:
> On Thu, Oct 5, 2017 at 3:22 PM, Lars Schneider
> wrote:
> >
> >> On 05 Oct 2017, at 22:02, Johannes Schindelin
> >> wrote:
> >>
> >> Dear Git users,
> >>
> >> It is my pleasure to announce that Git for Windows 2.14.2(2) is available
> >> f
On Thu, Oct 5, 2017 at 3:22 PM, Lars Schneider wrote:
>
>> On 05 Oct 2017, at 22:02, Johannes Schindelin
>> wrote:
>>
>> Dear Git users,
>>
>> It is my pleasure to announce that Git for Windows 2.14.2(2) is available
>> from:
>>
>> https://git-for-windows.github.io/
>>
>> Changes since Gi
Hi Lars,
On Thu, 5 Oct 2017, Lars Schneider wrote:
> > On 05 Oct 2017, at 22:02, Johannes Schindelin
> > wrote:
> >
> > It is my pleasure to announce that Git for Windows 2.14.2(2) is available
> > from:
> >
> > https://git-for-windows.github.io/
> >
> > Changes since Git for Windows v2
> On 05 Oct 2017, at 22:02, Johannes Schindelin
> wrote:
>
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.14.2(2) is available
> from:
>
> https://git-for-windows.github.io/
>
> Changes since Git for Windows v2.14.2 (September 26th 2017)
>
> New Features
>
Hello Jonathan,
On 04.10.2017 04:23, Jonathan Nieder wrote:
+git-for-windows
Hi Marc,
Marc Strapetz wrote:
compat/mingw.c assigns the Windows file creation time [1] to Git's
ctime fields at line 591 and at line 705:
buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
ftCreationTime
+git-for-windows
Hi Marc,
Marc Strapetz wrote:
> compat/mingw.c assigns the Windows file creation time [1] to Git's
> ctime fields at line 591 and at line 705:
>
> buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
>
> ftCreationTime > ftLastWriteTime is actually possible after copying
On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote:
> On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:
> > > > > Cc-ing the Git for Windows mailing list as an FYI.
> > > > >
> > > > > I have faint memories that some developers on that project have had to
> > > > > delv
On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Thu, 24 Aug 2017, Mike Hommey wrote:
>
> > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> > >
> > > On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> > >
> > > > Mike Hommey wrote[1]:
> >
Hi Mike,
On Thu, 24 Aug 2017, Mike Hommey wrote:
> On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> >
> > On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> >
> > > Mike Hommey wrote[1]:
> > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> > > >> Mike Homm
On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 18 Aug 2017, Jonathan Nieder wrote:
>
> > Mike Hommey wrote[1]:
> > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> > >> Mike Hommey wrote:
> >
> > >>> The reason for the :: prefix is that
Hi,
On Fri, 18 Aug 2017, Jonathan Nieder wrote:
> Mike Hommey wrote[1]:
> > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> >> Mike Hommey wrote:
>
> >>> The reason for the :: prefix is that it matches the ::
> >>> prefix used for remote helpers.
> >>>
> >>> Now, there are a f
Hi Hannes,
On Mon, 7 Aug 2017, Johannes Sixt wrote:
> Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
> > On Sun, 6 Aug 2017, Johannes Sixt wrote:
> > > Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> > > > * Comes with [BusyBox
> > > > v1.28.0pre.15857.9480dca7c](https://github
Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
On Sun, 6 Aug 2017, Johannes Sixt wrote:
Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
* Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
git-for-windows/busybox-w32/commit/9480dca7c].
What is the implicati
Hi Hannes,
On Sun, 6 Aug 2017, Johannes Sixt wrote:
> Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> > Dear Git users,
> >
> > It is my pleasure to announce that Git for Windows 2.14.0 is available from:
> >
> > https://git-for-windows.github.io/
> >
> > Changes since Git for Windows v
Hi Lars & Konst,
On Mon, 7 Aug 2017, Konstantin Khomoutov wrote:
> On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:
>
> [...]
> > > * It is now possible to switch between Secure Channel and OpenSSL for
> > >Git's HTTPS transport by setting the http.sslBackend config
> > >
On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:
[...]
> > * It is now possible to switch between Secure Channel and OpenSSL for
> >Git's HTTPS transport by setting the http.sslBackend config
> >variable to "openssl" or "schannel"; This is now also the method
> >used by
> On 06 Aug 2017, at 01:00, Johannes Schindelin
> wrote:
>
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.14.0 is available from:
Thank you :-)
> * It is now possible to switch between Secure Channel and OpenSSL for
>Git's HTTPS transport by setting the http
Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
Dear Git users,
It is my pleasure to announce that Git for Windows 2.14.0 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.13.3 (July 13th 2017)
Thank you so much! One question, though:
New Fe
From: "Johannes Schindelin"
Hi all,
it has been a while since Windows XP support has been dropped from Git for
Windows (v2.10.0 was the last version to support it), mainly due to the
code changes inherited from Cygwin's code base, which discontinued
supporting Windows XP after version 2.5.2 (be
Hi Stepan,
as I commented on your post to the Git for Windows mailing list:
On Tue, 25 Apr 2017, Stepan Kasal wrote:
> I have installed git for windows sdk from the web and tried to build it.
Nobody in the project found the time to update the website yet, but we do
have a simpler way to install
From: "Junio C Hamano"
Sent: Thursday, February 16, 2017 12:20 AM
"Philip Oakley" writes:
It may even be worth 'splitting' the pu branch sequence into the
existing pu (with merges from series that are selected as reasonable),
and then a pr branch (public review?) on top of that holding the re
"Philip Oakley" writes:
> For an integrator, or especially a CI tool, simply checking the second
> parents of each topic merge (post fail) should at least indicate if
> the basics of the feature actually passed the tests, though it doesn't
> check for interaction issues. This could give direct au
"Philip Oakley" writes:
> It may even be worth 'splitting' the pu branch sequence into the
> existing pu (with merges from series that are selected as reasonable),
> and then a pr branch (public review?) on top of that holding the rest
> of the series that have been submitted, so that the CI can
From: "Johannes Schindelin"
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
From: "Christian Couder"
> On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
> wrote:
> > Johannes Schindelin writes:
> >
> > > On Mon, 13 Feb 2017, Junio C Hamano wrote:
> > >
> > > > Johannes Schindelin writ
[sorry for the repeated emails - I'd prepared it off line, and then suffered
a number of auto send actions]
From: "Junio C Hamano"
"Philip Oakley" writes:
In the next..pu case the abstraction is in the other direction, we
have potentially multiple points of infection (from feature branches),
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does not quite
work, though.
I think
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does not quite
work, though.
I think
"Philip Oakley" writes:
> In the next..pu case the abstraction is in the other direction, we
> have potentially multiple points of infection (from feature branches),
> and a broad test (the whole test suite). In this case I believe we
> would like to investigate initially the --first-parent line
From: "Junio C Hamano"
"Philip Oakley" writes:
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does not quite
work, though.
I think
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
> From: "Christian Couder"
> > On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
> > wrote:
> > > Johannes Schindelin writes:
> > >
> > > > On Mon, 13 Feb 2017, Junio C Hamano wrote:
> > > >
> > > > > Johannes Schindelin writes:
> > > > >
>
Hi Christian,
On Wed, 15 Feb 2017, Christian Couder wrote:
> On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
> wrote:
>
> > Probably a less resource intensive approach is to find the tips of the
> > topics not in 'next' but in 'pu' and test them. That would give you
> > which topic(s) are pro
"Philip Oakley" writes:
> There are also a few ideas at the SO answers:
> http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does not quite
work, though.
From: "Christian Couder"
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
wrote:
Johannes Schindelin writes:
On Mon, 13 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
> That is why I taught the Git for Windows CI job that tests the four
> upstream Git integration branches t
Christian Couder writes:
> By the way it should not be very difficult as a patch to do this and
> more was proposed a long time ago:
>
> https://public-inbox.org/git/4d3cddf9.6080...@intel.com/
Thanks for a link. The one I found most interesting in the thread
is by Avery [*1*], where he explain
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>>
>>> Johannes Schindelin writes:
>>>
>>> > That is why I taught the Git for Windows CI job that tests the four
>>> > upstream Git integration branches to *also*
Johannes Schindelin writes:
> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > That is why I taught the Git for Windows CI job that tests the four
>> > upstream Git integration branches to *also* bisect test breakages and
>> > then upload comments to the ident
Hi,
On Mon, 13 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > That is why I taught the Git for Windows CI job that tests the four
> > upstream Git integration branches to *also* bisect test breakages and
> > then upload comments to the identified commit on GitHub
>
> Good.
Hi Lars,
On Fri, 11 Nov 2016, Lars Schneider wrote:
>
> On 10 Nov 2016, at 22:39, Johannes Schindelin
> wrote:
>
> > Hi Lars,
> >
> > On Wed, 9 Nov 2016, Lars Schneider wrote:
> >
> >> On 05 Nov 2016, at 10:50, Johannes Schindelin
> >> wrote:
> >>
> >>> I finally got around to rebase the
On 10 Nov 2016, at 22:39, Johannes Schindelin
wrote:
> Hi Lars,
>
> On Wed, 9 Nov 2016, Lars Schneider wrote:
>
>> On 05 Nov 2016, at 10:50, Johannes Schindelin
>> wrote:
>>
>>> I finally got around to rebase the Windows-specific patches (which seem to
>>> not make it upstream as fast as w
Hi Lars,
On Wed, 9 Nov 2016, Lars Schneider wrote:
> On 05 Nov 2016, at 10:50, Johannes Schindelin
> wrote:
>
> > I finally got around to rebase the Windows-specific patches (which seem to
> > not make it upstream as fast as we get new ones) on top of upstream Git
> > v2.11.0-rc0, and to bundl
On 05 Nov 2016, at 10:50, Johannes Schindelin
wrote:
> Dear Git users,
>
> I finally got around to rebase the Windows-specific patches (which seem to
> not make it upstream as fast as we get new ones) on top of upstream Git
> v2.11.0-rc0, and to bundle installers, portable Git and MinGit [*1*]
Hi Torsten,
On Thu, 25 Aug 2016, Torsten Bögershausen wrote:
> > I was not talking about the cost of correcting mistakes. Running --filters
> > is potentially very costly. Just so you understand what I am talking
> > about: I have a report that says that checking out a sizeable worktree
> > with
I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is horr
Hi Junio,
On Wed, 24 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> In any case, in the ideal future, I would imagine that we would want
> >> to have "cat-file blob" to enable "--filters" by default; that would
> >> make cat-file and hash-objects a pair of symmetric operat
Hi Dakota,
On Wed, 24 Aug 2016, Dakota Hawkins wrote:
> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
> wrote:
> >
> > On Tue, 23 Aug 2016, Dakota Hawkins wrote:
> >
> >> I use GFW almost exclusively, but I pretty much always consult the
> >> upstream documentation anyway (because I find
From: "Dakota Hawkins"
On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
wrote:
Hi Dakota,
On Tue, 23 Aug 2016, Dakota Hawkins wrote:
I use GFW almost exclusively, but I pretty much always consult the
upstream documentation anyway (because I find it easier).
Oh... I thought that typin
Johannes Schindelin writes:
>> In any case, in the ideal future, I would imagine that we would want
>> to have "cat-file blob" to enable "--filters" by default; that would
>> make cat-file and hash-objects a pair of symmetric operations.
>
> I would advocate against that. It is not like the terms
On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
wrote:
> Hi Dakota,
>
> On Tue, 23 Aug 2016, Dakota Hawkins wrote:
>
>> I use GFW almost exclusively, but I pretty much always consult the
>> upstream documentation anyway (because I find it easier).
>
> Oh... I thought that typing "git help gi
Hi Junio,
On Tue, 23 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The feature in question is also highly unlikely to be used as much by
> > non-Windows users as by Windows users due to the unfortunate choice of the
> > default setting for core.autocrlf.
>
> My vague reco
Hi Dakota,
On Tue, 23 Aug 2016, Dakota Hawkins wrote:
> I use GFW almost exclusively, but I pretty much always consult the
> upstream documentation anyway (because I find it easier).
Oh... I thought that typing "git help git-commit" opening a nice HTML page
in your favorite browser was good enou
Hi Junio,
On Tue, 23 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > In case it is not crystal-clear, let me clarify one very important point.
> > It seems that some people mistake the work I do for something I do on a
> > whim. This is not so.
> >
> > The patch series that
Johannes Schindelin writes:
> The feature in question is also highly unlikely to be used as much by
> non-Windows users as by Windows users due to the unfortunate choice of the
> default setting for core.autocrlf.
My vague recollection from some years ago was that even among those
who were activ
On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > One way to avoid that risk may be to release the new feature as
> > "experimental-and-subject-to-change", so that interested users on
> > Windows can actually try it out to see if the feature itself
> > (whate
1 - 100 of 137 matches
Mail list logo
