4 ms·

> 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,

> 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"
- Izkata 8y ago
  > but I'm interested in this implementation. From the user-visible side, it sounds like svn's tracked files, which trip up my co-workers more than git's staging area despite having used svn much longer.
brmgb 8y ago
> that sounds an awful lot like something one might call a "staging" area. Not at all. When you stage something in Git, you add a snapshot of the current version to the staging area. If you modify the file after doing "git add", the new modification will not be committed. Reading this discussion, I think a lot of people use git with a precise workflow from which they never diverge and don't actually know the tool that well. There are plenty of very surprising design decisions in git.

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"
Izkata 8y ago
> but I'm interested in this implementation. From the user-visible side, it sounds like svn's tracked files, which trip up my co-workers more than git's staging area despite having used svn much longer.

brmgb 8y ago

> that sounds an awful lot like something one might call a "staging" area. Not at all. When you stage something in Git, you add a snapshot of the current version to the staging area. If you modify the file after doing "git add", the new modification will not be committed. Reading this discussion, I think a lot of people use git with a precise workflow from which they never diverge and don't actually know the tool that well. There are plenty of very surprising design decisions in git.