Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

401–410 of 430 posts

Re: What comes after Git

#401

Post by vagab0nd »

pmeunier wrote: post #285
vagab0nd wrote: post #276

Earlier quoted context omitted.

How production-ready is Pijul? I heard about it some time ago and was super impressed. But apparently at the time it had issues, and was going to be re-written in a different language.

Wow, you heard about Pijul years ago then. I believe it is production-ready, in the sense that there hasn't been any real bug in months. I'll remove the "beta" label when more people use it. One thing that isn't production-ready is nest.pijul.com, but mostly for lack of funding: that platform uses the CRDT nature of Pijul to replicate all the repositories in different datacenters, but the machines it runs on are some…

I did not expect to get an answer from you directly :) I will definitely try it out with my next project!

Re: What comes after Git

#402

Post by ecnahc515 »

_huayra_ wrote: post #303
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…

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

It kind-of makes sense when you think of rebase as a composite command that does a checkout of the branch/newbase and cherry-picks the commits from previous branch.

Re: What comes after Git

#403

Post by tbrugz »

afiori wrote: post #192
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.

I thought that mercurial was able to push/pull from a git remote.

You can use the hg-git extension for that:

https://hg-git.github.io/

Re: What comes after Git

#404

Post by kadoban »

shikoba wrote: post #287
kadoban wrote: post #277

Earlier quoted context omitted.

Git has both concepts, snapshots and changes. You'd have to contort yourself more than a bit to describe common uses of "git rebase" without viewing it as changes, for instance. You may be aluding to git's underlying storage being snapshot based, but it actually also has diffs in pack files.

> but it actually also has diffs in pack files Storage optimization, absolutely unrelated to the diff between two snapshots.

The semantic layer uses both, and the implementation layer uses both. Saying that it's one or the other just seems misguided.

Re: What comes after Git

#405

Post by tsimionescu »

shikoba wrote: post #288
tsimionescu wrote: post #269

Earlier quoted context omitted.

Yes? Editing a file is different from creating a new file with some code copied from somewhere else, obviously. They may reach the same end state, but that doesn't make them the same operation. It also happens that one is much, much more common in software development than the other, so it's a much better mental model of what SEs do.

> They may reach the same end state, but that doesn't make them the same operation. So you're clinging to your mental model. Thanks for proving my point.

This is how work is actually done, and my mental model matches how I and my colleagues and yours as well actually work.

I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me.

We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the same as Merge sort just because they have the same inputs and outputs.

Re: What comes after Git

#406

Post by atq2119 »

evouga wrote: post #306
sophacles wrote: post #261

Earlier quoted context omitted.

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

> Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.

The company I work for has internal forks/clones of many projects hosted on GitHub.

I routinely interact with at least four different clones of a project: the upstream one on GitHub; the local one on my machine; my personal clone on GitHub for upstream contributions; and the company-internal clone hosted on some company-internal server.

So yes, we are using git in a decentralized fashion.

Re: What comes after Git

#407

Post by maccam94 »

koonsolo wrote: post #366
bvrmn wrote: post #282

Earlier quoted context omitted.

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…

> Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar. I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that. If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merg…

> try to do a squash merge to the main, then do some other changes in your branch, and try to merge again

For this situation, at the end just do:

git rebase -i main

And delete all of the commits that you included in your squashed commit. If you want to preserve your detailed history you can create a new branch for the rebase like so:

git checkout -b mybranch-rebase && git rebase -i main

Re: What comes after Git

#408

Post by shikoba »

tsimionescu wrote: post #405
shikoba wrote: post #288

Earlier quoted context omitted.

> They may reach the same end state, but that doesn't make them the same operation. So you're clinging to your mental model. Thanks for proving my point.

This is how work is actually done, and my mental model matches how I and my colleagues and yours as well actually work. I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me. We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the…

The issue is that the path you used to go from A to B is yours, one could use a totally different path. But what really matters is that your product is now in state B. That's what you ship, not the path.

Re: What comes after Git

#409

Post by shikoba »

kadoban wrote: post #404
shikoba wrote: post #287

Earlier quoted context omitted.

> but it actually also has diffs in pack files Storage optimization, absolutely unrelated to the diff between two snapshots.

The semantic layer uses both, and the implementation layer uses both. Saying that it's one or the other just seems misguided.

I don't understand your point. Mine was just that git could decide to store only snapshots, it would change nothing except for low level commands that deal directly with objects storage.

Re: What comes after Git

#410

Post by silisili »

jerf wrote: post #289
sophacles wrote: post #261

Earlier quoted context omitted.

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

There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life,…

Well said, but I humbly disagree that it has to be better in some way, just easier AND as technically sound. Unless that is by your definition better. Ease of use is probably one of the most important factors in real life in determining preferences for software.

I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be a Git replacement, but a better frontend. Kind of how yay is to pacman. Or how most use something like Handbrake instead of ffmpeg.

In a lot of ways, it reminds me of Python and Perl. Perl was definitely more powerful as a language, but Python felt like natural writing in pseudocode. Enthusiasts rightly point to the power of inbuilt regex, but like Git, few actually could harness it well enough to make that unreadability worth it.

Post reply on HN