4 ms·
"The lack of a 'rebase' function is considered a feature of Fossil, not a bug." It's not as if rebase is commonly used. It's there for those rare instances whe
by jwecker 15y ago
"The lack of a 'rebase' function is considered a feature of Fossil, not a bug."
It's not as if rebase is commonly used. It's there for those rare instances when you, say, remove a file that it turns out you don't have the copyright for and need to purge it completely, or that huge binary file some newb (ok, it was me) committed a while back that's not needed and makes cloning take 10 minutes.
Fossil looks really exciting to me- I've used git a ton and like it but don't really delude myself into thinking it can't be disrupted. But, seriously, you're missing a critical feature; instead of trying to patronize your would-be future users by defensively stating that it's a "good thing and we're proud of this missing functionality"- you could simply state something along the lines of "In general we think not having the equivalent of rebase is a good thing, but should you seriously need something like it, this is opensource and we'd love for you to contribute..." etc.
[Edit: I'm referring to git-filter-branch etc. to remove those things, not the rebase command per se, but in context of the original page's "Immutable==good" argument I interchanged the two]
- avar 15y agoIt's not as if rebase is commonly used. This is widly incorrect. Powerusers of Git use rebase extensively, pretty much every patch that makes it into Git itself has been rebased at least half a dozen times. I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages. I wouldn't use any SCM tool that wouldn't give me this functionality. The result of recording all history permanently is that users will just not commit their incomplete work, meaning that it'll be in their working tree instead of tracked in some form by the repository.
- Scaevolus 15y agoAgreed, without rebasing the history for projects with lots of developers quickly becomes a mess. > Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. I'm not sure how keeping garbage like "oops, fix typo" out of history is lying to your fellow developers-- a VCS should be aiding development, not forcing others to see your little mistakes.
- shasta 15y agoIt'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 agoThis 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 agoSo fossil does have rebase?
- bch 15y agoI'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.
- j_baker 15y agoNot to mention that gerrit doesn't tend to like merge commits.