Provocative Subject: line, I know.
But it's true, git-like "rebase" is not incompatible with Fossil's
principles *provided* that the result of a rebase is a new branch, or
provided that the branch being affected has no "children" (i.e., that
it's a private branch).
I use git a lot, and I like it. I also like the ideas behind Fossil.
I'm only really missing git cherry-pick and git rebase (which is
based, really, on cherry-pick).
Why rebase? I'd like to give you three example use cases where git
cherry-pick and git rebase have been important to me. I hope that
there are Fossil-specific alternatives, but if not then I hope that
these examples will be useful to the Fossil community.
Example #1: Rebasing commits in response to code reviews prior to
upstream integration.
Upstreams rarely ever want their canonical history polluted by a developer's
typical missteps (typos, etcetera).
See http://github.com:nicowilliams/krb5/branches, look for branches
named kadm5_polic_exts*.
Each one of these represents a rebase of another. That is, when I use
git rebase I mostly do it in brand new branches so as to not be
destructive of the original, even when all these branches are "private" as
in this case.
Each rebase was in response to code review comments. Some rebases
I did in various sequences, first one to re-organize some commits (e.g.,
reorder, split, or squash them), then another to fix minor issues.
Example #2: Cherry-picking from site-local feature branches onto
site-local release branches.
One SCM workflow I like involves maintaining sets of local patches to
open source projects, with each patchset kept as local feature branches
based on upstream release branches.
To make a new site-local release from a new upstream release we
first create a new site-local release branch for each site-local feature
based on the new upstream release, cherry-pick/merge the given
feature patches onto the new feature branches, test, then finally merge
all the site-local feature branches onto a site-local release branch
based on the new upstream release branch.
git cherry-pick isn't essential here: git merge would suffice. But the
cherry-pick concept allows more control over the merge metadata.
Note that these site-local feature branches and site-local release
branches are not always shared with the upstream (some hold
patches that upstream does not want or which would be obviously
of no interest to the upstream community), but they're not necessarily
"private" in the sense of not being shared with other site-local
repositories (e.g., developers').
Example #3: Intermediate upstreams ("project gates").
This example is very much based on how development was done at
Sun Microsystems, and in all certainty still is at Oracle in groups
acquired via the acquisition of Sun, and is how I do some
development today for some customers.
In this model we have upstream "gates", "project gates", and developer
repositories. Developers branch off of project gates and push commits
to the project gates. Project gates track upstream gates until the projects
complete, at which point they push their changes upstream.
You can surely see the problem though: as commits from multiple
projects get pushed upstream each remaining downstream project
gate has to rebase, and that breaks all their further downstream
developers. Clearly this is broken. But there's a way to make this
work, and we did this at Sun all the time: the rebases are done on new
gates based on the old gates.
In git this works as follows. First, the root upstream has a single
canonical branch ("master"), the project gates are either branches off
the canonical upstream branch, possibly in distinct repos, ditto the
developer gates. Second, the project gates rebase periodically, each
time creating a *new* branch and "closing" the previous project gate
branch to new commits. Third, developers periodically rebase their
branches onto (think of git rebase --onto=...) the new, rebased project
gates.
At Sun "periodically" meant specifically that we had "build schedules"
that resulted in "build releases", at which point a "snapshot" branch
was created of the upstream root. Thus the periodic rebasing for
the project gates was scheduled and the branch names had "build"
numbers in them.
One nice aspect of this model is that it allows project and developer
gates to keep their commits "on top of" the upstream base branch: it's
always clear what local patches there are relative to the upstream.
Note that all these example use cases involve at least two individuals
(upstream and downstream), and examples #2 and #3 scale to very large
communities (experience at Sun certainly backs this up). That is,
these models scale all the way from two individuals to thousands.
I would like these models to be feasible with Fossil. I realize that
that's not the intention of Fossil's developers. If it's not possible
or the community rejects making it possible, oh well, I'll drop it.
But I noted while reading the Fossil docs that the reason for
rejecting "rebasing" is its destructive nature, and the obvious
solution to that is to have the rebase operation create a new branch
while leaving the old one unmodified. That is, I do not think that
"rebase" is fundamentally inimical to a "never delete anything" model,
just apply copy-on-write to the concept.
Nico
PS: A telling of the history of Teamware (the SCM used at Sun for a
very long time until Mercurial finally started replacing it), Larry
McVoy, Bitkeeper, and git would probably be in order. In particular
the story of how Sun has used SCMs in the manner of use case #3 above
even when the SCMs supported other workflow models or were designed
specifically with other workflow models in mind. It's possible that
use case #3 arose primarily due to limitations of Teamware (though I'm
not certain of this as I wasn't there at the time), but I do think
that use case #3 is generally the best model for large upstreams with
large projects targeting integration into upstream, and it would have
arisen naturally eventually.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
