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

41–50 of 430 posts

Re: What comes after Git

#41

Post by nine_k »

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.

There absolutely is version control for rewriting commit history, no fancy tools needed.

Start another branch at the point where you want to rewrite history; don't switch to it: `git branch original-history-branch`.

Now `git rebase` your branch to your heart's content. This branch will have the new, rewritten history.

The original-history-branch still has your old history, refers to your old commits and prevents them from being garbage-collected, just in case you'd like to reset your target branch to that state.

Re: What comes after Git

#42

Post by japanuspus »

pgt wrote: post #15

Implicit branching in Pijul is a killer feature (IMO): https://pijul.org/

Yes, came here to plug Pijul as well: for distributed version control, the "first-class conflicts" of Pijul seems to be a step in the right direction.

For anyone who hasn't looked at Pijul, the theory part of the documentation [0] is well worth a read.

[0]: https://pijul.org/manual/theory.html

Re: What comes after Git

#43

Post by funklute »

gspr wrote: post #27
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…

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.

> And do you seriously not see the need of rebasing?

Rebasing isn't actually necessary, and there's a good argument to be made that you should never rebase. Fossil (the version control system used by the sqlite team) doesn't have any rebasing mechanism: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

(there are of course also very good arguments in favour of rebasing, but my point is simply that it isn't strictly necessary in a "complete" version control system)

Re: What comes after Git

#44

Post by oivey »

dotancohen wrote: post #40
gspr wrote: post #27

Earlier quoted context omitted.

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.

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

Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable.

How does rebasing break bisect?

Re: What comes after Git

#45

Post by 5e92cb50239222b »

dotancohen wrote: post #40
gspr wrote: post #27

Earlier quoted context omitted.

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.

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

Re: What comes after Git

#47

Post by Akronymus »

saxonww wrote: post #36
kadoban wrote: post #25

Earlier quoted context omitted.

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.

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?

Re: What comes after Git

#48

Post by Akronymus »

nine_k wrote: post #38
5e92cb50239222b wrote: post #31

Earlier quoted context omitted.

> Git is slow on large repos, even on an SSD. Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.

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

maybe this is of interest to you? https://github.blog/2022-06-29-improve-git-monorepo-performa...

Re: What comes after Git

#49

Post by Akronymus »

bergenty wrote: post #8
stellalo wrote: 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 use stashes all the time, when I realize I am working on the wrong branch.
Post reply on HN