7 ms·

It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. We develop HighFlux[1] which also gets rid of the sta

It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. We develop HighFlux[1] which also gets rid of the staging area. It simplifies your mental model of what's going on a lot. Because everything you save is automatically committed, switching to a different task/branch is also always instant without needing stash. Because what you're testing locally is what you're committing, I also never have CI failures anymore (with the staging area I frequently had unexpected interactions with unstaged changes and sometimes even accidentally forgotten added files). 1: https://highflux.io/ https://highflux.io/

still_grokking 4y ago
Sounds like saying bye-bye to any meaningful history. Rebasing, cheery-picking, or reverting of commits becomes impossible when every save of a file is pushed. You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Why not go one step farther: Just make an automatic block image of the whole systems of every developer machine every few seconds. You could than just deliver the image. No docker setup needed any more. Just write code. And when the local version works, ship the whole local system just as it is. ;-)
- joshuamorton 4y ago
  > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Google does this, it has saved my butt on more than one occasion. > Sounds like saying bye-bye to any meaningful history. I'm so confused, you just amend the most recent commit, or work with changes unstaged and uncommited. Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working on the next thing, either back to HEAD if its unrelated, or on top of the just-pushed changes if it depends on them. It's vastly simpler than having to git add at random times.
  - still_grokking 4y ago
    > > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). > Google does this, it has saved my butt on more than one occasion. You mean backups? Yes, backups are a very good idea. But this has nothing to do with VCS. That are separate topics. > Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working As long as the requirements are so trivial even CVS would suffice. But even considerably simple refactorings (in e.g. static languages) can be much more complex. It's easy to end up with hundreds of files changed. Than you need more powerful tools. Doing such things without the staging area is almost impossible to get right. (The only alternative would be quite some rebase sessions; and those are way more complicated than using the staging area upfront; also you would need some way to do diffs against "pined" changes—which is something you get for free with the staging area).
    - joshuamorton 4y ago
      > You mean backups? Yes, backups are a very good idea. No, I mean that the filesystem I edit code in has a full snapshotted history of every save and I can recover to a particular revision or particular point in time, even one's that weren't committed to vcs[0]. I guess you can call that a "backup", but like it's not what people usually mean. I have used this to recover some things I was working on three months ago but ended up throwing away. (citation: > All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review. via https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) > It's easy to end up with hundreds of files changed. Sure, doing a rename can touch 100 files, but you should isolate that change to a commit and PR that don't do anything else. Running sed and then committing or using your IDE's refactor feature, and then committing and running tests doesn't require a staging area. [0]: The truly wild thing about this is that the vcs state is also stored in the snapshotted, point in time recoverable fs, so if you do the equivalent of absolutely botching your git history, you can jump back in time a few minutes and start from a known good state.
chungy 4y ago
> It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. Sorry, but no. "No staging area" is what VCSes were like before Git and it was worse, much worse.
- still_grokking 4y ago
  Would support that. The staging area is one of the things that make Git shine, imho. It would be very difficult to handle quite some "WIP situations" without the staging area.
  - alwillis 4y ago
    I think there’s some Stockholm Syndrome [1] thing going on with the staging area. It confuses noobies and it’s easy to make mistakes. I think we’ll be okay with this stack workflow [2] taken from Mercurial’s Evolve command [3]. [1]: https://en.wikipedia.org/wiki/Stockholm_syndrome https://en.wikipedia.org/wiki/Stockholm_syndrome [2]: https://sapling-scm.com/docs/overview/stacks https://sapling-scm.com/docs/overview/stacks [3]: https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html https://www.mercurial-scm.org/doc/evolution/tutorials/topic-...
    - chungy 4y ago
      > I think there’s some Stockholm Syndrome I lived through the alternative and the staging area is superior. If it wasn't, I might not be using Git, or at least begrudge when I have to; neither is the case.
      - guytv 4y ago
        Isn't the staging area just a stack of changes where stack height == 1?
        still_grokking 4y ago
        Sure. And a branch is also just a stack of changes… The whole point is that this things are treated differently.
guytv 4y ago
One of the problems with `git`, and it seems that Sapling is no different, is that there is no one-to-one mapping between the user intent and the underlying SCM. For a user intent of "implement feature X", there is no UI to "start a new feature". Instead, one has to translate their requirement to the SCM mental model and issue a series of commands to manipulate a DAG of blob hashes that live in 4 different places simultaneously. (work tree, index, local repository and the remote repository. Highflux allows a simple user requirement to action mapping.

still_grokking 4y ago

Sounds like saying bye-bye to any meaningful history. Rebasing, cheery-picking, or reverting of commits becomes impossible when every save of a file is pushed. You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Why not go one step farther: Just make an automatic block image of the whole systems of every developer machine every few seconds. You could than just deliver the image. No docker setup needed any more. Just write code. And when the local version works, ship the whole local system just as it is. ;-)

joshuamorton 4y ago
> You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Google does this, it has saved my butt on more than one occasion. > Sounds like saying bye-bye to any meaningful history. I'm so confused, you just amend the most recent commit, or work with changes unstaged and uncommited. Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working on the next thing, either back to HEAD if its unrelated, or on top of the just-pushed changes if it depends on them. It's vastly simpler than having to git add at random times.
- still_grokking 4y ago
  > > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). > Google does this, it has saved my butt on more than one occasion. You mean backups? Yes, backups are a very good idea. But this has nothing to do with VCS. That are separate topics. > Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working As long as the requirements are so trivial even CVS would suffice. But even considerably simple refactorings (in e.g. static languages) can be much more complex. It's easy to end up with hundreds of files changed. Than you need more powerful tools. Doing such things without the staging area is almost impossible to get right. (The only alternative would be quite some rebase sessions; and those are way more complicated than using the staging area upfront; also you would need some way to do diffs against "pined" changes—which is something you get for free with the staging area).
  - joshuamorton 4y ago
    > You mean backups? Yes, backups are a very good idea. No, I mean that the filesystem I edit code in has a full snapshotted history of every save and I can recover to a particular revision or particular point in time, even one's that weren't committed to vcs[0]. I guess you can call that a "backup", but like it's not what people usually mean. I have used this to recover some things I was working on three months ago but ended up throwing away. (citation: > All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review. via https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) > It's easy to end up with hundreds of files changed. Sure, doing a rename can touch 100 files, but you should isolate that change to a commit and PR that don't do anything else. Running sed and then committing or using your IDE's refactor feature, and then committing and running tests doesn't require a staging area. [0]: The truly wild thing about this is that the vcs state is also stored in the snapshotted, point in time recoverable fs, so if you do the equivalent of absolutely botching your git history, you can jump back in time a few minutes and start from a known good state.

chungy 4y ago

> It's really just a matter of habit and getting used to no staging area takes short and has huge benefits. Sorry, but no. "No staging area" is what VCSes were like before Git and it was worse, much worse.

still_grokking 4y ago
Would support that. The staging area is one of the things that make Git shine, imho. It would be very difficult to handle quite some "WIP situations" without the staging area.
- alwillis 4y ago
  I think there’s some Stockholm Syndrome [1] thing going on with the staging area. It confuses noobies and it’s easy to make mistakes. I think we’ll be okay with this stack workflow [2] taken from Mercurial’s Evolve command [3]. [1]: https://en.wikipedia.org/wiki/Stockholm_syndrome https://en.wikipedia.org/wiki/Stockholm_syndrome [2]: https://sapling-scm.com/docs/overview/stacks https://sapling-scm.com/docs/overview/stacks [3]: https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html https://www.mercurial-scm.org/doc/evolution/tutorials/topic-...
  - chungy 4y ago
    > I think there’s some Stockholm Syndrome I lived through the alternative and the staging area is superior. If it wasn't, I might not be using Git, or at least begrudge when I have to; neither is the case.
    - guytv 4y ago
      Isn't the staging area just a stack of changes where stack height == 1?
      - still_grokking 4y ago
        Sure. And a branch is also just a stack of changes… The whole point is that this things are treated differently.

guytv 4y ago

One of the problems with `git`, and it seems that Sapling is no different, is that there is no one-to-one mapping between the user intent and the underlying SCM. For a user intent of "implement feature X", there is no UI to "start a new feature". Instead, one has to translate their requirement to the SCM mental model and issue a series of commands to manipulate a DAG of blob hashes that live in 4 different places simultaneously. (work tree, index, local repository and the remote repository. Highflux allows a simple user requirement to action mapping.