What comes after Git • Hacker News Board

Re: What comes after Git

#291

Post by sgbeal » Tue, Jul 05, 2022, 1:56 PM UTC

midenginedcoupe wrote: post #172

maccard wrote: post #157

Earlier quoted context omitted.

> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.

Well that's a different argument. The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

> But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

cough Fossil cough

Re: What comes after Git

#292

Post by SulphurSmell » Tue, Jul 05, 2022, 1:57 PM UTC

Art_Wolf wrote: post #270

SulphurSmell wrote: post #264

I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was amazed at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of "bug fix" or "specia…

One reason we moved off it was because it was a bandwidth hog! I believe they had two clients to try and help with this, a thin and think client. Even with the thin one, with the CC servers hosted in the states and some developers located in Europe, it would take a half hour for the client to refresh and pull down the latest changes.

Interesting. It was never an issue for us, as we were close to the CC servers. Some folks were not, so they ran their dev/build locally ("network close" to th CC servers) and VNC'd in from their actual location. In that case, only the stuff on the screen had to transit the "far away" network. Although, I think today, network issues would be less of a thing...as I tend to think that networks have scaled faster than code base size. I could be horribly wrong about that though. Any centralized repo is going to have this challenge though. It also depends on if you prefer snapshot or dynamic views. Snapshots were much easier on the network, at the expense of consistency. I also remember the CC team could work magic at optimizing things if you gave them time and a bit of flexibility. Crappy config specs were hard to read, and often slow to work off of. Any config spec that I had to scroll...I knew I was in for a shit week.

Re: What comes after Git

#293

Post by pmeunier » Tue, Jul 05, 2022, 1:58 PM UTC

CuriousSkeptic wrote: post #211

ribit wrote: post #203

My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All…

Snapshots do have the advantage of not having to know anything about the data. Tracking changes necessarily needs to define a way to describe how things may change. Perhaps another take on the issue is that changing data should be structured to be more snapshot friendly?

I'm one of the authors of Pijul, and I have plans to turn it into a synthesis of snapshots and patches, I've implemented the formats and initial steps, see https://pijul.org/posts/2022-01-07-compressed-sanakirja/

The formats are ready for the next steps, but since this is only useful for really massive repos, I want to wait a little bit before spending the time on these features. If more people start using it, it may provide the motivation needed.

Re: What comes after Git

#294

Post by bvrmn » Tue, Jul 05, 2022, 1:59 PM UTC

8n4vidtmkvmk wrote: post #111

indy wrote: post #69

Earlier quoted context omitted.

I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?

hg up --clean i dont know why mercurial doesn't get more love.

As I remember `hg up` requires network access. What if you break a repo offline?

Re: What comes after Git

#295

Post by SassyGrapefruit » Tue, Jul 05, 2022, 1:59 PM UTC

silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

I think git is wonderfully elegant and simple. I wish more people would take the time to sit down and understand it. It only takes maybe an hour or two.

>Even a simple merge/rebase leaves one confused.

I've never had this problem. Git always works exactly as its designed for me.

Re: What comes after Git

#296

Post by vvillena » Tue, Jul 05, 2022, 2:02 PM UTC

bryanrasmussen wrote: post #138

pizza234 wrote: post #120

Earlier quoted context omitted.

The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases. The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files. Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs). There are strang…

if instead of checkout you had a bunch of separate functions you think you would remember those? Someone could probably make an argument that commands should be overloaded even more - clone, pull, and checkout could be merged for most of their common operations - as an example. Note: I am not necessarily for this but I'm not necessarily against it either. agree --patch is weird.

Check out pacman, the Arch Linux package manager, to see an extreme case of command overloading. It probably makes lots of sense from a conceptual point of view, but for users that simply use a very small subset of the tool, it can get a bit messy.

Re: What comes after Git

#297

Post by capitainenemo » Tue, Jul 05, 2022, 2:05 PM UTC

bvrmn wrote: post #294

8n4vidtmkvmk wrote: post #111

Earlier quoted context omitted.

hg up --clean i dont know why mercurial doesn't get more love.

As I remember `hg up` requires network access. What if you break a repo offline?

hg clean ?

Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up

Re: What comes after Git

#298

Post by leethargo » Tue, Jul 05, 2022, 2:06 PM UTC

al2o3cr wrote: post #265

sriku wrote: post #146

I've been using fossil ( https://fossil-scm.org ) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name…

3. You cannot rewrite history unlike git. Hence the name. So if somebody accidentally commits customer data to the monorepo, just burn down the whole company and start over?

I'm guessing you can still go back in time and just "forget" what came after wards, by using backups of the repo file.

Re: What comes after Git

#299

Post by bvrmn » Tue, Jul 05, 2022, 2:06 PM UTC

pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

I think a git CLI is an elegant and orthogonal and maps pretty much semantically to basic commit graph operations. It clicked when I started to think in terms of graph transformations and what graph state I want at the end.

> I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.

IMHO this one of the cases when GUI is better. I use `tig`.

Re: What comes after Git

#300

Post by sgbeal » Tue, Jul 05, 2022, 2:08 PM UTC

colejohnson66 wrote: post #290

sgbeal wrote: post #207

Earlier quoted context omitted.

> What does it matter? I do $packagemanager install git and am done. _Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post. > I can't clean up my messy WIP co…

I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.

> I amend commits in Git quite often before pushing.

Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them.

> And then there's this: what if I accidentally commit a private key or database?

Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.