Hacker News Reader

Comment by avar | Hacker News Reader

    It'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.

View on HN

Agreed, 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.

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.

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.

So fossil does have rebase?

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) though, which I'll look into myself to come to understand. Before, I thought rebase was more 'destructive' than what that description indicates.

How do you get arround issues with sharing branches between devs while using rebase. The oddness of pushing your history over other devs makes rebase extremely backwards for me.

That's why you never rebase something that's already been pushed to a public repo or some other shared "master" branch. Rebasing is for making a clean history before you merge into master or make your changes public.

It's really a magnificent tool because I never have to worry about the cleanness of my work-in-progress commits.

Not to mention that gerrit doesn't tend to like merge commits.

Reply on news.ycombinator.com