Ekaitz Zarraga 👹
Now I realized I need to write a version control system from scratch, too, because Git is too complex for my taste.
My computing setup needs something better.
I'm reading a little bit about diffing algorithms and all that. Interesting stuff, probably too hard for me.
Janneke
@ekaitz_zarraga @cnx
In your case of a long lived feature branch with a complete rewrite of the core evaluator and more, I think I would opt for a collapse into about a handful of commits.
When working on a long lived feature branch, I tend to try to get a feel for: harmless cleanups, orthogonal additions/new features that don't harm the old code, and destructive rewrites and try to rewrite and reorder my branch early and often. Trying to push as many small commits down any destructive rewrites that I can. Only on the first few I write ChangeLog style commits. The work in progress rewrite is often many 'wip' commits, often only mentioning the idea or command to run it and it's status.
Ekaitz Zarraga 👹
@cnx I'm not sure if that's really incompatible with socially large projects.
Where's the issue, really?
I think most of the trouble here is some projects want all the commits to run and pass tests (why?) and to be perfect. Perfection is impossible, so that requires overwriting commits, specially during iterative steps... I don't like that. I also don't love squashing branches to just one commit.
Ekaitz Zarraga 👹
@cnx Take my work in Mes now as an example. I have like more than a hundred of commits. I basically rewrite almost every corner of the evaluator.
Should I fake the process and make all of them pass the tests if doing that is going to "forget" the actual struggle and its implications?
Should I add a changelog style commit message that basically lists hundreds of functions?
Rebasing and preparing everything will surely break things, as conflict resolution is not magic... IDK
cc @janneke
MortSinyx
Yea @ekaitz_zarraga, immutable changes can be incompatible with socially large projects, and personally I'm still adjusting to accept that (mostly on the side of no more "perfect" commit), hence the maybe. I'm going hard on it simply due to sysadmin needs (light, very few and also light dependencies, builtin captcha, tickets and forum). Cc: @suetanvil & @futurile
Ekaitz Zarraga 👹
@cnx @suetanvil @futurile Sure, yeah! I researched fossil in the past. I don't know if I like the no-rebase approach where the changes are immutable, but it's also very interesting. It goes the other way around, right?
Pijul and Darcs are designed for re-ordering and fossil for quite the opposite.
Ekaitz Zarraga 👹
@futurile @suetanvil I don't dislike the ux of git, but I dislike how they continue to add new commands all day and some of the weird decisions they are moving towards.
Also monorepo support, submodules and all that are things I don't need and I think make the whole thing too complicated.
I've been researching darcs and pijul, specially the second. They are truly interesting.
The changes are understood as commutative operations, and everything is built from there.
MortSinyx
@ekaitz_zarraga, see also Fossil, maybe. Cc: @futurile & @suetanvil
Ekaitz Zarraga 👹
@suetanvil yeah, but that means having git, that wouldn't remove any dependency or make the software simpler in any way.
futurile
@ekaitz_zarraga @suetanvil True, if you want to write your own storage/db layer for version control. But the nice thing about #jujutsu for me is that it's using Git as the backend. That means I can collaborate with others without having to use the terrible ux of #git
![Chris [list of emoji]](https://gnusocial.jp/avatar/76364-48-20230220155936.webp){kind=small}
Chris [list of emoji]
You could probably get pretty far by building on top of git's plumbing layers. AIUI, jj (https://github.com/jj-vcs/jj) already works this way.
(Of course, if you want to write a vcs for its own sake, cool!)
Janneke
@ekaitz_zarraga @cnx
Just to be clear: My way of handling long lived feature branches is not dictated by Git. I worked like this even before I started using CVS, when we were creating tarballs with patch level versions and exchanging diffs between them by modem.
Got just made rewriting and reordering history a lot easier.
I want all my commits to pass all tests, I want a linear history and don't ever use merges, so that bisecting always gives the smallest possible change to look at.
I cannot imagine how that would ever work using non-collapsed squash! or fixup! commits.
Ekaitz Zarraga 👹
@janneke @cnx Being more organized would help here, but I don't want the politics of a project or the tool that I use (git in this case) to dictate how should I work.
I prefer to let the fixes come first and adapt the policy and the tool to support that.
(Now I'm not saying we should change the tool in Mes or the policy, I think it is fine. I'm just trying to think about a different paradigm of something that would fit my brain better)
Ekaitz Zarraga 👹
@janneke @cnx From the top of my head, for example a tool like fossil where the commits are immutable, could keep track the fixups and, regardless if they are mixed with other dependent commits in between, could allow for querying a fixup history for one commit and understand it in context...
That could be an interesting way to logically organize the changes, but in the query, and not when the change is introduced.
Ekaitz Zarraga 👹
@janneke @cnx I like the approach but in a way that would destroy the process of reaching the conclusions I reached. In some commits, it's interesting, others are just silly fixes. But yeah, it's a reasonable balance.
About the commits, it's probably me that I'm that kind of "all over the place" programmers that touch too many things at the same time and when I make the commits I sometimes have interleaved things that are then hard to reorder for squashing...
Janneke
@ekaitz_zarraga
Han-wen and I evaluted darcs around 2008 and arch/tla before that before settling on git. At that time, darcs was unusable for a project like LilyPond.
Sure, it would flag conflicts that git just brushes over, but that didn't really help. Also, it would eventually grind to a halt.
Ekaitz Zarraga 👹
@janneke did you try pijul or darcs? those are supposed to work with independent patches way easier!
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.