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

231–240 of 430 posts

Re: What comes after Git

#231

Post by andyjohnson0 »

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…

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

I think this explains a lot of the initial popularity of git and github. Wanting to be like the cool kids, and git knowledge being seen as somehow "elite" back then.

But given that initial popularity, it seems likely to me that network effects mostly explain its growth in usage from there. Convergence on a single revision control tool/site/representation/api/etc is probably inevitable, in the same way that there is basically a single social network (ie Facebook).

Re: What comes after Git

#232

Post by gigatexal »

I dunno. I’ve decided like with SystemD to just learn it and get on with life. Git is ubiquitous and so is SystemD. Learn them. Adapt. Move forward.

This is not to say they’re perfect but they’re open source so if I felt strongly I could offer code to change it.

Re: What comes after Git

#233

Post by sgbeal »

open-source-ux wrote: post #225
sgbeal wrote: post #202

Earlier quoted context omitted.

(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is abso…

" Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium. " I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?

> A question rarely raised: why is Git considered suitable for small or medium projects?

Quite frankly, _it's not_. There's _absolutely nothing_ ideal about git except for its ability to super-scale to that _exceedingly small_ percentage of projects which need that level of scaling. That's its _one and only_ killer feature. If it weren't for github and its ilk, git would be just another second-tier tool like the rest of the SCMs. Unlike every(?) other SCM, fossil doesn't require 3rd-party tools to host over CGI: that's built right in to it and CGI works on even the cheapest of shared-hosting platforms, so no equivalent of github is required in order to host one's own repositories.

Granted, as a long-time fossil dev and advocate, i'm _severely_ biased in this regard, but there's are _reasons_ i prefer fossil over git, why i use it for _all_ of my own projects (fossil.wanderinghorse.net), and why i support and advocate for it (just not for that small tier of "uncommonly large" projects, as fossil has, quite frankly, no business being used there).

Re: What comes after Git

#234

Post by dale_glass »

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…

Let me try!

> Even a simple merge/rebase leaves one confused. Which should I use?

Merge merges two branches. You fork a branch off master, work on stuff until it's done, then merge it back into master. After that the branch can go away.

Rebase is for rewriting history. To get rid of the 20 embarrassing commits where you tweaked stuff at random hoping to get it to work, or to redo a bunch of changes in a more coherent and easier to review way. It can be used to transplant work from one branch to another. It also can be used to keep up with the changes in the branch you forked off from.

> What is incoming? Why does incoming change as you progress?

Not quite sure what you mean, could you provide more details?

> I didn't change anything (on purpose) but Git won't let me change branches.

Probably because changing branches would lose your current work. It can happen either mid-rebase, or because you modified a file that would be overwritten by a branch change.

> How do I just unfuck what I did and go back to a branch?

You can abort a rebase with `git rebase --abort`. This loses progress.

> Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.

I agree the UI leaves a lot to be desired. But the main thing is that you need to understand what it is that you want to accomplish first, especially in the merge/rebase question.

Re: What comes after Git

#235

Post by tasuki »

alenmilk wrote: post #103

The thing is that git is not supposed to be smart when it comes to merging. https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-tor... At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you. So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.

Yes, better conflict resolution is needed, but outside of scope for git. Do one thing well.

Re: What comes after Git

#236

Post by nine_k »

vlovich123 wrote: post #97
nine_k wrote: post #38

Earlier quoted context omitted.

How about `git status`? The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay. [1]: https://github.com/facebook/watchman

Facebook uses mercurial across the board, at least from what I saw a couple years back. A good chunk of the large file / large repo has been open sourced as EdenFS [1] which uses file notifications to update the status as you make changes to amortize the cost so that it’s already computed by the time you query (watchman is integrated). That being said, very few code bases grow to this size unless you are a major tech…

This is correct! Sorry. It's sometimes better to sleep in the middle of a night than to post. So embarrassing.

Re: What comes after Git

#237

Post by ziml77 »

The semantic diffing bullet point has me wondering what attempts there are at making open source semantic diff tools. I love the closed source tool SemanticMerge, but the company behind it decided to be shitwads and pull the product so they could add a selling point to their proprietary version control system.

Re: What comes after Git

#238

Post by mabbo »

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…

It's fine. It works. But it's not intuitive.

A decade of near daily use of it, as the 'git guy' on most teams I'm in, and I'm still spending time searching how to do specific things. To use a UX term, there's very few affordances telling me what I should expect, guiding my intuition.

Imagine a VCS where it was obvious and easy to figure out how to do anything that is possible. Along with all the power that git brings today.

Re: What comes after Git

#239

Post by sgbeal »

gorgoiler wrote: post #35

The project management features don’t have to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red/green results at integration time. A project should encapsulate the code, how we got there, what we changed, and why we changed it. The code is your HEAD, available as a working copy. How we got there is the stack of diffs that,…

> Which cat meme was deemed appropriate for the final approval of the change?

FWIW, that wins my internet for today and i'll aim to make that a factor in any future code reviews/approvals.

Re: What comes after Git

#240

Post by alksdeef »

mabbo wrote: post #238
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…

It's fine. It works. But it's not intuitive. A decade of near daily use of it, as the 'git guy' on most teams I'm in, and I'm still spending time searching how to do specific things. To use a UX term, there's very few affordances telling me what I should expect, guiding my intuition. Imagine a VCS where it was obvious and easy to figure out how to do anything that is possible. Along with all the power that git brings…

Seems like that's been done pretty well with all the wrappers, tui and gui's available.. what else is needed?
Post reply on HN