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

341–350 of 430 posts

Re: What comes after Git

#341

Post by mbfg »

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.

mercurial was pretty nice, and if you have a "beginner developer team", mercurial is probably my recommendation. but how git does branching is just better in a way you just can't get past, once you use it. Luckily it's usually pretty simple to start with hg and move to git at a later date.

Re: What comes after Git

#342

Post by AlexandrB »

midenginedcoupe wrote: post #112
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…

Absolutely. I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits. I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team st…

Mercurial is really nice. I find its CLI interface much less confusing than Git's. I think a lot of this has to do with Git's "index" where you have to "add" files and then "commit" them. This seems like the #1 source of confusion when people are learning Git and persists into operations like "rebase" and "cherry-pick" where the index is used for marking conflicts as resolved or not.

Re: What comes after Git

#343

Post by stonekyx »

SassyGrapefruit wrote: post #295
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.

Exactly. Git felt totally intuitive to me when I started using it as a teenager (with no background on SVN et al. of course), and most colleagues I've met so far also rarely had troubles using it. The latter is probably because I intentionally chose to work for companies that use Git though.

Re: What comes after Git

#344

Post by kfkdldldl »

COMMENT___ wrote: post #337
sophacles wrote: post #326

Earlier quoted context omitted.

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

> Everyone uses it the way it was intended. "Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever". > 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…

> I think that it is possible to add local branches and commits to centralised version control

Well, you think wrong, because it's not. Centralized change control will contact the central server for every change.

If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reachable over the network

Re: What comes after Git

#345

Post by nine_k »

comex wrote: post #68
nine_k wrote: post #41

Earlier quoted context omitted.

There absolutely is version control for rewriting commit history, no fancy tools needed. Start another branch at the point where you want to rewrite history; don't switch to it: `git branch original-history-branch`. Now `git rebase` your branch to your heart's content. This branch will have the new, rewritten history. The original-history-branch still has your old history, refers to your old commits and prevents them…

That’s like saying the operating system has version control built in, no fancy tools needed, because you can `cp my-code.c original-my-code.c`, edit `my-code.c`, and have `original-my-code.c` just in case you’d like to reset your code to the old version. That is to say - sure, it can work, but automated history tracking is far superior. Though, git does at least have reflog, so if you accidentally delete or overwrite…

This is true, and this is entirely the UI / workflow problem.

Git keeps a version for you while you are doing a rebase, so you can say `git rebase --abort` and get back to the preserved state. But it does not keep a log of these, and, more importantly, does not ask you whether you are glad with the end result: you cannot --abort right after a rebase completed without conflicts. One would say that you should explicitly do something like `git rebase commit` (or `git merge commit`) after you have reviewed the result.

Re: What comes after Git

#346

Post by beej71 »

AlexandrB wrote: post #342
midenginedcoupe wrote: post #112

Earlier quoted context omitted.

Absolutely. I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits. I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team st…

Mercurial is really nice. I find its CLI interface much less confusing than Git's. I think a lot of this has to do with Git's "index" where you have to "add" files and then "commit" them. This seems like the #1 source of confusion when people are learning Git and persists into operations like "rebase" and "cherry-pick" where the index is used for marking conflicts as resolved or not.

I personally always liked the flexibility the stage offers.

Re: What comes after Git

#347

Post by ogogmad »

i_have_an_idea wrote: post #339
ogogmad wrote: post #223

Earlier quoted context omitted.

Asking what the word "operating system" means is like asking what money is. There isn't really a one true definition. "Operating systems" in a much narrow sense were invented in the 1950s. I cannot tell you what people meant by the term back then. Then it seems that they accreted features. And then they accreted more features, like a gigantic snowball or avalanche. Ultimately, this all happened because people were la…

I feel like you ignored everything that I wrote, particularly the bit about it being important to call things using their correct names for the sake of effective communication. I.e., container orchestration software vs operating system. As for the rest of your argument, I feel ambivalent on whether it is worth responding. But here's my two cents: 1) Random userland software bundled with the OS does not constitute par…

> As for the "being able to parrot" bit, please spare your personal attacks. They don't make your argument any stronger, they just make me think it is not worth talking to you.

Sorry. I wasn't trying to attack you. But I can definitely see that it comes across that way, so I'll bear that in mind in the future. I might have been arguing for the sake of arguing too.

Re: What comes after Git

#348

Post by morelisp »

aaronblohowiak wrote: post #324
superb-owl wrote: post #308

Earlier quoted context omitted.

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?

I personally can’t wait until we have even more moribund foundations shipping over-engineered corporate leftovers.

Re: What comes after Git

#349

Post by troyvit »

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…

Yeah Mercurial seems like what git should have been but never will be.

Re: What comes after Git

#350

Post by COMMENT___ »

kfkdldldl wrote: post #344
COMMENT___ wrote: post #337

Earlier quoted context omitted.

> Everyone uses it the way it was intended. "Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever". > 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…

> I think that it is possible to add local branches and commits to centralised version control Well, you think wrong, because it's not. Centralized change control will contact the central server for every change. If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reac…

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 to say is that local commits could be added into centralised version control systems. Come on, SVN has a local working copy. Won’t it handle local commits?

Post reply on HN