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
