Johannes Sixt writes:
>>> Like this (generated using "git revert -m1)?
>>
>> OK. Thanks for taking care of it.
>
> Please don't forget to remove the corresponding release notes entry.
Thanks for a reminder. Very much appreciated.
> >> Like this (generated using "git revert -m1)?
> >
> > OK. Thanks for taking care of it.
Yes that looks good to me, thanks!
>
> Please don't forget to remove the corresponding release notes entry.
Makes sense, too.
Thanks,
Stefan
Am 08.09.2018 um 04:04 schrieb Junio C Hamano:
> Jonathan Nieder writes:
>
>> It is late in the release cycle, so revert the whole 3-patch series.
>> We can try again later for 2.20.
>>
>> Reported-by: Allan Sandfeld Jensen
>> Helped-by: Stefan Beller
>> Signed-off-by: Jonathan Nieder
>> ---
Jonathan Nieder writes:
> It is late in the release cycle, so revert the whole 3-patch series.
> We can try again later for 2.20.
>
> Reported-by: Allan Sandfeld Jensen
> Helped-by: Stefan Beller
> Signed-off-by: Jonathan Nieder
> ---
> Stefan Beller wrote:
>> Jonathan Nieder wrote:
>
>>> I
Subject: Revert "Merge branch 'sb/submodule-core-worktree'"
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing
changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598.
v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after
update, 2018-06-18) assumes an
I think we
> should revert e98317508c0 in "master" (for 2.19) and keep making use
> of that 'second try' in "next" (for 2.20).
Actually I'd rather revert the whole topic leading up to
7e25437d35a (Merge branch 'sb/submodule-core-worktree', 2018-07-18)
as the last patch in there doesn't work well
On Freitag, 7. September 2018 19:08:43 CEST Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
wrote:
> > Submodules checked out with older versions of git not longer works in the
> > latest 2.19 releases. A "git submodule update --recursive" command wil
> > fail
> > for
Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
> wrote:
>> Submodules checked out with older versions of git not longer works in the
>> latest 2.19 releases. A "git submodule update --recursive" command wil fail
>> for each submodule with a line saying "fatal: could
Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
> wrote:
>> A "git submodule update --recursive" command wil fail
>> for each submodule with a line saying "fatal: could not open
>> '/.git' for writing> Is a directory.
[...]
> I have the
Hi,
Allan Sandfeld Jensen wrote:
> I discovered it by using Debian testing, and it is shipping the 2.17rcs for
> some reason.
I believe you mean Debian unstable. Debian testing has 2.18.0.
> The example is just an old checkout of qt5.git with submodules,
> it is rather large.
On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen wrote:
>
> Submodules checked out with older versions of git not longer works in the
> latest 2.19 releases. A "git submodule update --recursive" command wil fail
> for each submodule with a line saying "fatal: could not open
> '/.git' for
On Freitag, 7. September 2018 17:03:27 CEST Jeff King wrote:
> On Fri, Sep 07, 2018 at 11:52:58AM +0200, Allan Sandfeld Jensen wrote:
> > Submodules checked out with older versions of git not longer works in the
> > latest 2.19 releases. A "git submodule update --recursive" command wil
> > fail
>
On Fri, Sep 07, 2018 at 11:52:58AM +0200, Allan Sandfeld Jensen wrote:
> Submodules checked out with older versions of git not longer works in the
> latest 2.19 releases. A "git submodule update --recursive" command wil fail
> for each submodule with a line saying "fatal: could not open
>
Submodules checked out with older versions of git not longer works in the
latest 2.19 releases. A "git submodule update --recursive" command wil fail
for each submodule with a line saying "fatal: could not open
'/.git' for writing> Is a directory.
I checked the release notes so far, and they
14 matches
Mail list logo
