Re: Git haas gone wild (Rust), freebsd-update

On Sat, Sep 20, 2025 at 17:30:52 +0300, Vadim Goncharov wrote:
> On Tue, 16 Sep 2025 07:22:05 -0400
> Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
...
> > The UI is awful because it is a fairly thin veneer over the underlying
> > object storage.  But it doesn't have to be.  That's my point about people
> > conflating the UI and repo format.  The repo format isn't perfect (e.g.,
> > lack of rename tracking) but it is good enough.  The UI, on the other hand,
> > is *not* good enough.
> 
> No, format is absolutely not "good enough". It is "just minimum to be workable
> at all". For example, they don't have not only "inode-style" (I don't know
> VCSes to use it yet, so it could be considered "advanced") but they can't even
> just upgrade to SHA-256 from SHA-1 - these are incompatible (while e.g. Fossil
> did it seamlessly) at all.

Git's on-disk format is largely (completely?) ok with sha256.  IIRC, tree,
commit, and tag objects can use whatever hash length.  I don't recall the
pack file internals, so I can't comment on that.  The biggest problem (IIUC)
is dealing with the migration from sha1 to sha256 without forcing everyone
to rewrite their sha1 repos with a new hash algo.  There is no 'hash algo'
field in the repo format, but doesn't prevent such things from being done -
it just takes more effort and careful engineering.

> As I've said earlier, commit has no information about what branch it
> belongs to,

That is true, but this (IMO) falls under the category of personal
preference.  Some people like the branch info, some hate it, some don't
care either way.

> it has direct consequence to having "metropolitan railroad map" git logs
> if branches are merged

If commits included branch info, wouldn't merges still look the same?
Mercurial dev use 2 branches: default and stable.  The former is the
'main' branch and stable is the point-release fixups branch.  The resulting
DAG looks like railroad map: https://repo.mercurial-scm.org/hg/graph/tip

> , thus many, many
> projects/companis choose to rebase/squash commits instead - that is, history
> rewriting, which goes AGAINST the whole idea of Version Control (and yes, I've
> many times found myself losing information due to this "squash to one" when
> changing again and again in several tries to satisfy company's CI)
> 
> And Revase Considered Harmful (and history rewriting in general):
> https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

History rewriting *before* a commit is "done" is fine.  See my description
of phases in the email I sent a few minutes ago.

IMO the "fixup commits that get squashed" is not an inevitable consequence
of the repo format - you could do the same thing with svn - but rather a
consequence of poor review & testing tooling.

They have gotten better over the years, but github and similar
services/tools have taught an entire generation of engineers that it is "not
worth it" to create a nice series of commits to push out for review, because
the tooling will require various "fixup" turds and the result will get
squashed into oblivion.

...
> > Anyway, I should stop before I outright start ranting :)
> 
> Why not! Ceterum censeo Git esse delendam!

Because it is off-topic for this mailing list? :)

Jeff.