On Tue, Jun 3, 2014 at 3:26 PM, Stephan Beal <sgb...@googlemail.com> wrote: > On Tue, Jun 3, 2014 at 10:05 PM, Nico Williams <n...@cryptonector.com> > wrote: >> >> These aren't architectural changes. >> >> For example, rebase == scripted sequence of cherry-picks. The index >> is more architectural, but not really that intrusive. Pushing only > > The main limiting factor here, from my understanding, is internals of fossil > which _might_ change _older_ data, making it dependent on the newer data. > e.g when saving a file, fossil might transform its older version into a > delta based on the new version (which is stored in undeltad form). Whether > or not it actually does that is left for it to decide. All of that is a side > effect of Fossil's original design philosophy: once it's in, it stays in.
git rebase... doesn't remove commits from the repo. It only creates new commits and then updates a branch's head to point to the newest of the new commits. Therefore rebase doesn't violate that constraint. git branches are really just symbolic names for commits. And commits not reachable from any branch or tag can be removed if you prune dead branches, but I'm not asking that Fossil have this functionality. > Because it was built with that philosophy in mind, it makes optimizations > based on that which make undoing it (e.g. so a "staged" or unpushed commit > could be undone) amazingly hard. The index has nothing to do with this. Deltas in the index are not in the repo. They are just the deltas that will be in the next commit, that's all. > About 6 months ago or so i investigated what it would take to support undo > of "popping" the top-most change from a repo (be it a tag, wiki change, or > whatever), and the checklist of TODOs (and associated complexity) quickly > grew longer than my hair :/. Right, and that's just not something I'm interested in. >> You're missing one item: a relational approach to history. > > i get that - fossil has it and git doesn't. That's _one_ feature from your > list which fossil has and git does not, whereas git has _lots_ of features > you want but fossil does not have. [...] A lot of the features I want can be scripted if the necessary primitives are provided. Rebase is like that. The index could also be like that with a bit more help from the core. Examples of primitives needed: - a cherry-pick that has the option to commit or not commit the given commit - the ability to commit with timestamps other than "now", arbitrary committer info, ... - metadata for referring to an original commit (so that one can chase cherry-picks and rebases) - preventing some operations (e.g., push, change branch) from running while a long-running interactive operation (e.g., merge, rebase, ...) is in-progress - for the index all that's needed is a way to apply a commit without referring to the checked out files, and a way to prevent switching to other branches while the index is not empty None of these strike me as in conflict with Fossil principles. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
