Live data from Hacker News

What comes after Git

matt-rickard.com

21–30 of 430 posts

Re: What comes after Git

#21

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.

Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true.

`git reflog` contains a full history of all refs you’ve been on in chronological order. Unless you explicitly delete them, dangling refs are not cleaned up immediately. If you rewrite history and realise you made a mistake, you can likely recover by simply resetting the mutated branch to something from the reflog, even days or weeks afterwards (the default reflog retention is 30 days).

Re: What comes after Git

#23
post #19

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.

Doesn’t git reflog answer that?

It's local to a single repository, can't be pushed anywhere, and is collected periodically by git gc.

Re: What comes after Git

#24
post #8
post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

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’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.

Re: What comes after Git

#25
post #3

> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work. in case anyone missed it: https://github.co…

git mv?

That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.

Re: What comes after Git

#26

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.

which is why I love Mercurial as it's immutable by default. You have to try really hard to mess up your repository.

Re: What comes after Git

#27
post #8
post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

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…

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed.

And do you seriously not see the need of rebasing?

Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

Re: What comes after Git

#28
post #19

Earlier quoted context omitted.

Doesn’t git reflog answer that?

It's local to a single repository, can't be pushed anywhere, and is collected periodically by git gc.

I don’t see why OP would need any of that to undo an history rewrite they messed up.

Re: What comes after Git

#29

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.

The old commits with old comments are still there for a while and 'git reset --hard' can be used to get back to the old way. After a rebase there is a ref named ORIG_HEAD and a log in .git/logs/refs/heads (though I didn't really know that, I just went looking through my .git folder).

If you do a big force push on a remote repository you could keep the old stuff in a tag or a branch.

Re: What comes after Git

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

Post reply on HN