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

121–130 of 430 posts

Re: What comes after Git

#121

Post by josteink »

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…

> Every time I use Git, I see how bad the UX is and marvel at how it ever became popular.

It's a tool aimed at technical people, which at the time it was launched offered features and technical possibilities which was unmatched by most other popular source-control systems at the time.

I remember going from Microsoft's Team Foundation Version Control to Git, and everything just felt miles more flexible and capable.

Especially branching was enormously limited with Microsoft's offer, while Git literally allowed me to merge anything I wanted, across any base, and usually end up where I wanted to be.

In short: Git solved real world problems in a way which more than compensated for its somewhat clunky UX.

Re: What comes after Git

#122

Post by kjeetgill »

nathants wrote: post #90

git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m

Interesting exercise. Mine looks more like:

- push/fetch: I personally never liked pull, it's sugar over fetch and merge/rebase.

- checkout -b: haven't looked into all the switch stuff yet

- rebase -i: my bread and butter. I rarely use merge aside from PRs where rebase bugs people.

- add/commit -am: obviously required

- cherry-pick/reset: pretty much replaces stash without introducing a whole new set of tools

- diff/log/status: if you get comfortable with these, you're not going to wedge yourself ever again

- brach: very much an unsung hero. If you get comfortable with commiting often and using brach. You can't ever lose your place doing anything ever again.

Re: What comes after Git

#123

Post by LtWorf »

parasti wrote: post #94
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…

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.

How to waste a week without learning anything useful about actually using git :D

At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.

Re: What comes after Git

#124

Post by morelisp »

mikewarot wrote: post #39
nine_k wrote: post #12

Earlier quoted context omitted.

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

>Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code. Git is a content addressable snapshot system, with bolted on code to make it retrospectively appear to be a line-oriented system. It's worse than you thought.

It's not worse. Snapshots are exactly what you want if you would like to have format-aware diff/merge or to experiment with alternate algorithms.

But it's easier to complain about git and throw out pie-in-the-sky ideas about "modernizing our tools" than to try the actually-existing AST-based diff/merge tools and realize it's 100x more complex for no workflow gain.

Re: What comes after Git

#125

Post by kadoban »

tsimionescu wrote: post #116
Akronymus wrote: post #47

Earlier quoted context omitted.

Would it make sense to make one commit for the move and one for the changes?

No, because you often have to make changes to the file to get it to compile after loving to a new location. It's much more annoying to review history with changes that can't possibly compile.

This isn't necessarily an issue, depending on what you mean by "review". The one case I really run into is bisects, but even for that you can tell it to just skip commits that won't build.

Re: What comes after Git

#126

Post by tsimionescu »

kache_ wrote: post #7

Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is

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 Subversion is that it makes branches cheap and easy. The ability to work with history offline is also nice in niche situations, but definitely not the major selling point.

Its major advantage compared to Hg is that it is more popular.

Re: What comes after Git

#127

Post by menaerus »

5e92cb50239222b wrote: post #45
dotancohen wrote: post #40

Earlier quoted context omitted.

> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

You must not ever work with junior developers. Rarely do I see a properly created commit history, what you usually get is something like: add upd fix upd fix Rebasing that stuff before merging it into master feels mandatory, or you're left with history with a very low signal-to-noise ratio.

> what you usually get is something like:

That's like 9 out of 10 people in my experience and none of them are juniors. It's pretty hard to get developers more disciplined.

Re: What comes after Git

#128

Post by nathants »

kjeetgill wrote: post #122
nathants wrote: post #90

git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m

Interesting exercise. Mine looks more like: - push/fetch: I personally never liked pull, it's sugar over fetch and merge/rebase. - checkout -b: haven't looked into all the switch stuff yet - rebase -i: my bread and butter. I rarely use merge aside from PRs where rebase bugs people. - add/commit -am: obviously required - cherry-pick/reset: pretty much replaces stash without introducing a whole new set of tools - diff/…

lately i’ve been using stash, reset hard, stash pop. work on a single patch over main.

use a backup branch prior to stash, just in case.

Re: What comes after Git

#129

Post by morelisp »

rswail wrote: post #59

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.

For magit users, there's https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.

Re: What comes after Git

#130

Post by bilekas »

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 as little time I end up needing to use the actual UI i really don't see the issue. This isn't the first time someone has complained about it either.

Reminds me of the slightly facetious anecdote that UI/UX has actually already been perfected so the complaints and problems you hear are just UI/UX people making work for themselves.

Post reply on HN