On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams <n...@cryptonector.com> wrote:
> 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. > Based on that description, that "sounds doable," but i'm inherently dubious of "rebase" because i've broken my git repos more than once when using it. (That said, i'm not the one you'd need to convince ;) > 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. > Fossil's internals would indeed make it very difficult to do that. > > 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. > The index is in the db, along with everything else. Fossil would currently need a separate set of delta tables and algorithms to accommodate that, or some way to say "do not consider these artifacts for delta purposes." > > 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. > But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way back to the first commit. As long as the repo wasn't synced, that could provide a staging area-like ("like," but not identical) feature. > 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, ... > i thought 'commit' had flags to override the timestamp and user, but apparently not. > - metadata for referring to an original commit (so that one can chase > cherry-picks and rebases) > What you're asking for is that fossil add the infrastructure for 100% fidelity with a 3rd-party system which can change at any time, breaking fossil's 100% fidelity. Any solution would be based on assumptions made about git, and that way lies madness. > - preventing some operations (e.g., push, change branch) from running > while a long-running interactive operation (e.g., merge, rebase, ...) > is in-progress > the db locking generally takes care of that (by failing for the second and subsequent ops). > - 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 > The "commit" model in fossil is fundamentally based on the sha1 of the contents of the file. How do we get that without referencing the files? > None of these strike me as in conflict with Fossil principles. > Not necessarily the principals, but they would, by and large, require new infrastructure which would be added for the sole sake of 100% fidelity with git, so that Fossil can be used as a git backup/recovery system when git suffers an untimely power outage. That way lies madness. (Headed off to bed, so please don't take a lack of further responses personally! ;) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users