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

421–430 of 430 posts

Re: What comes after Git

#421

Post by Too »

colejohnson66 wrote: post #290
sgbeal wrote: post #207

Earlier quoted context omitted.

> What does it matter? I do $packagemanager install git and am done. _Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post. > I can't clean up my messy WIP co…

I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.

Even in git, amending doesn’t rewrite the actual commit though. It creates a new one. You can find the old in your reflog. Think about it, the commit hash is based on the contents, so it must be changed on any content changes. It’s only after pushing that history is written in stone.

So you can say git never removes anything either.

The biggest issues with data loss in git is before you have done a commit. There, many actions can nuke your changes because you mixed up two flags, trying to rebase before commiting, etc. As long as you have a commit though, the reflog will save you from failed rebases.

Re: What comes after Git

#422

Post by Too »

enasterosophes wrote: post #52
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.

I didn't recognize the author, but came here to say the same thing: where are the ideas on how these improvements would be implemented? Without making an attempt at implementation, you (the generic you, not the person I'm replying to) have no idea what the real issues are. Even failed or partial implementations are more instructive than armchair criticisms, or thought experiments where you can just handwave away all…

Of course concrete ideas are better. But even armchair criticisms can be important (or at least interesting), to open up the discussion.

While git is good and powerful in many ways, git frankly has many deficiencies, yet everybody treats it as the holy grail of version control. Just because Linux uses it, GitHub exists or something else, I don’t know. The author lists many valid points that are not all sci-fi and that would multiply the usefulness of the vcs sevenfold.

Someone has to point out the elephant in the room.

It could spark the idea for someone to invest in something new and better or for someone to contribute improvements into git.

Re: What comes after Git

#423

Post by nailer »

0xCAP wrote: post #391
nailer wrote: post #376

Earlier quoted context omitted.

> What's your alternative for stuff that needs to run on more than one server for reliability or scale? Same as most people, and as previously mentioned: I pay pay a cloud provider, unless my business is being a cloud provider.

How do you host your stuff on, say, GCP? App engine? Only 1 per project. Compute Engine? Basically a VPS. Cloud Run? Ok, good luck with stuff that requires long running requests or listening to events from a source different from Google Cloud Pub/Sub, because your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming, so basically not an options for microservices if you're…

You're acting like IaC didn't exist before k8s.

Right now I'd use Pulumi, years ago I'd use Terraform, or the AWS API - I part of the first node AWS API client and part of App Engine before k8s existed. k8s didn't invent infra as code or auto provisioning capacity. The fact that it's advocates act like it did is why k8s is a DevOps meme.

> your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming

That's a good thing. I think you don't understand Serverless.

Re: What comes after Git

#424

Post by nailer »

jpgvm wrote: post #394
nailer wrote: post #323

Earlier quoted context omitted.

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…

All of it responds to your original comment which was your statement that it contributed nothing except padded resumes. I stated several things it contributed -even if you think it's too complex-. If you don't understand why people use k8s you don't understand the problems it solves. Especially if you think ECS is a substitute.

The thing you stated is that k8s allows people to easily deploy across different cloud providers due to lack of vendor lock in. k8s doesn't because nobody uses it for that - the cost of getting it tunning compared to simpler alternatives removes all value from the cross-platform abilities. That's why k8s is a DevOps meme.

Re: What comes after Git

#425

Post by JoeyBananas »

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…

My complaint is that the names of commands in Git are not intuitive. Otherwise, I think the UX lf Git is near perfect because it's possible to write things like Git graphical wrappers.

Re: What comes after Git

#426

Post by mirodin »

sgbeal wrote: post #291
midenginedcoupe wrote: post #172

Earlier quoted context omitted.

Well that's a different argument. The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

> But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :( cough Fossil cough

Amen to that. I love Fossil for its simplicity and batteries included model. No external ticketing, wiki and documentation to manually keep in sync. Plus everything inside a single SQLite file makes everything easier.

Re: What comes after Git

#427

Post by pdmccormick »

OJFord wrote: post #162
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 do wish I had an easier way to split up a commit that accidentally included several unrelated changes though. Perhaps it's what you want something easier than, but I have `uncommit` aliased to `reset HEAD^`, and use it often as `git uncommit -p` (then amend, then the 'uncommitted' changes are unstaged ready to go in a different commit if they were wanted just elsewhere, or removed if not).

Thank you, I think that is exactly what I was looking for, and just what I had secretly hoped someone might suggest in response to my comment. Thanks again!

Re: What comes after Git

#428

Post by pdmccormick »

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?

I've never understood the argument that you should not optimize your own working environment (IDE/editor customization, alternate keyboard layouts, shell aliases, custom hotkeys, scripts, etc.) because it could be unfamiliar to someone else. I've also heard it in the context of, you shouldn't stray too far from the defaults because if you sit down to use a colleagues' computer, you will be out of your element. Unless your job is to pair program full time, or perhaps you're creating educational screencasts, maybe? If you slowly build out your own personal setup over time, presumably you should still always be able to explain what it is that you're doing at each step.

Re: What comes after Git

#429

Post by ferruck »

vaughan wrote: post #163
ferruck wrote: post #151

Earlier quoted context omitted.

I choose to use git, over and over again. I hardly use any of its "network effects" but rather its features. So, maybe try to be a bit less general the next time, please.

Do you use GitHub? Do you work with a team? Did you really review other alternatives and try them out?

Sorry for the late response.

> Do you use GitHub?

Just a bit, it's nothing I look forward to. I mainly use Gitlab due to work, but it's not that much better.

> Do you work with a team?

Yes.

> Did you really review other alternatives and try them out?

Only SVN some years ago and I hated it.

It wasn't my intention to say that Git is the best VCS we'll ever get, but I enjoy using it and (besides the sometimes a bit baroque command line syntax) have nothing to complain about. So, whenever there's the need for version control, I choose Git without second thought and so I never even felt the urge to try something else. I'm sure that this will change at some point, but not yet.

Re: What comes after Git

#430

Post by _huayra_ »

ecnahc515 wrote: post #402
_huayra_ wrote: post #303

Earlier quoted context omitted.

> The checkout command is severely overloaded; I've been using git since 2008. I just learned a few weeks ago that I had the opposite understanding of what --theirs and --ours does on git-checkout during a rebase operation. (briefly: --ours is the branch you are rebasing onto, --theirs is the changes from the branch with the changes you are repeatedly cherry-picking into the new branch. see this answer for more detai…

It kind-of makes sense when you think of rebase as a composite command that does a checkout of the branch/newbase and cherry-picks the commits from previous branch.

Yes, it actually totally makes sense, but the issue is that if one draws the mental picture the wrong way the first time (and is left uncorrected), it's equally easy to draw the mental picture (i.e. of commits "flying around" from one branch to another) in the other direction too. That's what bit me

I don't even know how to check for mistakes here with my current employer (god speed to the code I wrote at my previous jobs). Unlike a merge, a rebase leaves no trace except in the reflog :(

Post reply on HN