8 ms·

GitHub Trip Report

195 points by networked 7y ago

allenbrunson 7y ago
boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. to me, this kind of result is the most compelling argument that the world of high tech isn't nearly so much a meritocracy as it is made out to be.
- masklinn 7y ago
  > boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. git is not complex though. It just has an absolutely godawful "high-level" user interface. Porcelain (high-level commands) are really shortcuts on sets of low-level operations usually performed together, which is why e.g. `checkout` is used simultanously for reverting working copy chances and switching the entire thing to arbitrary commits or branches. That also makes git extremely hard to learn "top down" beyond rote learning of a few commands: from that POV the CLI is completely incoherent so you can't really build an intuition for what command could do what operation. The terrible naming doesn't help either. If you have the time and desire to start from the on-disk storage (ignoring packfiles) you can build your own in a few hours.
  - Smaug123 7y ago
    This is slowly improving, at least; `git switch` is now a thing, for example. https://git-scm.com/docs/git-switch/2.23.0 https://git-scm.com/docs/git-switch/2.23.0
    - capableweb 7y ago
      At a glance, it seems to do the same as `git checkout` and `git checkout -b`. Can someone give a TLDR about the difference? Edit: gonna be fun to see how guides like https://www.atlassian.com/git/tutorials/using-branches/git-checkout https://www.atlassian.com/git/tutorials/using-branches/git-c... are becoming outdated in a way where switching/checking out doesn't mean the same thing anymore, but the article uses them interchangeably
      - masklinn 7y ago
        These three invocations are not present in switch: git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>… git checkout [<tree-ish>] [--] <pathspec>… git checkout (-p|--patch) [<tree-ish>] [--] [<paths>… ] That is, aside to / on top of the ability to switch to a specific branch or commit, checkout * is used to revert working tree changes, possibly interactively * is used to set working tree changes to either side of a merge (in case of conflict) * is used to revert specific local paths to a historical version thereof, possibly interactively
  - pnako 7y ago
    Regarding the last point: some OpenBSD developers are currently writing their own front end ("got") using the same on-disk structure as git. http://gameoftrees.org/goals.html http://gameoftrees.org/goals.html
    - masklinn 7y ago
      That looks interesting. However there have been lots of "porcelain replacements" efforts in the past, but most of them either were abandoned because by the time they'd built something complete enough the author had had to so deeply understand the underlying model they could use the official fine, or remained niche because they were extremely opinionated (and limited) with respect to the workflows they'd support.
      - lima 7y ago
        The point of that project is to create a BSD-licensed Git clone, not build better porcelain.
        wolrah 7y ago
        Nah, the point is definitely not to create a Git clone. They're developing their own system designed around a more centralized structure than Git (closer to CVS/SVN), but remaining compatible with Git on disk.
- orhmeh09 7y ago
  I encourage you to read its source code, a mishmash of several dialects of tcl, html and js and sql inlined in c, etc. I made an effort to use fossil throughout the summer, but lack of tooling + a lot more git experience caused me to abandon it except for some existing repositories. Note, I have tremendous respect for the authors of fossil and I hope for its success in the long term.
avip 7y ago
Winners are not about who's best. Git is not better than hg, Koalas are not better than giant sloth, Windows is not better than linux. So? All major hosted scm dropped hg support. What op tries to do seems emphatically Quijote-ish
- nindalf 7y ago
  Isn't the English word Quixotic?
  - avip 7y ago
    I don't know and welcome any correction to my grammar or spelling.
  - drmclean 7y ago
    yes! it is although it's relatively obscure. (native English speaker here.)
- matwood 7y ago
  Best is a subjective term. When Windows won the desktop it was the best at running MS Office. I don't know enough about hg to say how git is better, but I'm sure there are areas where git excels. From what I've read hg has a better cli, but that alone may not be enough to be the 'best'.
  - dochtman 7y ago
    I maintain that GitHub itself is actually an important reason that Git won out.
fulafel 7y ago
His critique on Git rebase is spot on: https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...
- lars512 7y ago
  The moralising about it doesn't make much sense. In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. We had a proposal around commit standards at work recently: we came to the conclusion that rebasing your private branches and squashing out irrelevant commits is the recommended flow, to make reviews easier.
  - TeMPOraL 7y ago
    > In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. That's because you joined the "it's a story" camp without noticing. If you instead view git history as a sort of gentlemen's audit log, then "refactoring" it is indeed both lying and dishonorable. And in no other profession it would be OK to mess with something used for review / audit purposes. Personally, I'm in favor of the history/audit log view, because you can't predict today what information you may need in the future, and refactoring git history throws away a lot of historical context.
    - Vinnl 7y ago
      Not GP, but I'm certainly in the story camp. My commit history is not an audit log, it's documentation about the choices I made while writing my code, and a tool that helps me combine relevant parts. In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. (Unless Fossil/whatever system you're using stores every character you ever type - I'm not familiar with it.) Edit: To use an example from the article: > Yet, sometimes we come upon a piece of code that we simply cannot understand. If you have never asked yourself, “What was this code’s developer thinking?” you haven’t been developing software for very long. With my commit, I'm telling other developers/my future self what I was thinking, rather than having them try to figure that out by themselves from my code. The assumption there is that I'm better at explaining my thinking than my code is.
jcims 7y ago
Maybe i’m crazy but i find it completely unremarkable that a GitHub strategy session leaves core git completely alone and instead focuses on improving the ecosystem around it.
- danpalmer 7y ago
  This doesn't surprise me in the slightest. Looking at GitHub product changes over the last few years (or even GitLab product changes), the core git components have been largely untouched. In fact I'd argue that the core git part of GitHub hasn't really changed since ~2-3 years into the company. This makes sense, because GitHub doesn't add value in "improving" the git part. Anyone can run a git server, and git itself doesn't really have much else to it. GitHub adds value in all the places around it. Collaboration, process, teams, communication, code review, security. These are things that most people using git will need, which are better when integrated or close to their version control system, and things that git doesn't address. As a GitHub user, I'm glad that this was what they focused on.
  - WAHa_06x36 7y ago
    I'd be less generous and say outright that GitHub benefits from git being a bad tool that NEEDS an external ecosystem to make it usable. Improving git itself goes directly against their interests.
    - saagarjha 7y ago
      Many of the things that GitHub adds are not things I see being part of Git.
holman 7y ago
This is a pretty interesting writeup, even though I don’t necessarily agree with everything. Makes you think, at least. I’ve been out of version control for a bit, and GitHub itself for quite a bit longer, but this part was interesting to me: > Because: It isn't really about Git anymore. GitHub used to be a Git repository hosting company. But now, they are about providing other software development and management infrastructure that augments the version control. They might as well change their name to Hub at this point. Just for added color: starting around 2010 or 2011 or so (around when we added Subversion to GitHub), we had a pretty solid idea that version control wasn’t “the thing”. Mostly because Mercurial was a strong alternative, and there always felt like there might be something new in the wings that could dominate in the next few years. Version control felt really dynamic, and deeply susceptible to change. And if something was better, we’d totally ditch Git for the new thing. The name was a bit of a misnomer, from that perspective. I think that changed over time — I had a hell of a time trying to get movement on basic version control improvements back in 2014 — and now they’re clearly much more about the ecosystem rather than version control itself. It’s where the money is, of course, but it’s also where the bigger innovation is, at least for the time being. I think the author is right to say that Microsoft is targeting a different area than version control specifically, though you could argue if the outcome of that is good or bad. It’s certainly different, though- they’re especially growing headcount right now, and the company makeup is wildly different than what many customers tend think it is today, imo.
- deleted 7y ago
  [deleted]
- souterrain 7y ago
  > Because: It isn't really about Git anymore. GitHub used to be a Git repository hosting company. But now, they are about providing other software development and management infrastructure that augments the version control. They might as well change their name to Hub at this point. I agree fully, but the one "feature" missing from drh's analysis is GitHub's social aspect. Getting code out in front of people and allowing them to interact with it (directly, via commits and PRs, or indirectly, via issue comments) as a feature of a social network is their differentiator. GitHub's choice of git wasn't germane to building a social network: GitHub could have been successful using svn, excepting that git was ascendant at the time. Fossil's feature of an integrated web server is an anti-feature to GitHub; it defeats the purpose of having a centralised "Hub."
glloydell 7y ago
Seems to be misfiled, trip reports generally should be under https://www.erowid.org/ https://www.erowid.org/
chx 7y ago
> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important. This is one thing (but not the only thing) that I intensely dislike about git vs bzr. Loglevels are not particularly new and can be applied so directly to the VCS log that bzr log has a level option.
pdq 7y ago
In case people are unaware, drh is Richard Hipp, aka the author of SQLite and Fossil. https://en.m.wikipedia.org/wiki/D._Richard_Hipp https://en.m.wikipedia.org/wiki/D._Richard_Hipp
- Nicksil 7y ago
  Non-mobile: https://en.wikipedia.org/wiki/D._Richard_Hipp https://en.wikipedia.org/wiki/D._Richard_Hipp
cryptonector 7y ago
IDK who D. R. Hip thinks agrees that rebasing is bad, but I sure as heck don't. Rebasing is good on private branches: it lets you write clean linear history. Conversely, intra-project-branch history is of little or no interest whatsoever once pushed upstream. Rebasing published branches is not a good thing, of course, but fans of rebasing don't propose that.
weinzierl 7y ago
> The GitHub staff says that the four pillars of their organization are > 1. DevOps > 2. Security > 3. Collaboration > 4. Insights Interesting to see "Security" as number two.

195 points by networked 7y ago

boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. to me, this kind of result is the most compelling argument that the world of high tech isn't nearly so much a meritocracy as it is made out to be.

masklinn 7y ago
> boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. git is not complex though. It just has an absolutely godawful "high-level" user interface. Porcelain (high-level commands) are really shortcuts on sets of low-level operations usually performed together, which is why e.g. `checkout` is used simultanously for reverting working copy chances and switching the entire thing to arbitrary commits or branches. That also makes git extremely hard to learn "top down" beyond rote learning of a few commands: from that POV the CLI is completely incoherent so you can't really build an intuition for what command could do what operation. The terrible naming doesn't help either. If you have the time and desire to start from the on-disk storage (ignoring packfiles) you can build your own in a few hours.
- Smaug123 7y ago
  This is slowly improving, at least; `git switch` is now a thing, for example. https://git-scm.com/docs/git-switch/2.23.0 https://git-scm.com/docs/git-switch/2.23.0
  - capableweb 7y ago
    At a glance, it seems to do the same as `git checkout` and `git checkout -b`. Can someone give a TLDR about the difference? Edit: gonna be fun to see how guides like https://www.atlassian.com/git/tutorials/using-branches/git-checkout https://www.atlassian.com/git/tutorials/using-branches/git-c... are becoming outdated in a way where switching/checking out doesn't mean the same thing anymore, but the article uses them interchangeably
    - masklinn 7y ago
      These three invocations are not present in switch: git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>… git checkout [<tree-ish>] [--] <pathspec>… git checkout (-p|--patch) [<tree-ish>] [--] [<paths>… ] That is, aside to / on top of the ability to switch to a specific branch or commit, checkout * is used to revert working tree changes, possibly interactively * is used to set working tree changes to either side of a merge (in case of conflict) * is used to revert specific local paths to a historical version thereof, possibly interactively
- pnako 7y ago
  Regarding the last point: some OpenBSD developers are currently writing their own front end ("got") using the same on-disk structure as git. http://gameoftrees.org/goals.html http://gameoftrees.org/goals.html
  - masklinn 7y ago
    That looks interesting. However there have been lots of "porcelain replacements" efforts in the past, but most of them either were abandoned because by the time they'd built something complete enough the author had had to so deeply understand the underlying model they could use the official fine, or remained niche because they were extremely opinionated (and limited) with respect to the workflows they'd support.
    - lima 7y ago
      The point of that project is to create a BSD-licensed Git clone, not build better porcelain.
      - wolrah 7y ago
        Nah, the point is definitely not to create a Git clone. They're developing their own system designed around a more centralized structure than Git (closer to CVS/SVN), but remaining compatible with Git on disk.
orhmeh09 7y ago
I encourage you to read its source code, a mishmash of several dialects of tcl, html and js and sql inlined in c, etc. I made an effort to use fossil throughout the summer, but lack of tooling + a lot more git experience caused me to abandon it except for some existing repositories. Note, I have tremendous respect for the authors of fossil and I hope for its success in the long term.

avip 7y ago

Winners are not about who's best. Git is not better than hg, Koalas are not better than giant sloth, Windows is not better than linux. So? All major hosted scm dropped hg support. What op tries to do seems emphatically Quijote-ish

nindalf 7y ago
Isn't the English word Quixotic?
- avip 7y ago
  I don't know and welcome any correction to my grammar or spelling.
- drmclean 7y ago
  yes! it is although it's relatively obscure. (native English speaker here.)
matwood 7y ago
Best is a subjective term. When Windows won the desktop it was the best at running MS Office. I don't know enough about hg to say how git is better, but I'm sure there are areas where git excels. From what I've read hg has a better cli, but that alone may not be enough to be the 'best'.
- dochtman 7y ago
  I maintain that GitHub itself is actually an important reason that Git won out.

fulafel 7y ago

His critique on Git rebase is spot on: https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...

lars512 7y ago
The moralising about it doesn't make much sense. In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. We had a proposal around commit standards at work recently: we came to the conclusion that rebasing your private branches and squashing out irrelevant commits is the recommended flow, to make reviews easier.
- TeMPOraL 7y ago
  > In other professions, it's not "lying" or "dishonorable" to present your work in the most clear and understandable way to others, it's a basic condition for entry. I don't see how software's any different. That's because you joined the "it's a story" camp without noticing. If you instead view git history as a sort of gentlemen's audit log, then "refactoring" it is indeed both lying and dishonorable. And in no other profession it would be OK to mess with something used for review / audit purposes. Personally, I'm in favor of the history/audit log view, because you can't predict today what information you may need in the future, and refactoring git history throws away a lot of historical context.
  - Vinnl 7y ago
    Not GP, but I'm certainly in the story camp. My commit history is not an audit log, it's documentation about the choices I made while writing my code, and a tool that helps me combine relevant parts. In fact, I'm sure that you're lying too: every time you Ctrl+Z in between commits, you're removing parts of your audit log. Choosing when to commit is telling a story. (Unless Fossil/whatever system you're using stores every character you ever type - I'm not familiar with it.) Edit: To use an example from the article: > Yet, sometimes we come upon a piece of code that we simply cannot understand. If you have never asked yourself, “What was this code’s developer thinking?” you haven’t been developing software for very long. With my commit, I'm telling other developers/my future self what I was thinking, rather than having them try to figure that out by themselves from my code. The assumption there is that I'm better at explaining my thinking than my code is.

jcims 7y ago

Maybe i’m crazy but i find it completely unremarkable that a GitHub strategy session leaves core git completely alone and instead focuses on improving the ecosystem around it.

danpalmer 7y ago
This doesn't surprise me in the slightest. Looking at GitHub product changes over the last few years (or even GitLab product changes), the core git components have been largely untouched. In fact I'd argue that the core git part of GitHub hasn't really changed since ~2-3 years into the company. This makes sense, because GitHub doesn't add value in "improving" the git part. Anyone can run a git server, and git itself doesn't really have much else to it. GitHub adds value in all the places around it. Collaboration, process, teams, communication, code review, security. These are things that most people using git will need, which are better when integrated or close to their version control system, and things that git doesn't address. As a GitHub user, I'm glad that this was what they focused on.
- WAHa_06x36 7y ago
  I'd be less generous and say outright that GitHub benefits from git being a bad tool that NEEDS an external ecosystem to make it usable. Improving git itself goes directly against their interests.
  - saagarjha 7y ago
    Many of the things that GitHub adds are not things I see being part of Git.

holman 7y ago

This is a pretty interesting writeup, even though I don’t necessarily agree with everything. Makes you think, at least. I’ve been out of version control for a bit, and GitHub itself for quite a bit longer, but this part was interesting to me: > Because: It isn't really about Git anymore. GitHub used to be a Git repository hosting company. But now, they are about providing other software development and management infrastructure that augments the version control. They might as well change their name to Hub at this point. Just for added color: starting around 2010 or 2011 or so (around when we added Subversion to GitHub), we had a pretty solid idea that version control wasn’t “the thing”. Mostly because Mercurial was a strong alternative, and there always felt like there might be something new in the wings that could dominate in the next few years. Version control felt really dynamic, and deeply susceptible to change. And if something was better, we’d totally ditch Git for the new thing. The name was a bit of a misnomer, from that perspective. I think that changed over time — I had a hell of a time trying to get movement on basic version control improvements back in 2014 — and now they’re clearly much more about the ecosystem rather than version control itself. It’s where the money is, of course, but it’s also where the bigger innovation is, at least for the time being. I think the author is right to say that Microsoft is targeting a different area than version control specifically, though you could argue if the outcome of that is good or bad. It’s certainly different, though- they’re especially growing headcount right now, and the company makeup is wildly different than what many customers tend think it is today, imo.

deleted 7y ago
[deleted]
souterrain 7y ago
> Because: It isn't really about Git anymore. GitHub used to be a Git repository hosting company. But now, they are about providing other software development and management infrastructure that augments the version control. They might as well change their name to Hub at this point. I agree fully, but the one "feature" missing from drh's analysis is GitHub's social aspect. Getting code out in front of people and allowing them to interact with it (directly, via commits and PRs, or indirectly, via issue comments) as a feature of a social network is their differentiator. GitHub's choice of git wasn't germane to building a social network: GitHub could have been successful using svn, excepting that git was ascendant at the time. Fossil's feature of an integrated web server is an anti-feature to GitHub; it defeats the purpose of having a centralised "Hub."

glloydell 7y ago

Seems to be misfiled, trip reports generally should be under https://www.erowid.org/ https://www.erowid.org/

chx 7y ago

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important. This is one thing (but not the only thing) that I intensely dislike about git vs bzr. Loglevels are not particularly new and can be applied so directly to the VCS log that bzr log has a level option.

pdq 7y ago

In case people are unaware, drh is Richard Hipp, aka the author of SQLite and Fossil. https://en.m.wikipedia.org/wiki/D._Richard_Hipp https://en.m.wikipedia.org/wiki/D._Richard_Hipp

Nicksil 7y ago
Non-mobile: https://en.wikipedia.org/wiki/D._Richard_Hipp https://en.wikipedia.org/wiki/D._Richard_Hipp

cryptonector 7y ago

IDK who D. R. Hip thinks agrees that rebasing is bad, but I sure as heck don't. Rebasing is good on private branches: it lets you write clean linear history. Conversely, intra-project-branch history is of little or no interest whatsoever once pushed upstream. Rebasing published branches is not a good thing, of course, but fans of rebasing don't propose that.

weinzierl 7y ago

> The GitHub staff says that the four pillars of their organization are > 1. DevOps > 2. Security > 3. Collaboration > 4. Insights Interesting to see "Security" as number two.