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

321–330 of 430 posts

Re: What comes after Git

#321

Post by pizza234 »

andreareina wrote: post #244
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…

Push makes sense to me actually, branches and tags are both aliases to a particular commit. What makes them different is that the branch pointer gets updated on commit, while the tag pointer is (meant to be) static. But I do in general agree that the cli leaves much to be desired. I really have to give credit to magit for making a git ui that is simultaneously easy to use, powerful, and has actually made me more prof…

I think there is definitely a technical reason, but I'll explain the UX problem with an example: what does, intuitively, `push --force --tags` do?

1. force push both the branch and the tags

2. force push only the tags

It's very ambiguous - both answers make sense. And that's a big UX problem!

Re: What comes after Git

#322

Post by coxley »

Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we'll have the scaling sorted too.

Commits are automatically "branches" off trunk. You typically do 1:1, commit:PR. As you make new changes to the same PR, you `hg amend` instead of another commit. Those commits get merged into trunk.

Re: What comes after Git

#323

Post by nailer »

jpgvm wrote: post #313
nailer wrote: post #267

Earlier quoted context omitted.

Kubernetes main contribution to tech is “let’s do it all using kubernetes” as a meme for wasted time. It references the effort and money wasted by people that wanted to build cloud providers despite not being in the business of being a cloud provider.

Just no. Kubernetes has it's roots in Omega which was a research project to explore improvements to Borg. It was created/released as a direct response to increasing lock-in of AWS and Azure PaaS like services that were becoming an existential threat to GCP ever gaining any marketshare. Unlike OpenStack it did actually manage to mostly achieve it's goal of preventing lock-in by creating a standardized API in which all…

You've said a lot of things but none of these respond to the comment you're referring to.

> 1) Single-handedly forced the other 2 major vendors to implement a standard API.

I (and I'm sure you too, you seem intelligent) would be surprised if say EKS is anywhere close to ECS usage. k8s is considered so complex/poor Amazon sell ECS-on-prem.

It's the epitome of resume driven development - nobody uses k8s for any other reason except to say they use k8s.

Re: What comes after Git

#324

Post by aaronblohowiak »

superb-owl wrote: post #308
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.

> It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.

In what way does the cncf do this that the Apache foundation does not?

Re: What comes after Git

#325

Post by brendoncarroll »

I've been working on a project "Got". Which deals with the LFS problem, mentioned in the post.

https://github.com/gotvc/got

Got isn't really trying to do software version control better than Git. It's trying to make general purpose file versioning practical, with a workflow similar to Git's.

Re: What comes after Git

#326

Post by sophacles »

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.

Everyone uses it the way it was intended. There's not really another option. Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. All of that is because you have a local copy of the repo and history, and can develop your way against your local repo then push the resulting changes upstream. The fact that this allows chaining of upstreams is not the main focus of "decentralized" wrt git and the other dvcs, that's just a side effect of the concept that appealed to Linus since it would better fit the kernel development model.

From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.

Re: What comes after Git

#327

Post by capitainenemo »

bvrmn wrote: post #311
capitainenemo wrote: post #297

Earlier quoted context omitted.

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

> hg up doesn't require network access. So it's like `git checkout` and doesn't cover all breakage cases.

Not sure how to answer that, but sure, I can imagine plenty of ways in which a local repo could be screwed up that might require a strip or just a complete fresh pull. "All breakage cases" is pretty broad.

My personal reasons for liking mercurial is some pretty amazing tooling (hg absorb, hg fa --deleted, revsets/filesets) combined with a friendly commandline with fairly sensible defaults.

Re: What comes after Git

#328

Post by fargle »

tsimionescu wrote: post #134
fargle wrote: post #22

Earlier quoted context omitted.

agree. same question as "what comes after C ?" same answer.

I'm sure some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI. No king rules forever. C has become a much more niche language than it was 20-30 years ago, and the trend continues. C++ has slowly eroded most of its niches, and there's a slew of new languages gunning for its throne - Rust being the most likely to succeed (especially once we will have some popular Lin…

But those aren't good analogies for "C". I think the best analogy is the long-standing belief prior to "C" that assembly would "always" be the systems programming language. Yes, someday a new king will be born (I doubt a coup).

In a similar grain, git is a beautifully designed and conceived simple content-addressable object store. With a complex and challenging UI (I don't have any problem with it, but still).

Neither of these tools are perfect; in fact they can sometimes be objectively be more imperfect than many of their competitors. But they are special.

> some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI

It's not what people write about - it's what they use. C, UNIX(/Linux), Git are all very similar - and Pervasive.

Re: What comes after Git

#329

Post by howinteresting »

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…

Interactive rebases are what I use as well. They're such a terribly broken way to use Git. You can't even start an interactive rebase (to go back and update earlier commits in the stack) in the middle of another one.

Re: What comes after Git

#330

Post by prettyStandard »

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…

To split a commit...

1. Make a new commit to revert what you to come last

2. Make a new commit to revert what you want to come first

3. Make a new commit to restore/revert line 2 above

4. Make a new commit to restore/revert line 1 above

5. Squash original into lines 1 & 2 above

Alternatively you can use interactive rebase, 1. set edit on the commit you want to split

2. When the rebase stops, `git reset --soft HEAD~1` (I think)

3. `git add` and commit as necessary then follow up with git rebase --continue

Post reply on HN