On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 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 ;)
You're mixing things up :) Rebase is just a script around "new branch
starting at given base, cherry-pick all the commits from the base to
the head of what's being rebased". It's a script, literally. It
can't break your repo.
(A rebase of a branch that had been referenced from downstreams will
break them, which is why one should not do it to a public branch. And
the old commits may be left unreachable from any branch name, so you
might think your repo is "broken", but you can still find those
commits and create branches that refer to them.)
>> 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.
Mercurial too had "heavy-duty" branches only, then they added
"bookmarks" that are very similar to git branches. Since a "bookmark"
is just a symbolic name for a commit... this is just a new table at
best, with two columns.
>> > 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."
It could be in the DB, but it doesn't need to interfere with anything.
The only requirements:
- if the index is not empty, then the user can't change branches
- if the index is not empty, then commit should commit only what's in the index
Any tools to manage the index could then be totally external (contributed).
>>
>> > 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
> [...]
You misunderstand the index. It's not about undo. It's about
capturing a subset of the extant deltas for committing.
>> - 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?
The index captures the content to be committed.
It's like having a logical snapshot of the workspace set aside. You
add things to the index ("copy", if you like) from the workspace, then
you commit what's in the index.
If your index is empty and you commit, you get the same behavior as today.
>>
>> 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.
Forget the backup/restore -- that's a different problem set. We're
now on the subject of about allowing me to get the workflows I use
with git, but with Fossil instead, and with minimal changes to Fossil.
Give me the bare primitives I need, and I can build the rest as
external components.
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
