Most active commenters
  • mhh__(5)
  • eru(3)

←back to thread

Mozilla Firefox – Official GitHub repo

(github.com)
848 points thefilmore | 11 comments | 13 May 25 05:23 UTC | HN request time: 1.769s | source | bottom
Show context
bandrami ◴[13 May 25 06:03 UTC] 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 ◴[13 May 25 06:08 UTC] 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__ ◴[13 May 25 06:36 UTC] 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 #
1. kace91 ◴[13 May 25 06:42 UTC] 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 #
2. eru ◴[13 May 25 07:08 UTC] 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 #
3. baq ◴[13 May 25 08:59 UTC] No.43970946[source]▶
It’s only good if you haven’t tried anything else. Check out gerrit, but there are many more tools and workflows.

Note we’re talking about the GitHub UI mostly. Pulling and merging a remote branch is a basic git operation, almost a primitive.

4. mhh__ ◴[13 May 25 15:52 UTC] No.43974277[source]▶
No, they're terrible. We should be reviewing stacks of commits not branches
replies(1): >>43977227 #
5. mhh__ ◴[13 May 25 15:52 UTC] No.43974284[source]▶
Phabricator.
6. IshKebab ◴[13 May 25 20:18 UTC] No.43977227{3}[source]▶
Why? A branch is a stack of commits.
replies(2): >>43977997 #>>43987967 #
7. Dylan16807 ◴[13 May 25 21:35 UTC] No.43977997{4}[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.

8. mhh__ ◴[14 May 25 18:50 UTC] No.43987967{4}[source]▶
Then whence merge commits?

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

replies(1): >>43990972 #
9. eru ◴[15 May 25 01:34 UTC] No.43990972{5}[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 #
10. mhh__ ◴[15 May 25 02:43 UTC] No.43991327{6}[source]▶
They are often called stacked diffs yes.
replies(1): >>43991813 #
11. eru ◴[15 May 25 04:22 UTC] No.43991813{7}[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.