I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.
I don't see why merge conflicts would be a pain specific to monorepos. The merge conflict arises when you and some other person modify the same parts of the same file. No matter the repo size the correct solution here is figuring out the intention of the other person by reading their change or talking to them and deciding how to combine it with your change.
The only reason which may make merge conflicts happen slightly more often in monorepo (vs constellation of small repos) is that not having the repo cloned locally is an obstacle to make the change. So some folks won't bother contributing repo that they'd have to clone first and instead they'd file a bug to the owners.
`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
I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit.
I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed.
Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.
> Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.
You can just use the tip as your staging. Use interactive amending to move changes from the working copy to the commit, and when you want to "commit", finish up the message.
hg actually has an "unamend" command (part of the "uncommit" standard extension) which... reverts the last amend. Rather than having to remember how to contort reset into the right shape to move changes back out of staging without destroying everything.
`git reset HEAD~` doesn't feel like that much of a contortion to me. It's the destructive change that requires more contortion (`--hard`) which feels fair. Maybe this is stockholm syndrome though.
The way I think of it, there's basically three copies of the file in play: in HEAD, in staging area, and on disk. I cannot trust my memory to remember which variant of "git reset" copies the file in HEAD to the staging area, which variant copies staging area to disk, and which variant copies HEAD to disk (in all cases, the third copy remains uninvolved). Getting it wrong potentially creates unrecoverable data loss. And, unfortunately, this is one of those cases where reading git's documentation is less than helpful.
Combine this with the case where "I want to break one commit into two commits," where now I have to worry about making sure I know if the command is going to change the revision HEAD points to. At least there, the old commit will still exist as backup in the invariable scenario I screw something up.
In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).
I’ve never used one of the source control systems at these big companies but I use the staging area along with your git-branchless just fine for now. I’m not sure if it’s any less efficient this way.
It's not a big deal either way, but the staging area interacts worse with some operations. For example, if you have staged changes and then get a conflict with `git checkout --merge`, AFAIK there's no way to undo to before the conflict in Git. When using commits, all of the standard merge and undo tactics apply.
I guess each to their own. I want to stage my commit with regular commands, and then have the staging area work with (diff, add/remove etc).
I don't care for an interactive tool, IMHO I prefer using commands that are repeatable and learnable instead of stepping through some interactive workflow all the time.
You `sl commit` that half-done work anyway and then iterate by running `sl amend` many times until your commit is finished. In case you want to amend just part of changes us `sl amend -i`
I've tried one very basic terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.
It is quite fast tbh and non-sluggish terminal is nice-to-have.
I've tried one terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.
