10 ms·

Git9: Git Reimagined for the Plan 9 OS

71 points by adamnemecek 8y ago

Quarrel 8y ago
wtf. plan9 is still alive? There's a name I haven't seen since 1995. (Vale dhog)
- dexen 8y ago
  There's a community fork named `9front' [1]. Most of the development happens in its community (IRC, mailing list). Expect some hermetic memes. [1] http://9front.org/ http://9front.org/
  - meruru 8y ago
    There's also https://harvey-os.org/ https://harvey-os.org/
  - all2 8y ago
    So that was a rabbit hole if there ever was one. The Thai code of conduct got me. I think it was Thai, anyway. The arguments they make for the actual system make sense to me and I want to see what else exists on the OS research front.
- f2f 8y ago
  you get a bonus point for mentioning dhog, may he rest in peace.
  - Quarrel 8y ago
    He gave a good steer to an aspiring grad student, which meant I only ever spent a summer on plan9 things. He was a gentle, nice and talented guy. :(
snazz 8y ago
There’s some good additional commentary in the body of the Lobsters post from the author, including why they wrote it and why not libgit2: https://lobste.rs/s/bpzl12/git_fs_native_git_implementation_for_plan https://lobste.rs/s/bpzl12/git_fs_native_git_implementation_...
tomohawk 8y ago
> The most obvious difference is that Git's index is a bit boneheaded, so I'm ignoring it. > In fact, the entire concept of the staging area has been dropped, as it's both confusing and clunky. Sounds like its on the right track.
- phs2501 8y ago
  Opinions obviously vary. The staging area is one of the most useful things about Git for me, and I use it just about every day.
  - ori_b 8y ago
    But I've got some usability studies to back the anti-staging stance up. Take a look at the research by the gitless folks: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf, https://gitless.com/ https://gitless.com/
    - fxfan 8y ago
      This shows what's wrong with neo-hacker news. Actual scientific studies are downvoted and guessworks and 'anecdata' are upvoted. Truly jumped the shark.
      - theamk 8y ago
        Have you read the paper, especially their study design?(p11/302 is a good summary, also last 5 pages for actual instructions). They have sample size of 10 people, and they specifically choose a very basic workflow. This study design is a real problem -- even after I have read the paper, I am not convinced that I should be using gitless. Their graph looks science-y, but the small sample size and non-representative experiment design means the conclusion do not apply to my work. Reading this paper is reading a DB benchmark which only used rows with two integer fields in all their tests. Sure, it is interesting reading, but unless your workflow is exactly that, it is useless in real life. (Disclaimer: it is entirely possible that gitless is better than git in all workflows, not just the one described in the paper. But even if it is the case, I would not know about it, at least not from the gitless site.)
uranusjr 8y ago
Anyone else wondering about the name? I’m OK with the absence of staging area, but with such a fundamental change why would it still call itself “Git”? A name like (say) Tig would keep the Git reference alive, but make it obvious the two are different.
- jxy 8y ago
  Next you are going propose that most of the plan 9 commands should change their names because they are not POSIX?
  - uranusjr 8y ago
    That’s a very slippery slope. Most of their tools would be just fine since the notions predate POSIX, and people already expect incompatibilities across platforms (plus Plan 9 ones more or less work similarly as their counterparts). Naming a new not-really-Git thing Git causes more confusion than benefits because Git is not a standard but a “product”.
- jcrites 8y ago
  Tig is an existing text mode interface for working with Git, FYI. A pretty useful tool: https://github.com/jonas/tig https://github.com/jonas/tig
deathanatos 8y ago
> The most obvious difference is that Git's index is a bit boneheaded, so I'm ignoring it. > In fact, the entire concept of the staging area has been dropped, as it's both confusing and clunky. There are now only three states that files can be in: 'untracked', 'dirty', and 'committed'. > Some usage examples: git/add foo.c So… what does `git/add` do? > Tells the repository to add a file to the next commit. And wherever that information is stored, so that between running `git/add` and `git/commit`, we can remember what things are going to be part of the commit… that sounds an awful lot like something one might call a "staging" area. How have we not reinvented it here?
- ori_b 8y ago
  What happens if you change foo.c after adding it? And that's the real issue at hand.
- gcb0 8y ago
  > no staging area > we invented a new state "included in next commit but not called stage" impressive.
  - Dylan16807 8y ago
    A list of what files to include is very different from an invisible arbitrary data tree.
- stonogo 8y ago
  > that sounds an awful lot like something one might call a "staging" area. What you call it is one thing. The actual code behind git's official "staging" implementation is basically an entire magical branch on-disk. The staging code is a big part of why git submodules are so awkward. I don't even use Plan 9, but I'm interested in this implementation.
  - ori_b 8y ago
    And that's before you take into account that the staging area's index makes some very interesting decisions: - Maximum file size of 4g -- but this limit is only present in the staging area, which means it's possible to construct repos with files that can't be checked out into the index. - Dates have the year 2038 problem. - Contains non-portable stat fields like the device the file was on. - Requires a complete rewrite of the whole index file on every change, making it scale O(n) in the size of the repository. - Requires padding of data fields to 8 bytes -- but then has 12 byte header which the fields are packed after, making all of them misaligned to 4 bytes. The whole thing screams "thoughtless, bleary-eyed 3 AM hack"

71 points by adamnemecek 8y ago

Quarrel 8y ago

wtf. plan9 is still alive? There's a name I haven't seen since 1995. (Vale dhog)

dexen 8y ago
There's a community fork named `9front' [1]. Most of the development happens in its community (IRC, mailing list). Expect some hermetic memes. [1] http://9front.org/ http://9front.org/
- meruru 8y ago
  There's also https://harvey-os.org/ https://harvey-os.org/
- all2 8y ago
  So that was a rabbit hole if there ever was one. The Thai code of conduct got me. I think it was Thai, anyway. The arguments they make for the actual system make sense to me and I want to see what else exists on the OS research front.
f2f 8y ago
you get a bonus point for mentioning dhog, may he rest in peace.
- Quarrel 8y ago
  He gave a good steer to an aspiring grad student, which meant I only ever spent a summer on plan9 things. He was a gentle, nice and talented guy. :(

snazz 8y ago

There’s some good additional commentary in the body of the Lobsters post from the author, including why they wrote it and why not libgit2: https://lobste.rs/s/bpzl12/git_fs_native_git_implementation_for_plan https://lobste.rs/s/bpzl12/git_fs_native_git_implementation_...

tomohawk 8y ago

phs2501 8y ago
Opinions obviously vary. The staging area is one of the most useful things about Git for me, and I use it just about every day.
- ori_b 8y ago
  But I've got some usability studies to back the anti-staging stance up. Take a look at the research by the gitless folks: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf, https://gitless.com/ https://gitless.com/
  - fxfan 8y ago
    This shows what's wrong with neo-hacker news. Actual scientific studies are downvoted and guessworks and 'anecdata' are upvoted. Truly jumped the shark.
    - theamk 8y ago
      Have you read the paper, especially their study design?(p11/302 is a good summary, also last 5 pages for actual instructions). They have sample size of 10 people, and they specifically choose a very basic workflow. This study design is a real problem -- even after I have read the paper, I am not convinced that I should be using gitless. Their graph looks science-y, but the small sample size and non-representative experiment design means the conclusion do not apply to my work. Reading this paper is reading a DB benchmark which only used rows with two integer fields in all their tests. Sure, it is interesting reading, but unless your workflow is exactly that, it is useless in real life. (Disclaimer: it is entirely possible that gitless is better than git in all workflows, not just the one described in the paper. But even if it is the case, I would not know about it, at least not from the gitless site.)

uranusjr 8y ago

Anyone else wondering about the name? I’m OK with the absence of staging area, but with such a fundamental change why would it still call itself “Git”? A name like (say) Tig would keep the Git reference alive, but make it obvious the two are different.

jxy 8y ago
Next you are going propose that most of the plan 9 commands should change their names because they are not POSIX?
- uranusjr 8y ago
  That’s a very slippery slope. Most of their tools would be just fine since the notions predate POSIX, and people already expect incompatibilities across platforms (plus Plan 9 ones more or less work similarly as their counterparts). Naming a new not-really-Git thing Git causes more confusion than benefits because Git is not a standard but a “product”.
jcrites 8y ago
Tig is an existing text mode interface for working with Git, FYI. A pretty useful tool: https://github.com/jonas/tig https://github.com/jonas/tig

deathanatos 8y ago

> The most obvious difference is that Git's index is a bit boneheaded, so I'm ignoring it. > In fact, the entire concept of the staging area has been dropped, as it's both confusing and clunky. There are now only three states that files can be in: 'untracked', 'dirty', and 'committed'. > Some usage examples: git/add foo.c So… what does `git/add` do? > Tells the repository to add a file to the next commit. And wherever that information is stored, so that between running `git/add` and `git/commit`, we can remember what things are going to be part of the commit… that sounds an awful lot like something one might call a "staging" area. How have we not reinvented it here?

ori_b 8y ago
What happens if you change foo.c after adding it? And that's the real issue at hand.
gcb0 8y ago
> no staging area > we invented a new state "included in next commit but not called stage" impressive.
- Dylan16807 8y ago
  A list of what files to include is very different from an invisible arbitrary data tree.
stonogo 8y ago
> that sounds an awful lot like something one might call a "staging" area. What you call it is one thing. The actual code behind git's official "staging" implementation is basically an entire magical branch on-disk. The staging code is a big part of why git submodules are so awkward. I don't even use Plan 9, but I'm interested in this implementation.
- ori_b 8y ago
  And that's before you take into account that the staging area's index makes some very interesting decisions: - Maximum file size of 4g -- but this limit is only present in the staging area, which means it's possible to construct repos with files that can't be checked out into the index. - Dates have the year 2038 problem. - Contains non-portable stat fields like the device the file was on. - Requires a complete rewrite of the whole index file on every change, making it scale O(n) in the size of the repository. - Requires padding of data fields to 8 bytes -- but then has 12 byte header which the fields are packed after, making all of them misaligned to 4 bytes. The whole thing screams "thoughtless, bleary-eyed 3 AM hack"