Question about git 2.10

[alvaro burnett]

Hi everyone,

I use Git 2.10 and my question is: Is there any risk of corrupting repos created by other people who use newer versions of Git? In other words, has the Git repo format changed since version 2.10?

[Johannes Schindelin]

Hi Alvaro,

Git is designed to be backwards-compatible. That is, you can access and
work with repositories initialized by old Git versions.

There are occasionally new features in newer Git versions that might make
it impossible to interact with both old and new Git versions on the same
local git directory, once enabled (for example, if you enable MIDX using a
newer Git version and then initialize that data structure, then work on
the worktree using an older Git version that does not know about MIDX,
using a new Git version afterwards might get it confused about missing
MIDX updates).

Typically, such features are opt-in, though, so if you know that you use
ancient versions (such as Git v2.10), you simply don't enable those
features.

In any case, this is not actually a Windows-specific question and would
therefore be much better discussed on the Git mailing list (for details,
see https://git-scm.com/community).

Ciao,
Johannes

[alvaro burnett]

Thanks Johannes,

I was worried that I might corrupt something silently.

The reason that I asked it here is because I would be happy to do all the work of restoring XP support, and I have whatever time is necessary. The problem is that I don't know how. I would need some guidance.

[Konstantin Khomoutov]

On Sun, Nov 12, 2023 at 02:32:05AM -0800, alvaro burnett wrote:

> I was worried that I might corrupt something silently.
>
> The reason that I asked it here is because I would be happy to do all the
> work of restoring XP support, and I have whatever time is necessary. The
> problem is that I don't know how. I would need some guidance.

I'm not a GfW developer/maintainer (contrary to, say, Johannes), but I would
propose that your endaevor might be unfortunately doomed: while it probably
should be possible to somehow bring Windows-specific code of Git itself into a
shape enabling it working on XP, and maintaining it to have this property,
you should be well aware of the fact Git-for-Windows still heavily relies on
MSYS2 to be useful, and this project is phasing out support for Windows 7
and below, and for 32-bit builds as well - see [1]. Hence, basically, you will
need to not ony maintain the necessary changes in GfW itself, but also in
that platform as well, and its maintainers might be not interested in the
support for a dead platform and might be unwilling to have it in the mailine
even if someone would propose the necessary patches and ongoing support.

All-in-all, I would probably just let that platform rest in peace.
If you _need_ Git support there (I would understand that you might be
maintaining some piece of software written for XP, and so you might need
to keep that piece live sort of forever), I would concentrate on verifying
that the last version of GfW reliably working for you on XP is still
compatible *on the network protocol level* with contemporary versions of Git -
so that your old "last known-good" version can still communicate with the
repositories operated by newer Git versions. Probably this also should include
the format of the so-called "bundles" operated by the `git bundle` command
(and `git fetch` etc) as they can be used to make your old Git exchange
commits with newer Git versions.

If you feel like exploring that route, make sure you can read from and post
to the main Git list [2] since the one we're having our conversation on
is not suitable for questions regarding version interoperability.

1. https://github.com/git-for-windows/build-extra/blob/main/ReleaseNotes.md#changes-since-git-for-windows-v2420-august-21st-2023
2. https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list

[Johannes Schindelin]

Hi alvaro,

you definitely do not have whatever time is necessary to restore XP
support. The main problem is not even in Git's source code, but the fact
that Git requires a POSIX shell to work, and for that we use the MSYS2
runtime which is a close derivative of the Cygwin runtime. And _that_
runtime has stopped supporting Windows XP a looooong time ago and did not
exactly dilly dally with introducing new features afterwards.

Here are just some commits that would need to be reverted:

https://github.com/cygwin/cygwin/commit/e426213a88e060ae3d739a8d9fe2f3e7e0432e43
https://github.com/cygwin/cygwin/commit/fa6a5a3a74cb822900111319c39a6a4793e4b588
https://github.com/cygwin/cygwin/commit/b47a67e4932840ca6ce7f54147c57df35f25f848
https://github.com/cygwin/cygwin/commit/238c2b14ca3cd7cc785e67846cce63380b4679ae

And that's just the tip of the iceberg.

After that, newer commits' changes would have to be adjusted to support
XP, or new flags would have to be introduced to selectively revert at
runtime what has been introduced if XP has no equivalent support (think
e.g. pseudo consoles).

No, that ship has sailed. There's no bringing back Windows XP support to
Git for Windows, even if you have several years of free time.

Ciao,
Johannes

> --
> You received this message because you are subscribed to the Google Groups "git-for-windows" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/5d70aee9-2df6-4bd2-a7ce-c43f62dfd6dbn%40googlegroups.com.
>

[alvaro burnett]

Well it's sad to see Git for Windows married to whatever the MSYS guys decide. I'm surprised to hear that they are breaking compatibility not only with Windows 7 but also with everything 32-bit. Funny to see open source embracing the planned obsolescence agenda pushed by the big tech. I guess I will continue using Git 2.10 for as long as possible and then switch to something that doesn't depend on MSYS.

[Konstantin Khomoutov]

On Mon, Nov 13, 2023 at 05:32:59AM -0800, alvaro burnett wrote:

> Well it's sad to see Git for Windows married to whatever the MSYS guys
> decide. I'm surprised to hear that they are breaking compatibility not only
> with Windows 7 but also with everything 32-bit. Funny to see open source
> embracing the planned obsolescence agenda pushed by the big tech. I guess I
> will continue using Git 2.10 for as long as possible and then switch to
> something that doesn't depend on MSYS.

I think you might be missing the main point of phasing out support for
whatever platforms get obsoleted by their vendors. It's not just some sort of
"blind obedience", it's mere lack of manpower and lack of other resources -
such as H/W to serve as CI, - to support a platform which does not receive
security updates (even for critical exploits), and may stop working on any
new piece of hardware. I once have explained to someone all this in more
detail in a similar case - dropping support for XP from a popular
implementation of the Go programming language; you might find it interesting
to read [1].

Basically, GfW could in theory "do something" to still support XP, but
consider that it would amount to forking MSYS2 or rewriting at least parts
of GNU Bash (and Perl) to not depend on MSYS2. While doable, there's the
unavoidable question of who is to do it, and who will be responsible for
ongoing support of the result etc. It's not an easy question to answer.

(Please don't perceive the above text as a sort of personal attack; I've been
in your boots.)

1. https://stackoverflow.com/a/52137703/720999

[alvaro burnett]

Perhaps the solution to that is simply to write your software in a way that doesn't depend on bandwagonist third parties such as MSYS, which is what Fossil does. You can download the latest version and it will run on Windows XP and newer.

[Konstantin Khomoutov]

On Mon, Nov 13, 2023 at 08:14:03AM -0800, alvaro burnett wrote:

> Perhaps the solution to that is simply to write your software in a way that
> doesn't depend on bandwagonist third parties such as MSYS, which is what
> Fossil does. You can download the latest version and it will run on Windows
> XP and newer.

You are comparing apples to oranges here because Git and Fossil have very
different tracks of their initial development.

Fossil for a long time was a one-man project (as did SQLite, by the same
author) completely written in pure C, with an explicit goal of producing an
(almost) free-standing (self-sufficient) binary eligible for so-called x-copy
deployment. The Fossil's author does not do Windows, and neither he's
interested in it, but the fact SQLite is pure C, and so it Fossil has greatly
simplified porting to Windows. It's interesting to note that SQLite, thanks to
its longevity and ubiquitousness, had already contained a set of
Windows-specific kludges which helped Fossil.

Conversely, Git has started life as a gig of the original author of Linux,
with the specific goal of helping the development of Linux, on Linux.
Basically, the whole reason was to replace Bitkeeper which had suddenly became
unusable for the Linux developers, with no viable existing alternative. While
not in any way required, typical environments powered by Linux and used by
people to develop software feature a typical UNIX-y software stack - for
instance, a Unix-compatible shell, Perl and so on are taken for granted. This
is the first point to note: support for a non-Unix platform was not a goal for
a long time during the original development of Git. The second point is that
Git had two-layered Unix-y design right from the start: there's a set of
low-level core tools written in C, and a set of high-level user-facing tools
wielding the low-level ones to do heavy lifting. The upper layer tools were
routinely coded as shell and Perl scripts - simply because it was easier and
faster and provided fast code-experiment-change cycle. Given that, by the time
Git gained enough traction so there appeared interest in making it work on
Windows, there were just too much code which had to be either rewritten
completely in order to work on non-Unix-y systems or be made somehow work
there largely unmodified. The folks who started the porting effort (I think
Johannes was there right from the start) took the second route, and started
relying on already existing libraries and tooling which helped to have Unix-y
code compile and work on Windows. What is now known as Git-for-Windows has
been named "msysGit" for precisely the reason explained above.

Being a software developer myself, I would say the approach the GfW devs have
picked was the only correct one, given the situation at the time. You can
surely blame the original Git authors for not thinking about its portability
to non-POSIX platforms but, well, I've tried to explain why they had that
mindset: the initial use case for Git to exist was very narrow; they simply
did not think of world domination, they needed a very fast and reasonably
robust tool to efficiently handle the source code of a gigantic software
project.

Git is slowly being updated to eventually get rid of non-C code for its
core, but it's not there yet.