5 ms·

I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and

I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and making commits as I go along doesn't work well. How does sapling let me take a long list of commits and break them into larger but more manageable chunks? git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits. Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the "whole" vs a patch that is more localized.

arxanas 4y ago
Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).
- ArchOversight 4y ago
  If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke. It sounds like I would need to: - switch - amend the commit - restack? - switch back to the HEAD? Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sapling-scm.com/docs/commands/fold https://sapling-scm.com/docs/commands/fold This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.
  - arxanas 4y ago
    Yes, in my preferred workflow, I usually create a temporary commit and then switch away. Sapling also has `sl shelve` as `git stash`. If you want to run tests on commits without checking them out, you might want to try my `git test` command: https://github.com/arxanas/git-branchless/discussions/643 https://github.com/arxanas/git-branchless/discussions/643 You can use `sl fold --exact` to combine arbitrary commits without including the current one. (To be honest, I just always used `sl histedit`.)
  - mitrandir77 4y ago
    `sl histedit` is very similar to `git rebase -i` if you're famiilar with that interface which works just fine. Other commands useful for amending changes to previous commits: * `sl goto --merge <hash>` - if theres no conflicts you can just switch commits with pending changes and those pending changes would be applied on top of other commit. If there are conflicts this command would fail https://sapling-scm.com/docs/commands/goto https://sapling-scm.com/docs/commands/goto * `sl absorb` - this automagically finds the last commit that touched the lines that are pending and amends that commit with them https://sapling-scm.com/docs/commands/absorb https://sapling-scm.com/docs/commands/absorb
  - tchebb 4y ago
    `sl absorb` can turn that workflow into a single command in many cases: it automatically looks at what hunks you've changed and tries to propagate them back to earlier commits in the stack that touched those same hunks. It's not perfect, but in my experience using this at Meta, it does what you want 90% of the time.
- andrewshadura 4y ago
  Consider also trying git-crecord, which is a port of he's curses-based partial commit interface.
  - andrewshadura 4y ago
    Oh, I didn’t notice a typo — hg’s.
- charcircuit 4y ago
  sl record is another shorthand for an interactive commit.
kobalsky 4y ago
> git add -p allows me to add chunks easily and create commits your workflow resembles mine so I'm in the obligation of mentioning https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit which allows you to stage individual lines among other features. https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE
thijser 4y ago
https://sapling-scm.com/docs/introduction/differences-git#sapling-has-no-staging-area https://sapling-scm.com/docs/introduction/differences-git#sa... says: "If you want to commit/amend just part of your changes you can use commit/amend -i to interactively choose which changes to commit/amend. Alternatively, you can simulate a staging area by making a temporary commit and amending to it as if it was the staging area, then use fold to collapse it into the real commit."
cryptonector 4y ago
`git add -e` is even more amazing. I also use this workflow. Lots of detached HEAD mode, using the index to commit things piecemeal, then rebase as needed, until I'm finally done.
tome 4y ago
> I use the staging area to allow me to more easily break larger changes into smaller commits ... git add -p allows me to add chunks easily Sure, but you can use `git commit -p` to get the same benefits without explicitly using the staging area.

arxanas 4y ago

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).

ArchOversight 4y ago
If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke. It sounds like I would need to: - switch - amend the commit - restack? - switch back to the HEAD? Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sapling-scm.com/docs/commands/fold https://sapling-scm.com/docs/commands/fold This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.
- arxanas 4y ago
  Yes, in my preferred workflow, I usually create a temporary commit and then switch away. Sapling also has `sl shelve` as `git stash`. If you want to run tests on commits without checking them out, you might want to try my `git test` command: https://github.com/arxanas/git-branchless/discussions/643 https://github.com/arxanas/git-branchless/discussions/643 You can use `sl fold --exact` to combine arbitrary commits without including the current one. (To be honest, I just always used `sl histedit`.)
- mitrandir77 4y ago
  `sl histedit` is very similar to `git rebase -i` if you're famiilar with that interface which works just fine. Other commands useful for amending changes to previous commits: * `sl goto --merge <hash>` - if theres no conflicts you can just switch commits with pending changes and those pending changes would be applied on top of other commit. If there are conflicts this command would fail https://sapling-scm.com/docs/commands/goto https://sapling-scm.com/docs/commands/goto * `sl absorb` - this automagically finds the last commit that touched the lines that are pending and amends that commit with them https://sapling-scm.com/docs/commands/absorb https://sapling-scm.com/docs/commands/absorb
- tchebb 4y ago
  `sl absorb` can turn that workflow into a single command in many cases: it automatically looks at what hunks you've changed and tries to propagate them back to earlier commits in the stack that touched those same hunks. It's not perfect, but in my experience using this at Meta, it does what you want 90% of the time.
andrewshadura 4y ago
Consider also trying git-crecord, which is a port of he's curses-based partial commit interface.
- andrewshadura 4y ago
  Oh, I didn’t notice a typo — hg’s.
charcircuit 4y ago
sl record is another shorthand for an interactive commit.

kobalsky 4y ago

> git add -p allows me to add chunks easily and create commits your workflow resembles mine so I'm in the obligation of mentioning https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit which allows you to stage individual lines among other features. https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE

thijser 4y ago

https://sapling-scm.com/docs/introduction/differences-git#sapling-has-no-staging-area https://sapling-scm.com/docs/introduction/differences-git#sa... says: "If you want to commit/amend just part of your changes you can use commit/amend -i to interactively choose which changes to commit/amend. Alternatively, you can simulate a staging area by making a temporary commit and amending to it as if it was the staging area, then use fold to collapse it into the real commit."

cryptonector 4y ago

`git add -e` is even more amazing. I also use this workflow. Lots of detached HEAD mode, using the index to commit things piecemeal, then rebase as needed, until I'm finally done.

tome 4y ago

> I use the staging area to allow me to more easily break larger changes into smaller commits ... git add -p allows me to add chunks easily Sure, but you can use `git commit -p` to get the same benefits without explicitly using the staging area.