←back to thread

848 points thefilmore | 8 comments | | HN request time: 1.892s | source | bottom
Show context
bandrami ◴[] No.43969975[source]
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
replies(29): >>43969999 #>>43970002 #>>43970008 #>>43970018 #>>43970019 #>>43970028 #>>43970031 #>>43970032 #>>43970036 #>>43970037 #>>43970142 #>>43970154 #>>43970198 #>>43970282 #>>43970314 #>>43970343 #>>43970418 #>>43970419 #>>43970431 #>>43970434 #>>43970451 #>>43970472 #>>43970541 #>>43970904 #>>43971268 #>>43971299 #>>43971387 #>>43971586 #>>43988717 #
IshKebab ◴[] No.43970002[source]
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them.

Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)

replies(3): >>43970054 #>>43970113 #>>43970150 #
mhh__ ◴[] No.43970113[source]
Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.
replies(3): >>43970148 #>>43970157 #>>43970328 #
kace91 ◴[] No.43970148[source]
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
replies(3): >>43970331 #>>43970946 #>>43974284 #
1. eru ◴[] No.43970331[source]
Pull requests are great, but the typical github UI isn't necessarily the best way to review code.

It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.

replies(1): >>43974277 #
2. mhh__ ◴[] No.43974277[source]
No, they're terrible. We should be reviewing stacks of commits not branches
replies(1): >>43977227 #
3. IshKebab ◴[] No.43977227[source]
Why? A branch is a stack of commits.
replies(2): >>43977997 #>>43987967 #
4. Dylan16807 ◴[] No.43977997{3}[source]
The workflow I believe they're talking about is like a branch but you can have multiple versions of the branch as you develop and refine it.

And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.

5. mhh__ ◴[] No.43987967{3}[source]
Then whence merge commits?

A branch is a commit with a hat on, strictly speaking.

replies(1): >>43990972 #
6. eru ◴[] No.43990972{4}[source]
Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'.

Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)

And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.

replies(1): >>43991327 #
7. mhh__ ◴[] No.43991327{5}[source]
They are often called stacked diffs yes.
replies(1): >>43991813 #
8. eru ◴[] No.43991813{6}[source]
Basically in terms of git speak branches are mutable pointers to immutable commits. (They are basically the only mutable thing in git.)

What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.

Once you have that, you could build all the convenient operations on top of that abstraction.

Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.

I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.