Re: [RFC] should these two topics graduate to 'master' soon?

[Junio C Hamano]

Jeff King  writes:

> On Tue, Mar 28, 2017 at 11:51:49AM -0700, Jonathan Nieder wrote:
>
>> > * jc/merge-drop-old-syntax (2015-04-29) 1 commit
>> >
>> >   This topic stops "git merge  HEAD " syntax that
>> >   has been deprecated since October 2007 (and we have issued a
>> >   warning message since around v2.5.0 when the ancient syntax was
>> >   used).
>> >
>> > * jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
>> >
>> >   This is the endgame of the topic to avoid blindly falling back to
>> >   ".git" when the setup sequence said we are _not_ in Git repository.
>> >   A corner case that happens to work right now may be broken by a call
>> >   to die("BUG").
>> >
>> > I am leaning toward including the former in the upcoming release,
>> > whose -rc0 is tentatively scheduled to happen on Apr 20th.  I think
>> > the rest of the system is also ready for the latter (back when we
>> > merged it to 'next' and started cooking, there were still a few
>> > codepaths that triggered its die(), which have been fixed).
>> >
>> > Opinions?
>> 
>> Google has been running with both of these for a while.  Any problems
>> we ran into were already reported and fixed.  I would be all for
>> including them in the next release.
>
> Thanks, I was wondering how much exposure the latter got. It might be a
> good idea to merge it to "master" early in the post-2.13 cycle to get a
> little more exposure (since the point of it is really to flush out
> unusual cases, the more people run it before we make a release the
> better). But I'm also OK if it's merged to master this cycle, as long as
> it's soon-ish. It's much better to flush out problems in pre-release
> master than in a released version.

OK, let's do both during this cycle, before I take a short break at
the beginning of next month.

Thanks.

Re: [RFC] should these two topics graduate to 'master' soon?

[Jon Loeliger]

So, like, Junio C Hamano said:
> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports.  The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the cycle.
> 
> * jc/merge-drop-old-syntax (2015-04-29) 1 commit
> 
> 
> * jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
> 
> Opinions?

While I have no technical data on these issues, I think
they should go in.

jdl

Re: [RFC] should these two topics graduate to 'master' soon?

[Jeff King]

On Tue, Mar 28, 2017 at 11:51:49AM -0700, Jonathan Nieder wrote:

> > * jc/merge-drop-old-syntax (2015-04-29) 1 commit
> >
> >   This topic stops "git merge  HEAD " syntax that
> >   has been deprecated since October 2007 (and we have issued a
> >   warning message since around v2.5.0 when the ancient syntax was
> >   used).
> >
> > * jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
> >
> >   This is the endgame of the topic to avoid blindly falling back to
> >   ".git" when the setup sequence said we are _not_ in Git repository.
> >   A corner case that happens to work right now may be broken by a call
> >   to die("BUG").
> >
> > I am leaning toward including the former in the upcoming release,
> > whose -rc0 is tentatively scheduled to happen on Apr 20th.  I think
> > the rest of the system is also ready for the latter (back when we
> > merged it to 'next' and started cooking, there were still a few
> > codepaths that triggered its die(), which have been fixed).
> >
> > Opinions?
> 
> Google has been running with both of these for a while.  Any problems
> we ran into were already reported and fixed.  I would be all for
> including them in the next release.

Thanks, I was wondering how much exposure the latter got. It might be a
good idea to merge it to "master" early in the post-2.13 cycle to get a
little more exposure (since the point of it is really to flush out
unusual cases, the more people run it before we make a release the
better). But I'm also OK if it's merged to master this cycle, as long as
it's soon-ish. It's much better to flush out problems in pre-release
master than in a released version.

-Peff

Re: [RFC] should these two topics graduate to 'master' soon?

[Stefan Beller]

On Tue, Mar 28, 2017 at 11:35 AM, Junio C Hamano  wrote:
> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports.  The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the cycle.
>
> * jc/merge-drop-old-syntax (2015-04-29) 1 commit
>
>   This topic stops "git merge  HEAD " syntax that
>   has been deprecated since October 2007 (and we have issued a
>   warning message since around v2.5.0 when the ancient syntax was
>   used).

git-gui has:
82fbd8a (git-gui: maintain backwards compatibility for merge syntax, 2016-10-04)
which was the only blocker IIUC.
So this looks good to me.

>
> * jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
>
>   This is the endgame of the topic to avoid blindly falling back to
>   ".git" when the setup sequence said we are _not_ in Git repository.
>   A corner case that happens to work right now may be broken by a call
>   to die("BUG").
>
> I am leaning toward including the former in the upcoming release,
> whose -rc0 is tentatively scheduled to happen on Apr 20th.  I think
> the rest of the system is also ready for the latter (back when we
> merged it to 'next' and started cooking, there were still a few
> codepaths that triggered its die(), which have been fixed).

Just read through the commit messages of that branch and they
look reasonable, but I refrain from having an opinion here.

Thanks,
Stefan

Re: [RFC] should these two topics graduate to 'master' soon?

[Jonathan Nieder]

Hi Junio,

Junio C Hamano wrote:

> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports.  The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the cycle.
>
> * jc/merge-drop-old-syntax (2015-04-29) 1 commit
>
>   This topic stops "git merge  HEAD " syntax that
>   has been deprecated since October 2007 (and we have issued a
>   warning message since around v2.5.0 when the ancient syntax was
>   used).
>
> * jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
>
>   This is the endgame of the topic to avoid blindly falling back to
>   ".git" when the setup sequence said we are _not_ in Git repository.
>   A corner case that happens to work right now may be broken by a call
>   to die("BUG").
>
> I am leaning toward including the former in the upcoming release,
> whose -rc0 is tentatively scheduled to happen on Apr 20th.  I think
> the rest of the system is also ready for the latter (back when we
> merged it to 'next' and started cooking, there were still a few
> codepaths that triggered its die(), which have been fixed).
>
> Opinions?

Google has been running with both of these for a while.  Any problems
we ran into were already reported and fixed.  I would be all for
including them in the next release.

Thanks and hope that helps,
Jonathan

[RFC] should these two topics graduate to 'master' soon?

[Junio C Hamano]

There are two topics that are marked as "Will cook in 'next'" for
practically forever in the "What's cooking" reports.  The world may
have become ready for one or both of them, in which case we should
do the merge not too late in the cycle.

* jc/merge-drop-old-syntax (2015-04-29) 1 commit

  This topic stops "git merge  HEAD " syntax that
  has been deprecated since October 2007 (and we have issued a
  warning message since around v2.5.0 when the ancient syntax was
  used).

* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit

  This is the endgame of the topic to avoid blindly falling back to
  ".git" when the setup sequence said we are _not_ in Git repository.
  A corner case that happens to work right now may be broken by a call
  to die("BUG").

I am leaning toward including the former in the upcoming release,
whose -rc0 is tentatively scheduled to happen on Apr 20th.  I think
the rest of the system is also ready for the latter (back when we
merged it to 'next' and started cooking, there were still a few
codepaths that triggered its die(), which have been fixed).

Opinions?