What comes after Git • Hacker News Board

Re: What comes after Git

#361

Post by wvh » Tue, Jul 05, 2022, 6:08 PM UTC

nailer wrote: post #323

jpgvm wrote: post #313

Earlier quoted context omitted.

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

What's your alternative for stuff that needs to run on more than one server for reliability or scale? I have been duct-taping HA solutions since the late nineties, it definitely wasn't prettier than Kubernetes. We are beyond the phase where we want to care about a physical server with a broken hard disk or power supply. Whether or not Kubernetes-the-software is the answer to the conceptualisation of a "computer" is beyond the point; there is a clear trend towards abstraction of computing hardware for good reasons, even for companies way smaller than the Googles and AWSes of this world.

Re: What comes after Git

#362

Post by bvrmn » Tue, Jul 05, 2022, 6:14 PM UTC

AvImd wrote: post #353

quietbritishjim wrote: post #331

Earlier quoted context omitted.

Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if…

Is there any option to have this "private commits" feature in git? I just realized it's exactly what I wanted so many times. I've tried the assume-unchanged hack but it's too brittle.

I successfully use [stgit][1] (for 10 years) for private commits and pretty much for the rest of near-git workflows.

[1]: https://stacked-git.github.io/

Re: What comes after Git

#363

Post by COMMENT___ » Tue, Jul 05, 2022, 6:14 PM UTC

sophacles wrote: post #355

COMMENT___ wrote: post #350

Earlier quoted context omitted.

I believe that - hypothetically - centralised version control can have disconnected local commits with private local branches. But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI. I don’t think that SVN, p4 or CVS have support for local commits. What I want…

I think you are getting confused about what is decentralized by git (et al). It's not that there's a notion of "a canoncial copy". The canonical copy stuff is about user/developer organization. What dvcs distributes is the history - the notion that you can have local commits, branches, etc is a decentralization of a repo's history. In a centralized vcs, that history is always mediated by the server - you want a new r…

> In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is.

I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy?

I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git.

* I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control?

* GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised.

When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history.

I think that's what @evouga meant in his comment above when he said > 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

#364

Post by bvrmn » Tue, Jul 05, 2022, 6:16 PM UTC

quietbritishjim wrote: post #331

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…

Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if…

I heavily used mq extension and it was pretty inferior in UX terms to StGit at those times. With StGit there are no any nice features in Mercurial for me.

Re: What comes after Git

#365

Post by bvrmn » Tue, Jul 05, 2022, 6:18 PM UTC

lenkite wrote: post #356

quietbritishjim wrote: post #331

Earlier quoted context omitted.

Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if…

If only someone had launched hghub.com at the time of github.com.

I remember issues with windows/unix interop for mercurial repos when github started to gain traction.

Re: What comes after Git

#366

Post by koonsolo » Tue, Jul 05, 2022, 6:27 PM UTC

bvrmn wrote: post #282

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…

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 merge again. Have fun solving all the merge conflicts that actually shouldn't be there.

Like I said, SVN and Mercurial are fine too. I don't see any reason why git would magically solve some merge conflict that SVN or Mercurial is not able to.

Re: What comes after Git

#367

Post by koonsolo » Tue, Jul 05, 2022, 6:32 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…

I see you never worked with coworkers that were able to mess up a git system. And because git is so complex, it's pretty easy to mess up.

Just let some junior developers to some rebases and squashes, and see what happens.

Re: What comes after Git

#368

Post by [deleted] » Tue, Jul 05, 2022, 6:32 PM UTC

COMMENT___ wrote: post #363

sophacles wrote: post #355

Earlier quoted context omitted.

I think you are getting confused about what is decentralized by git (et al). It's not that there's a notion of "a canoncial copy". The canonical copy stuff is about user/developer organization. What dvcs distributes is the history - the notion that you can have local commits, branches, etc is a decentralization of a repo's history. In a centralized vcs, that history is always mediated by the server - you want a new r…

> In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy? I think that the most common daily use workflows with git and GitHub are absolutely c…

[deleted]

Re: What comes after Git

#369

Post by bergenty » Tue, Jul 05, 2022, 6:42 PM UTC

gspr wrote: post #27

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…

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

What do you mean? Why can’t you just pull down version 1.3 of a file by specifying the version number in the command?

Re: What comes after Git

#370

Post by nathants » Tue, Jul 05, 2022, 6:43 PM UTC

kjeetgill wrote: post #224

nathants wrote: post #128

Earlier quoted context omitted.

lately i’ve been using stash, reset hard, stash pop. work on a single patch over main. use a backup branch prior to stash, just in case.

That's reasonable, but I think a commit + a rebase -i of just that single commit gets you to the same place. And now your backup branch can preserve the code you would have stashed.

rebase is a multi stage command that often requires force push. as good as it can be, discouraging it’s use, especially in contexts where git is considered challenging, is probably the play.