gitx: switch to maintained fork

[miccal]

Homebrew/discussions#4250

#89655

[carlocab]

Same questions/concerns as #89655.

This is a fork of a fork, and not even particularly popular. I don’t see any indication this is official or officially recommended by the original, so it cannot take over the name of the original.

is there any indication from the original developers of GitX that this is now considered the "official" version?

[hannesa2]

@carlocab
gitx is no more a fork, and several people take care for years now in an own organization.
The origin is since 14 years dead and for the same time, there is no response anymore.
The fork from the origin is since 9 years dead and for the same time, there is no response anymore.

[appden]

Not only is gitx/gitx the only actively maintained fork, it's the only one that includes important fixes to work properly on Apple Silicon Macs.

[bevanjkay]

The point being made here is that if we update the cask to point to the new fork, then existing users will receive upgrades to the package that a different vendor now develops. Which is not a great experience for users, unless they are specifically intending to receive this change.

Generally when a project is forked and becomes popular, (where appropriate) we would add a new cask with the vendor name as a suffix on the cask token. In this case that wouldn't be possible as the token would become gitx-gitx which is confusing.

[appden]

Thanks for the reply @bevanjkay. That's a very reasonable concern. I still think it's too bad to leave users on such an old version with many bugs that have since been fixed. It seems like the best course then could be a new cask with a name like gitx-official, gitx-modern, or whatever else makes sense unless you can get blessing from the original developer.

[p-linnane]

We can go about this in 2 different ways.

1. We can have an exemption to our normal policy and allow this fork to become the new source.

• Pro: This would be beneficial since there are over 200 downloads in the last 90 days.
• Con: This is not designated by the original upstream as the successor to the project.

2. We can deprecate this cask, and create a new one under a different name.

• Pro: This would conform with our existing policy, and keep things cleaner. Users would understand this is a deliberate change to a different source.
• Con: Will cause confusion since the only gitx cask would have a different name. We would also need to find a suitable name.

I am not one for deviating from normal policy, but I understand the needs of the community here. I think it would be wise to ask for a review from members of our Technical Steering Committee to help us make a final determination.

[p-linnane]

Ping @Homebrew/tsc since I can't request an actual review for some reason.

[miccal]

Reading the four links I provided above, I vote for option 1.

1. We can have an exemption to our normal policy and allow this fork to become the new source.

[p-linnane]

I am also leaning towards option 1 due to the benefits to the community and length of time upstream has been dead according to @hannesa2. I will wait to see what the TSC thinks though.

[iMichka]

Option 1 looks good. I think it’s not the first time we do this: at least we did that kind of thing in homebrew-core a few times and no-one has complained.

The important thing to maybe check if there was a license change, but I guess there was none, so we should be good on that side.

And if someone wants the legacy gitx back, we can still add a gitx-legacy package later on.

[MikeMcQuaid]

at least we did that kind of thing in homebrew-core a few times and no-one has complained.

We actually never do this (or at least never should) without the original author "blessing" the fork.

In this case, though, the gitx/gitx repository makes it look a lot more maintained than the original and "forks" are a bit different for Casks when we're shipping binaries anyway.

All that to say: I'm 👍🏻 in this case of landing this PR as-is.