Most of the time I think it wouldn't be very much different to go back among the commits in such a rebased sequence than elsewhere, since there can be unrelated commits that affects the testing in any case, and it's not like we have a strict rule that every commit _must_ be self-contained and return the tree to green build status in the development branch.
But of course it depends on the amount of divergence between the main trunk and the development commits - there is a point where this approach becomes impractical and it's better to use a real branch with a single merge at the end. > this situation is of course still better than a single huge commit > without any access to the detailed commits at all. Yes, I think so. It can be viewed as "a single commit with internal history", and it'd be a very nice tool for medium-sized changes, at least. > that only works if you are the only one working on that branch, > a branch that is continuously rebased is very hard to use for anyone > else. Would it be that hard? If I have my own changes on top of this dev branch, and someone else rebases it, then it wouldn't be much harder to rebase my changes on top of the new dev branch as any other rebase, would it? The changing hashes would be a nuisance mostly since you can't reliably refer to a commit using them. The way they are calculated on the whole tree in git is a drawback in my view. It's nice in an extremely decentralized dev environment to have the security built into the commit id's, but that decentralized model is not the reason I want to use git. I'd rather see uuid's or something as commit id's and hashes only as an optional tool to "sign" trees.
