3 ms·
Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit. > Histedit extension which is meant to provide
by develop7 13y ago
Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit.
> Histedit extension which is meant to provide this feature has warnings all over the place
Ignore them — you do know, what are you doing, right?
> changeset backups written to locations in the working tree
That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.
- Perseids 13y ago> Ignore them — you do know, what are you doing, right? No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog. > That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked. I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago, but believe to remember there was some command that left .orig files lying around and that if you applied a history rewrite command several times those backups were overwritten with the new backups and you weren't able to come back all the way.
- develop7 13y ago> to be able to go back to a previous state whenever I need to as I've said, old commits are backed up. > This works great with Git's reflog. except git reflog is cleaned on git gc Not mentioning http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution feature is being in development. > there was some command that left .orig files lying around Only way .orig files may pop up is failure to replay rebased commit(s). No way these are backups — their purpose is to make user able to fix things and continue.