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

181–190 of 430 posts

Re: What comes after Git

#181

Post by skratlo »

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.

Re: What comes after Git

#182

Post by sokoloff »

bmitc wrote: post #102
alexchamberlain wrote: post #88

Earlier quoted context omitted.

Simply separating concerns so that each PR/commit focuses on 1 thing.

But what is the one thing if you're just adding a dependency, where you're only adding it so that you can subsequently add a feature using it in a separate PR? The atomic action is adding the feature which requires the new dependency. Unless I misunderstood what you wrote. I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are wo…

It seems no different than adding a feature dark in one PR and turning it on in a second. “The atomic action is launching the new feature to users” seems like an equivalent argument (and one with which I disagree).

Re: What comes after Git

#183

Post by GuB-42 »

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 allocate CPU and memory to processes. And it stands between the user (here, the sysadmin) and the hardware (the servers). "Operating system of the cloud" is, I think, a good description of Kubernetes.

Re: What comes after Git

#184

Post by gspr »

funklute wrote: post #109
gspr wrote: post #93

Earlier quoted context omitted.

Of course it isn't necessary. It's just extremely useful. Of course it rewrites history, and I abhor rewriting shared history, but it's extremely useful to be able to rewrite your own private history!

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

Re: What comes after Git

#185

Post by anonymous_sorry »

mejutoco wrote: post #150
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…

I agree with you. Adding new well-thought commands while keeping the old more arcane syntax would be enough for me (like git switch, git restore, git create-branch instead of git checkout -b, etc.). This way new users will find it better to learn and people familiar with it don't need to change it.

`git switch --create` (or `-c`) is the new `git checkout -b`.

There is also `git branch --create`, although that doesn't switch you.

Re: What comes after Git

#186

Post by jansan »

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…

and marvel at how it ever became popular.

You obviously have not used the alternatives that were available before Git. After CVS and Subversion, Git was just a breeze of fresh air. But UX still has a lot of room for improvement.

Re: What comes after Git

#187

Post by codingdave »

vaughan wrote: post #55
tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

Usually problems arise before solutions. I’ve been thinking the same things and welcome this post.

Except the author did not really give problems. They gave a list of features they think would be needed, and some of those implied problems... but this post was a list of desired solutions. I have no idea what specifically they meant when they referred to git having pain points. I can guess based on my own experience, but a list of specific problems would have been lovely.

Re: What comes after Git

#188

Post by omnicognate »

hardware2win wrote: post #174
parasti wrote: post #94

Earlier quoted context omitted.

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.

Is there any other soft where ppl do seriously advise newbies to learn its internals? Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass" Imagine having to read excel's or windows code in order to use it consciously, lol.

You don't need to learn its internals or read its code. You do need to learn what it does. This is not unreasonable, and is not the reason its interface is a mess.

Re: What comes after Git

#189

Post by afiori »

bryanrasmussen wrote: post #138
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…

if instead of checkout you had a bunch of separate functions you think you would remember those? Someone could probably make an argument that commands should be overloaded even more - clone, pull, and checkout could be merged for most of their common operations - as an example. Note: I am not necessarily for this but I'm not necessarily against it either. agree --patch is weird.

If clone push and pull were overloaded into a

   git sync --from  --target
It would not change much.

The problematic kind of overloading are like how

    git push origin master
and

    git push origin master:master
push master to origin while

    git push origin :master
deletes master from origin.

Re: What comes after Git

#190

Post by geenat »

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…

How is large file support?

What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial?

Aside from that, Fossil is very intriguing.

Post reply on HN