[Sorry to break threading, but I unsubscribed, then saw this in the archives and re-subscribed just to answer, but I don't have the Message-ID.]
On Sun, Dec 30, 2012, Joerg Sonnenberger wrote: >On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote: > > I repeat: git rebase does not "manipulate the pre-existing tree", it > > does not destroy any history already in the tree. The only > > destructive action that git rebase does is change the commit that a > > branch _name_ points to, and from a fossil philosophy perspective this > > is the only aspect of git rebase that is worth differing on. > > > git rebase is destructive due to a combination of not supporting more > than one "leave" revision for a given named tag and dropping all other > revisions on a non-fastforward push. Now a combination of recording what > a "rebase" is based on and just marking the original commit as closed > would pretty much serve the purpose of fossil. I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). Also, I'd like to be able to ask about previous rebasings of a given branch and be able to name them, something like branchname%N, where N is the Nth previous rebasing. This way I could checkout, diff, ... old versions of a branch. And then there'd be no need to create a copy of the victim branch prior to rebasing. This alternative to my first proposal strikes me as particularly useful. Thank you for mentioning it. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
