4 ms·

It's not just "oops, typo", but also "oops, someone checked in something proprietary." Being able to scrub the version history before you publish it is more or

by shasta 15y ago

It's not just "oops, typo", but also "oops, someone checked in something proprietary." Being able to scrub the version history before you publish it is more or less is almost a requirement in certain environments.

bch 15y ago
This is actually solved in fossil via "shun". The case of publishing a password or credit card numbers or $seriousMistake will be attributed to an artifact. Applying "shun" to that artifact will prevent it from being pushed to remote repos, and, on repo rebuild (a local operation), that artifact will be completely removed from the repository (locally). The list of shunned artifacts is maintained forever however, so if the artifact is re-introduced via a pull from some other repo, the shun that was previously applied will still be in effect, and keep the artifact from being further propagated by this repo.
- zbanks 15y ago
  So fossil does have rebase?
  - bch 15y ago
    I'm not a git expert, but iiuc, git rebase is a way to re-present a subtree as a single checkin, or otherwise re-work the commit tree to clean it up. It's also a big part of git culture. In fossil, there is such a thing as a private branch that will not be pushed/pulled when repos sync w/ ea. other, but the owner of that private branch can ultimately merge the work, and it will appear as a single atomic commit (ie: a single checkin, not all the multiple artifacts describing the whole of the work in the private branch). I'd think that's the closest thing to rebase that fossil has. Even in that case, though, there's no explicit moving of artifacts; when the work is merged to a public branch though, all the work appears as the condensed net change, in a single checkin. Otherwise, culturally speaking, re-working of the tree is -not- the way the repository is handled. Errors are fixed w/ corrective checkins, and both will show in the history. jrockway sheds some light on git rebasing here (http://news.ycombinator.com/item?id=2524993 http://news.ycombinator.com/item?id=2524993) though, which I'll look into myself to come to understand. Before, I thought rebase was more 'destructive' than what that description indicates.

by shasta 15y ago

bch 15y ago

This is actually solved in fossil via "shun". The case of publishing a password or credit card numbers or $seriousMistake will be attributed to an artifact. Applying "shun" to that artifact will prevent it from being pushed to remote repos, and, on repo rebuild (a local operation), that artifact will be completely removed from the repository (locally). The list of shunned artifacts is maintained forever however, so if the artifact is re-introduced via a pull from some other repo, the shun that was previously applied will still be in effect, and keep the artifact from being further propagated by this repo.

zbanks 15y ago
So fossil does have rebase?
- bch 15y ago
  I'm not a git expert, but iiuc, git rebase is a way to re-present a subtree as a single checkin, or otherwise re-work the commit tree to clean it up. It's also a big part of git culture. In fossil, there is such a thing as a private branch that will not be pushed/pulled when repos sync w/ ea. other, but the owner of that private branch can ultimately merge the work, and it will appear as a single atomic commit (ie: a single checkin, not all the multiple artifacts describing the whole of the work in the private branch). I'd think that's the closest thing to rebase that fossil has. Even in that case, though, there's no explicit moving of artifacts; when the work is merged to a public branch though, all the work appears as the condensed net change, in a single checkin. Otherwise, culturally speaking, re-working of the tree is -not- the way the repository is handled. Errors are fixed w/ corrective checkins, and both will show in the history. jrockway sheds some light on git rebasing here (http://news.ycombinator.com/item?id=2524993 http://news.ycombinator.com/item?id=2524993) though, which I'll look into myself to come to understand. Before, I thought rebase was more 'destructive' than what that description indicates.