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

111–120 of 430 posts

Re: What comes after Git

#111

Post by 8n4vidtmkvmk »

indy wrote: post #69
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…

I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?

hg up --clean

i dont know why mercurial doesn't get more love.

Re: What comes after Git

#112

Post by midenginedcoupe »

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 structures, etc., ect.), but I see git as exactly the same.

I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions?

Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.

Re: What comes after Git

#113

Post by dreamcompiler »

Akronymus wrote: post #49
bergenty wrote: post #8

Earlier quoted context omitted.

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the vers…

I use stashes all the time, when I realize I am working on the wrong branch.

Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files.

To me, rebases are the work of the devil and I never use them. To each their own I guess.

Re: What comes after Git

#114

Post by arxanas »

torginus wrote: post #13

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

You might be interested in my project git-branchless https://github.com/arxanas/git-branchless or the Git-compatible Jujutsu SCM https://github.com/martinvonz/jj, both of which have version control for commit history via an operation log. Both feature sensible `undo` commands.

Re: What comes after Git

#115

Post by tsimionescu »

shikoba wrote: post #99
saxonww wrote: post #36

Earlier quoted context omitted.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

> It's when you move a file and make substantial edits that it gets confused. It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.

People "cling desperately" to the way they are actually working. That Git uses an alien model that happens to somewhat match what I'm doing doesn't mean I'm "desperately clinging" to the actual reality of what I'm doing (editing a file).

Re: What comes after Git

#116

Post by tsimionescu »

Akronymus wrote: post #47
saxonww wrote: post #36

Earlier quoted context omitted.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

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.

Re: What comes after Git

#117

Post by zaphirplane »

hackernewds wrote: post #91
enasterosophes wrote: post #52

Earlier quoted context omitted.

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…

The skills necessary to solve a problem, are also the skills necessary to realize there is one in the first place.

I’ve got one, poverty I realise the problem no idea and I bet no one here has an idea how to fix it without breaking a lot of other things

The list goes on

Re: What comes after Git

#119

Post by dreamcompiler »

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.

The solution for this is not rewriting history but writing a smarter history viewing tool that filters out the noise.

Re: What comes after Git

#120

Post by pizza234 »

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…

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 strange warts (e.g. adding with --patch doesn't include files not in the index; displaying the content a given stash entry requires typing the whole - unnecessarily complex - entry name), which I don't doubt make sense technically, but from a user perspective, they're odd.

There's probably a lot of stuff that one can find, depending on how wide their usage is. For example, I actually didn't realize how convenient patched (--patch) unstaging would be, since I typically perform a reset, then add (--patch) again.

I've personally never got past the feeeling that, not frequently but still with some frequence, git operations have a byzantine UX.

edit: find the merge commit of a given commit is something also very missed; it requires a non-trivial alias.

Post reply on HN