latest git version no longer detected by base

grey artkiver at gmail.com
Fri Apr 22 22:15:54 UTC 2022


I realize I am late chiming in on this thread, and this is, without
a doubt, almost entirely tangential. However, I created a preliminary
Portfile for got-portable (got [Gameoftrees] is a BSD licensed, git
compatible tool aiming for something similar to be a drop in
replacement for git, though it is currently still very much a work in
progress from some OpenBSD developers, not entirely dissimilar to for
example, openrsync as an rsync replacement/alternative.).

At the moment, I've only opened a Trac ticket, rather than submitted a
PR, as I am not entirely sure what the process is to submit a new
MacPort for approval even after having read and followed
https://guide.macports.org/chunked/development.creating-portfile.html.

The Trac ticket, with an attached Portfile for got-portable may be found here:
  https://trac.macports.org/ticket/65059

Note that in its present state it is probably not likely to be useful
for replacing git in every conceivable workflow, but if you wanted to
help test the Portfile and see if it might be useful in a situation
where you had previously used git, or at the very least if it seems
worth submitting as a MacPort, additional eyes and testing would be
appreciated!

To wit, though also tangential to the origins of the thread, FreeBSD
uses gitup (https://github.com/johnmehr/gitup) in base, which is sort
of similar to FreeBSD's earlier tools svnlite and csup (for Subversion
and CVS respectively) but as far as I know, gitup is intended more for
syncing from repositories rather than committing to them. In contrast,
I believe (though I may be mistaken) that got (GameOfTrees) has an
intention to be a more fully fledged git alternative (in ways that
perhaps fossil-scm's git compatibility failed to deliver on its
promise)? Nonetheless, it would probably be nice to have a MacPort of
FreeBSD's gitup as well, though last I checked, FreeBSD's gitup had a
name collision with this gitup, which is very different, but already
has a MacPort: https://ports.macports.org/port/GitUp/ Suffice to say,
that I tend to be a bit more familiar with OpenBSD's code branches
despite years of also running FreeBSD in production environments as
well, so for a first effort, got seemed as if it was something easier
for me to cut my teeth on with regards to submitting a Portfile for a
new port.

My apologies for adding any distractions to discourse related to the
mainline git client in this thread.



On Sun, Apr 17, 2022 at 2:16 AM Herby G <herby.gillot at gmail.com> wrote:
>
> As I mentioned in my original comment on the commit, the big change in Git 2.35.3 (and starting in 2.35.2) is a major behavior change to address CVE-2022-24765
>
> What this means in practice is that Git will no longer operate on or process any higher level Git directories with different ownership.
>
> As I had mentioned to Ken earlier on in this list, you can try setting the safe.directory configuration value to disable this behavior as mentioned in the above post: https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory
>
> It looks like it should be safe.directory = * in the master git configuration file, though I have not tried that myself.
>
>
> On Sat, Apr 16, 2022 at 11:13 AM Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>
>>
>>
>> On 14 Apr 2022, at 11:16 pm, Joshua Root <jmr at macports.org> wrote:
>>
>> On 2022-4-14 23:56 , Christopher Jones wrote:
>>
>> Hi All,
>>
>> Does anyone have any ideas on
>>
>> https://github.com/macports/macports-ports/commit/053dbb666a57972ceefba10b1edd12f16d886fd4#commitcomment-71271508 <https://github.com/macports/macports-ports/commit/053dbb666a57972ceefba10b1edd12f16d886fd4#commitcomment-71271508>
>>
>> something about the latest git port is causing it to no longer to properly detected and used by base..
>>
>>
>> The git used by port sync is whatever is found by macports::findBinary: <https://github.com/macports/macports-base/blob/v2.7.2/src/macports1.0/macports.tcl#L2603>
>>
>> And that ends up calling binaryInPath, which simply looks for an executable file of the given name in each directory in PATH: <https://github.com/macports/macports-base/blob/v2.7.2/src/macports1.0/macports.tcl#L407>
>>
>> FWIW, my syncs still use /opt/local/bin/git after upgrading.
>>
>>
>> What OS is this ? For me the issue is happening on macOS 12.
>>
>> The problem is completely reproducible. I can uninstall macports git and it starts working again with the system binary, and then reinstall macports version and it stops working again..
>>
>> I think at some point I will have to probably just put some more verbose debug into base, to try and help figure out what exactly is happening there to cause it to fail to use macports git correctly.. my suspicion is its something to do with the checks performed at
>>
>> https://github.com/macports/macports-base/blob/5d637741b5ae04b63f7e99a9057c6764d29fd7fd/src/macports1.0/macports.tcl#L2613
>>
>> That are no longer working correctly for some reason, leading to a null string being returned, which is the behaviour I see.
>>
>> Chris
>>
>>
>>
>> - Josh


More information about the macports-dev mailing list