On Tue, Dec 23, 2025 at 11:36:43AM -0600, Constantine A. Murenin wrote:
> I find it ironic that it's claimed that those who claim that the rename
> issue doesn't exist, "aren't about to publicly change their minds", yet,
> effectively, we still don't even have a single cohesive document which
> expressly addresses all of the questions about this.
Would you like to write one? I agree it would be a nice thing to have.
The trouble is, it takes time and effort. And, as I've already said
several times, this same flamewar has been happening over and over
again for years and years and it's tiring.
I've been on this list for longer than I'm willing to admit, and I think the existence of this mythical Git "flamewar" is far overstated.
To the contrary, it's all been Fossil + Git / GitHub, then, at one point, it's suddenly Mercurial, out of nowhere, without any further explanation. Then anyone who didn't get the mythical memo and who doesn't understand the "why" bit, is given the "Git Advocate" label, with all the questions dismissed.
I'm happy to write a summary, but I don't think you'd be happy with the results, so, I'll pass.
At the end of the day, it simply makes no sense that somehow Mercurial is able to determine, and correctly store, the rename metadata, even with Git used as the front-end, yet Git is somehow fundamentally incapable of doing the same, regardless of the options used.
I think the biggest argument from this thread, on using Git and only Git, without Mercurial, is preservation of the commit hashes/references throughout the history. Which would NOT be possible if we proceed with Mercurial+Git duo, with an immediate plan to switch to something better, too, should something better come along. Because then noone would have any clue what a given hash would refer to. (Unless, of course, everyone votes with their wallet, but then what's the point of using Mercurial again, if all the developers would be using Git anyways?)
[…]
Also, I'm getting yelled at off-list for continuing to respond, so
this is going to be the last post.
I'm not quite sure what the above admission is supposed to mean, but if the decision to use Mercurial is as sound as portrayed, surely it'll withstand the scrutiny, right?
> disable the rename detections
Disabling git's rename support entirely reverts to the status quo of
CVS not supporting rename. That isn't helpful.
Ultimately, the design flaw is that git doesn't store rename metadata,
and you can't really work around it.
But why are the renames so important again? Wouldn't it be better if we get permanent hashes for each commit right away, by using a single VCS, instead of storing (autogenerated) rename metadata, but having the duplicity with the hashes?
How exactly would Mercurial even get the rename metadata if the renames are performed in Git?
> there's also Jujutsu (jj-vcs).
That seems to be a whole different (and newish) tool. (That is, it
seems to be more than just another git porcelain.) I'm not optimistic
because it still seems to be a wrapper around git, and you can't fix
git's fundamental design flaws that way. (Also I'm a little concerned
by the section in the project readme that talks about replication as
if distributed version control doesn't already do that.)
But also, it says it's experimental. It might be interesting to
experiment with. Doesn't look ready to adopt.
(https://github.com/jj-vcs/jj for the curious)
The jj project may be experimental, but it already has 860 forks and 23.8k stars on GitHub, and is basically semi-backed by Google.
> outside experts
Who do you propose as outside experts who would have anything useful
to add? Keep in mind that version control is a storage application,
and NetBSD, being an OS project, has a lot of institutional experience
with storage and a lot of community members with a lot of experience
with storage.
Also, we've had any number of git advocates with no apparent ties to
the NetBSD community walk in and read from the script above.
> tell any Git maintainers about the rename issue
The git maintainers have also had some twenty years to fix their shit.
It's implausible that they don't know about the issue. (It's also
unlikely that they care specifically about any given user considering
it a dealbreaker.) There's also been ample time, in the course of all
the iterations of the argument outlined above, for someone interested
to take it upstream. Since nothing's changed, reasonable explanations
include:
- like the typical git advocate, the git maintainers deny that
there's a problem and won't accept arguments to the contrary;
- the git maintainers recognize that there's a problem but don't
consider it important;
- the git maintainers recognize that there's a problem but it's
unfixable for whatever reason (perhaps compatibility).
> I mean, if simply using a Mercurial backend, already effectively
> disables this feature within git
Anything follows from an invalid premise!
I don't quite think that experts in storage is the same as experts in Git.
It sounds like questions aren't being asked of the outside experts, simply because the answers received may be inconvenient to hear?
I really appreciate your help in finally explaining the reasoning for the choice, but to me, quite a bit of the rationale here, boils down to the Not Invented Here (NIH) syndrome.
Except that, ironically, we actually probably still have more Git experts within our own developer community than the Mercurial experts…
I'd volunteer in engaging the Git community on this matter, but since we don't even have a requirements spec, it sounds like any answers or advice received, would be more or less inconsequential…
C.