Yes, I've been asking for branch history (the reflog provides some, but it's insufficient because it's not shared in any way).
Even with this, I'd want to rebase away "fixed typo" prior to pushing, and more, I'd want to:
- organize commits into logical chunks so that they might be cherry-picked (in the literal sense, not just the VCS sense) into maintenance release branches
- organize commits as the upstream prefers (some prefer to see test updates in separate commits)
IIUC BitKeeper does have a sort of branch push history, unlike git. Is this wrong?
So the current BK doesn't really have branches, it has the model that if you want to branch you clone, each clone is a branch.
Which begs the question "how do you do dev vs stable branches?" And the answer is that we have a central clone called "dev" and a central clone called "stable". In our case we have work:/home/bk/stable and work:/home/bk/dev. User repos are in work:/home/bk/$USER/dev-feature1 and work:/home/bk/$USER/stable-bugfix123.
We run a bkd in work:/home so our urls are
bk://work/dev
bk://work/$USER/dev-feature1
BK has a concept of a level - you can't push from a higher level to a lower level. So stable would be level 1, dev would be level 2. Levels propogate on clone so when you do
bk clone bk://work/dev dev-feature2
and then try and do
bk push bk://work/stable
it will tell you that you can't push to a lower level. This prevents backflow of all the new feature work into your stable tree.
The model works well until you have huge (like 10GB and bigger) repos. At that point you really want branches because you don't want to clone 10GB to do a bugfix.
Though we addressed that problem, to some extent, by having nested collections (think submodules that actually support all workflows, unlike git, they are submodules that work). So you can clone the subset you need to do your bugfix.
But yeah, there are cases where "a branch is a clone" just doesn't scale, no question. But where it does work it's a super simple and pleasant model
Even with this, I'd want to rebase away "fixed typo" prior to pushing, and more, I'd want to:
- organize commits into logical chunks so that they might be cherry-picked (in the literal sense, not just the VCS sense) into maintenance release branches
- organize commits as the upstream prefers (some prefer to see test updates in separate commits)
IIUC BitKeeper does have a sort of branch push history, unlike git. Is this wrong?