
Git9: Git Reimagined for the Plan 9 OS - adamnemecek
https://bitbucket.org/oridb/git9
======
tomohawk
> 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
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.

~~~
pytyper2
Same here. Without staging how do I change 10 files but only commit 3 of them?
For example working on a change, then notice a bug that should be fixed now.
Currently I just stage the 3 files for the hot bug fix, commit those, deploy,
then continue working on the remaining 7 files.

~~~
war1025
I wonder how much overlap there is between the "staging area is useless" and
the "never rewrite history" crowds.

Personally, I use staging area all the time to create a curated set of commits
that make logical sense when putting them up for review.

My workflow is generally to keep a very messy history of `XXX` commits until I
am happy with what I've come up with. Then reset back to the branch point and
using the staging area to build up logical changesets.

I don't care about the history of my coming up with the solution, I care about
presenting the solution in a way that makes sense to reviewers, including
future me.

~~~
ori_b
Interesting, so you commit things that are different from the code that is
sitting in your working directory at the time of the commit?

~~~
war1025
I use `git add -p` to selectively pick out chunks of code that fit together
into commits.

Later on, if I notice that I messed something up, I'll create a fixup commit
and do an interactive rebase to squash it back into the correct commit.

~~~
e3b0c
In my opinion, `git add -p` should be the default, and a `-a` or alike to
forcibly commit the entire working tree. I have developed a habit that I
wouldn't feel comfortable if I haven't reviewed the chunks I am going to make
into the commit.

~~~
Rychard
While there are many people who don't understand git's staging area, there are
far less that understand how to selectively stage/commit chunks, or even that
such functionality is available at all.

It should be a crime for people to blindly stage everything. Cleaning up after
my colleagues easily falls under the "lost cause" umbrella.

------
deathanatos
> _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?

~~~
stonogo
> 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
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"

------
snazz
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_...](https://lobste.rs/s/bpzl12/git_fs_native_git_implementation_for_plan)

------
uranusjr
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
Next you are going propose that most of the plan 9 commands should change
their names because they are not POSIX?

~~~
uranusjr
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”.

------
Quarrel
wtf. plan9 is still alive?

There's a name I haven't seen since 1995.

(Vale dhog)

~~~
dexen
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
There's also [https://harvey-os.org/](https://harvey-os.org/)

