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

191–200 of 430 posts

Re: What comes after Git

#191

Post by emn13 »

skratlo wrote: post #181
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…

Came here to say this, I stopped reading after that, just skimmed the article, it's bunch of horsecrap.

To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.

Re: What comes after Git

#192

Post by afiori »

maccard wrote: post #157
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…

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

Re: What comes after Git

#193

Post by L3viathan »

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…

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. But I agree that it would be nice to be able to label several commits (distinct from tags).

Re: What comes after Git

#194

Post by funklute »

gspr wrote: post #184
funklute wrote: post #109

Earlier quoted context omitted.

> Of course it isn't necessary. Well....but you literally said above that there's a need for it. In a somewhat condescending tone. And now it's suddenly obvious that it's not necessary? Okay.

It's possible to have a need for something even though that thing is not necessary. "Oh man, I really need a nice dinner right now" is impossible for you unless that dinner consists of the absolutely strictly minimum necessaries of nutrients in a gray tasteless slurry? Come on.

And again, you could lose the condescending tone, thank you very much.

Re: What comes after Git

#195

Post by COMMENT___ »

happyweasel wrote: post #145
tsimionescu wrote: post #126

Earlier quoted context omitted.

Subversion is much simpler than Git (centralized is always simpler than decentralized). Being simple is not what made Git popular. Git is popular because it is free, fast, works well enough, and was popular in some major projects. Its major advantage for most orgs (those who actually use it in a centralized manner, with a corporate repo that everyone syncs with every day, unlike the Linux kernel team) as compared to…

> it makes branches cheap and easy. IMHO branching itself isn't expensive in Subversion, the problems arise when you merge (feature)branches back. If you branch off (for release branches) and then just selectively merge certain commits to that branch only if needed (the info being stored in svn:mergeinfo), I think its not that bad. I prefer branch-by-abstraction and trunk-based dev anyway, so here you go ;)

Subversion has its branching and merging quirks, but it works and works well in most cases. Most of the usage problems can be solved by sticking to best practices and using up-to-date SVN client versions.

Re: What comes after Git

#196

Post by polyrand »

Not related to the problems listed in the blog post, but most of my problems with git went away when I started using worktrees[0] (I do a `--bare` clone and add worktrees in there).

Working on a new feature: new worktree Doing a code review: new worktree Testing random changes: new worktree (usually in detached mode) Need to debug some code from the current production branch: new worktree

All the problems with `checkout`, `stash` and switching between branches disappeared.

[0]: https://git-scm.com/docs/git-worktree

Re: What comes after Git

#197

Post by b0afc375b5 »

anonymous_sorry wrote: post #175
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…

I was learning git around the time `switch` and `restore` were introduced to tackle the problem of checkout being overloaded. I started using the new commands and it instantly made more sense and began to click. I very rarely use checkout at all. Something to be aware of when training junior devs. Do them a favour and learn switch/restore first!

I think this is the first time I've heard of switch and restore. Before I moved to magit I always used git checkout and git reset.

Re: What comes after Git

#198

Post by bayindirh »

R0flcopt3r wrote: post #153
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…

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

> For you to enjoy using this tool you had to change the model your brain use, and you call that good UX?

Every tool has its modus operandi, incl. but not limited to every programming language. Extending our understanding is hardly a bad thing.

Git proposes a model for handling stuff, and I prefer it very much.

And yes, the UX is fine.

Re: What comes after Git

#199

Post by i_have_an_idea »

GuB-42 wrote: post #183
i_have_an_idea wrote: post #179

> Kubernetes (the operating system of the cloud) The post just loses credibility after this statement. Yes, Kubernetes is important, but "operating system" is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.

Yes, and it matches the definition of an "operating system". Originally, an "operating system" is a system that takes the role of an operator. In the early days, operators were people who loaded programs, feed them data, fetched the results, etc... for the users. Matching the modern definition of an interface between the user and hardware. Kubernetes allocate servers (hardware) to containers just like a typical OS al…

> Yes, and it matches the definition of an "operating system".

No, it does not. An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. [1][2]

You cannot just arbitrarily take long-established technical terms and redefine them to suit your needs or your rough intuition. If you look in the authoritative sources below, there are over 100+ mentions of Linux and Windows, as well as several mentions of esoteric and defunct OS like Haiku, BeOS and others. Not a single mention of Kubernetes.

This is because Kubernetes is not an operating system and it does not fit the technical definition of an OS. It is container orchestration software.

It is important to call things using their real names, otherwise, eventually, communication breaks down and no one knows what we're talking about.

[1] https://www.britannica.com/technology/operating-system

[2] https://en.wikipedia.org/wiki/Operating_system

Re: What comes after Git

#200

Post by rsync »

R0flcopt3r wrote: post #153
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…

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

Counterpoint: for me to enjoy using the bicycle tool I had to change models my brain used … and, yes, I think the bicycle has a good UX.
Post reply on HN