1. Forum
  2. Usenet
  3. COMP.SYS.TANDEM

  • ITUGLB Update: Git 2.39.0 and 2.38.2 available

    From Randall@21:1/5 to All on Wed Dec 14 00:06:39 2022
    Hi Everyone,

    A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

    2.38.2 is a back-port of fixes through 2.39.0.

    Regards,
    Randall Becker
    On Behalf of the ITUGLIB Technical Committee

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to Randall on Wed Dec 28 06:28:19 2022
    On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:
    Hi Everyone,

    A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

    2.38.2 is a back-port of fixes through 2.39.0.

    Regards,
    Randall Becker
    On Behalf of the ITUGLIB Technical Committee

    I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0 appears
    to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would
    otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

    Regards.
    Randall

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to Randall on Wed Dec 28 06:47:51 2022
    On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:
    On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:
    Hi Everyone,

    A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

    2.38.2 is a back-port of fixes through 2.39.0.

    Regards,
    Randall Becker
    On Behalf of the ITUGLIB Technical Committee
    I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0
    appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would
    otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

    Regards.
    Randall

    Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report back.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to Randall on Fri Dec 30 14:57:41 2022
    On Wednesday, December 28, 2022 at 9:47:52 a.m. UTC-5, Randall wrote:
    On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:
    On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:
    Hi Everyone,

    A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

    2.38.2 is a back-port of fixes through 2.39.0.

    Regards,
    Randall Becker
    On Behalf of the ITUGLIB Technical Committee
    I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0
    appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would
    otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

    Regards.
    Randall
    Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report back.

    No root cause has yet been identified - not for lack of trying. As soon as I hear anything, I will post news. The key point is that if you are a submodule user, your upstream needs to be remote not local. If you are purely remote, you will not be
    impacted. Otherwise, you will need to revert to 2.36.0 or earlier. Do not use 2.36.1 or newer as those have the change that causes this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to Randall on Fri Dec 30 15:20:59 2022
    On Friday, December 30, 2022 at 5:57:42 p.m. UTC-5, Randall wrote:
    On Wednesday, December 28, 2022 at 9:47:52 a.m. UTC-5, Randall wrote:
    On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:
    On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:
    Hi Everyone,

    A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

    2.38.2 is a back-port of fixes through 2.39.0.

    Regards,
    Randall Becker
    On Behalf of the ITUGLIB Technical Committee
    I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0
    appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would
    otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

    Regards.
    Randall
    Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report
    back.
    No root cause has yet been identified - not for lack of trying. As soon as I hear anything, I will post news. The key point is that if you are a submodule user, your upstream needs to be remote not local. If you are purely remote, you will not be
    impacted. Otherwise, you will need to revert to 2.36.0 or earlier. Do not use 2.36.1 or newer as those have the change that causes this.

    I think I have found the root cause. 2.39.0 appears fine if you avoid using the 'git remote add origin ../path' command. When I used a simple clone, the origin was set up correctly and the submodule add works correctly. You do need to configure the
    protocol.file.allow=always variable if you are using local submodules - this was added as a security measure. So no revert is required unless you use the git remote add command with relative paths. Glad that is figured out.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)