Drop `git flow`, or at least `getopt.exe` from MinGit

[dscho]

During a discussion about MinGit's MSYS contents today, I noticed that /usr/bin/getopt.exe from util-linux is included in MinGit. My follow-up investigation led to git-for-windows/build-extra@920c19b which explains that this is needed for git flow.

Seeing as there is a growing amount of evidence that not only is Git Flow over-engineered, but also that the original inventor is totally disinterested in maintaining it, even other volunteers who tried to maintain this over the years seem to have given up.

So let's drop git flow.

Or, if there is too much backlash against that, let's at least ensure that getopt.exe is no longer included in MinGit lest random users try to employ Hyrum's Law and force Git for Windows to bundle this totally unneeded executable forever.

[bmcdonnell-fb]

Dropping git flow in v2.51.1.windows.1 unexpectedly broke our release workflow. (I don't believe there was a deprecation period?)

Can you please restore it (or gitflow-avh), at least until git-flow-next has a stable release?

[bmcdonnell-fb]

Related: #5901

[dscho]

Dropping git flow in v2.51.1.windows.1 unexpectedly broke our release workflow. (I don't believe there was a deprecation period?)

You're right, there hasn't been any deprecation notice in the release notes.

I mistook the silence about git flow on this bug tracker as silent agreement.

Can you please restore it (or gitflow-avh), at least until git-flow-next has a stable release?

I cannot in good conscience restore gitflow-avh because it is unmaintained, and I cannot include git-flow-next because of the dramatic increase in size (combined with the fact that git flow is not a widely used Git add-on, and therefore it would be unfair to burden the millions of Git for Windows users with the added payload when they do not need it).

The best I can do is to adapt the release workflow to install both Git for Windows and git-flow-next.

[bmcdonnell-fb]

I'm working around the issue by downgrading to 2.51.0.windows.2.. I may try gitflow-cjs, as you suggested on #5395 (comment).

I cannot include git-flow-next

To be clear, I wasn't asking for this. I was only asking that you consider a temporary reversion of the removal, until the suggested replacement has a stable release (whether you include it or not).

The best I can do is to adapt the release workflow to install both Git for Windows and git-flow-next.

Once git-flow-next is stable, I'd welcome this if there is sufficient demand, but IDK if there is.

In any case, thanks for your past and ongoing work on Git for Windows. :)

[FHannes]

@dscho Are you planning to move forward with adapting the release workflow? I understand that keeping git flow in adds additional burden, but for Windows so far I have not found a practical way of distributing it outside of the git package. Without a prior deprecation notice, this has seriously caught us off-guard and now we have to scramble to ensure our teams don't run into issues. While I have no issue with git-flow-next being included in some way or it being an early release, it too does not seem to provide a very practical distribution mechanism and from my testing it also does not seem to be fully backwards compatible yet. Backwards compatibility seems to be an open ticket.

[dscho]

Are you planning to move forward with adapting the release workflow?

No. Git Flow is unsupported by its own author, and Git for Windows cannot take over that support.

I understand that keeping git flow in adds additional burden,

Oh, it's no longer "in". It's out. It would create a substantial burden to get it back in.

but for Windows so far I have not found a practical way of distributing it outside of the git package.

If you must, you can download the git-flow package from https://github.com/git-for-windows/pacman-repo/tree/d4e2da4a5fa47694e15d626e5682a6c336294fa4^, then make a Git installer after adding it to the packages in make-file-list.sh. That way, you can make a Git package that includes Git Flow (and you maintain that).

While I have no issue with git-flow-next being included in some way

There is absolutely no plan from my side to carry git-flow-next in Git for Windows, ever.

[FHannes]

@dscho Thank you for the quick answer, I can work with that. I mean no offense or disrespect for your excellent work on this project. Going by the release notes and your communication around this issue, it seems to be a sensitive topic. I am just evaluating our options to move forward.

[joerghampel]

Just for statistics (as I can see that ship has sailed), here's one more +1 for not liking the removal of Git Flow.

We are using Git Flow for all our work, and having it removed from Git for Windows - and also on such notice - is a huge PITA. I do understand the reasons and arguments, and I'm confident we can work around this internally, but it probably poses an unsurmountable hurdle to many of our customers to have their IT departments fix this for them.