Remove reference to rtx in README

[ChrisMcD1]

• PR Description

rtx has since been renamed to mise https://mise.jdx.dev/rtx.html and the creator says that it shouldn't be used to manage git. jdx/mise#4694 (comment)

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[ChrisMcD1]

So this of course, begs the question, what should we recommend for managing git versions? I could personally use this advice right now because I'm testing out some code for #4504, and there has been a lot of support for trailers added in more recent versions of git, so I want to make sure that what I write still works on different versions.

Also, unrelated to the concept of this PR, but what are our ongoing rules for supported git versions? I see the list we defined that we are running in our CI is around 2 years old. #2754 Do we have any plans to bump it from 2.22.0, which came out in June 2019? (In particular to my code I'm working in, I want to use git commit --trailer which came out in 2.32.0, from June 2021)

[stefanhaller]

So this of course, begs the question, what should we recommend for managing git versions?

I'm not sure I would recommend it, but here's what I personally do:

• Maintain a bunch of directories of git installations in my home directory, under ~/git-versions/
• To install a new version there, follow these steps:
  • cd <git-repo>
  • git checkout v2.xy.z
  • mkdir ~/git-versions/2.xy.z
  • make -j9 prefix=/Users/stk/git-versions/2.xy.z install
  • (don't use ~ in the make command, this doesn't work for some reason)
• To run tests against a particular version, use
  • PATH=~/git-versions/2.xy.z/bin:$PATH ./scripts/run_integration_tests.sh

Also, unrelated to the concept of this PR, but what are our ongoing rules for supported git versions? I see the list we defined that we are running in our CI is around 2 years old. #2754

The list was last updated four weeks ago (see #4439).

But I can't really answer this question. I would personally be in favor of updating our minimum required version to a much more recent version, to make our lives easier, but @jesseduffield had reasons why he wanted to keep supporting older versions if possible. I'll let him make the call on this.

[jesseduffield]

I'd be happy to go to 2.32 just cos it still spares most people from having to upgrade their git from the OS stock version.

Here's some stock versions from my chat with chatGPT

[stefanhaller]

@jesseduffield You said 2.32, but did you mean 2.31?

[jesseduffield]

I meant 2.32 because that's what @ChrisMcD1 mentioned. Indeed, 2.31 is on RHEL 9, but my understanding is that RHEL is overwhelming used for servers, not personal computers, and that lazygit would rarely be used on servers.

[stefanhaller]

I see, ok.

On that note though, I'm skeptical that using git commit --trailer in lazygit is a good idea, but of course I don't know what @ChrisMcD1's plans are, and this should probably be discussed elsewhere.

[ChrisMcD1]

On that note though, I'm skeptical that using git commit --trailer in lazygit is a good idea, but of course I don't know what @ChrisMcD1's plans are, and this should probably be discussed elsewhere.

Yeah, my ideas aren't fully formed yet either. I'll think some more and come back with a clearer idea.

For this PR, what do we want to recommend people use to manage git versions? I'm just trying to save someone else from going down the 2 hour rabbit hole that ended with me discovered the maintainer of rtx plainly saying (with no clarification😅 ) that his tool should not be used for this purpose.

jdx/mise#4694 (comment)

[stefanhaller]

For this PR, what do we want to recommend people use to manage git versions?

No idea to be honest. What I described above works well for me, but I'm not sure we want to document it; and I'm not aware of any tools that make this easy, but I also haven't looked for them. 😉