What comes after Git • Hacker News Board

Re: What comes after Git

#301

Post by sgbeal » Tue, Jul 05, 2022, 2:11 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?

> So if somebody accidentally commits customer data to the monorepo

First, you use that as a "teaching opportunity" to educate that someone about why doing so is Bad for Business. Secondly, you "shun" the artifact(s) in question. Since shunning burns holes in the project history (DAG and blockchain), we (in the fossil project) invariably advise against going so unless it's absolutely necessary (publishing custom data being an example of "necessary"). There's a major semantic difference between deleting content "just to cleanup the history" vs. "to eliminate legal liability."

> , just burn down the whole company and start over?

If you prefer that approach then have at it.

Re: What comes after Git

#302

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

troppl wrote: post #141

krageon wrote: post #105

Earlier quoted context omitted.

> Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)

Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays. But still, everyone remembers how hard it was to start out. Which is why…

> I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more.

I had enough SVN merging issues so when git appeared I forced transition to git in a 3 month-period including writing Git-plugin for Hudson (Jenkins).

Re: What comes after Git

#303

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

pizza234 wrote: post #120

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…

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…

> The checkout command is severely overloaded;

I've been using git since 2008. I just learned a few weeks ago that I had the opposite understanding of what --theirs and --ours does on git-checkout during a rebase operation. (briefly: --ours is the branch you are rebasing onto, --theirs is the changes from the branch with the changes you are repeatedly cherry-picking into the new branch. see this answer for more detail [0])

I shudder to think how much I've screwed things up over my career as a result...

[0] https://stackoverflow.com/a/34260242/2492058

Re: What comes after Git

#304

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

sgbeal wrote: post #300

colejohnson66 wrote: post #290

Earlier quoted context omitted.

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. Foss…

Why do you mean "modify"? As in rewriting history (commits before HEAD)?

Re: What comes after Git

#305

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

sgbeal wrote: post #207

L3viathan wrote: post #193

Earlier quoted context omitted.

1: What does it matter? I do $packagemanager install git and am done. What do I care whether it's got dependencies or consists of several binaries? 2: Fair enough. Although a multi-file backup doesn't sound hard to me either. 3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits? 4: Sounds like a nice feature. 5: This just uses the term "tag" to mean something else that git tags.…

> 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…

> Nope. Fossil remembers what happened, not what "should have" happened.

So if someone new on the team accidentally commits "node_modules" it's there in the history forever? Doesn't sound like a great feature...

The choice to discard history gives freedom to developers

Re: What comes after Git

#306

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

sophacles wrote: post #261

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…

> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then t…

But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.

Re: What comes after Git

#307

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

samtheprogram wrote: post #16

bergenty wrote: post #8

Earlier quoted context omitted.

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the vers…

These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method. Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if…

There shouldn’t be different ways to handle the same problem. It should literally be 4 features and call it a day. Simplicity is a feature.

Re: What comes after Git

#308

Post by superb-owl » Tue, Jul 05, 2022, 2:20 PM UTC

mpermar wrote: post #167

>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below. Kubernetes didn't brought open-source collaboration to a new level. No matter how relev…

To try and steelman this line - the CNCF (a major force behind k8s) has indeed been a game-changer for OSS. It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.

IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.

Re: What comes after Git

#309

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

flurdy wrote: post #149

alexchamberlain wrote: post #81

Earlier quoted context omitted.

Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.

Since I often play with razors by rebasing, resetting, cherry picking, etc locally - I created a `git tmp` alias so I can play without fear of needing to go reflog diving again. The `tmp` command creates a commit of all changes, branches it, then rolls back the commit. [1] https://github.com/flurdy/dotfiles/blob/master/.config/fish/...

This temp branch (or even `git tag my_orig_branch`) approach is usually a better on-ramp than the reflog. It's still too easy to misread the line in the reflog of a prior HEAD change and go to the wrong commit, whereas the tmp branch is foolproof (and fatigue-proof).

Re: What comes after Git

#310

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

capitainenemo wrote: post #297

bvrmn wrote: post #294

Earlier quoted context omitted.

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

So you should also read the manual to know about. There no such thing as "intuitive" in VCS world. Looks like most of commentators confuse intuitiveness with familiarity.

Don't get me wrong I appreciate mercurial devs did a tremendous work to hide DVCS under SVN-like ("simple" hah) interface. But every non-standard thing requires manual reading.