On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams <n...@cryptonector.com>
wrote:
> 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.
>
You're right, i'm confusing rebase and reset (and its --hard option). Thank
you for so politely pointing that out :).
> 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.
>
Bookmarks. That's a nice idea, actually. Added to my TODO list.
> - 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
>
Neither of those seems to pose any problems, so long as the index isn't
using the current versioning-related infrastructure (concretely: doesn't
have any unique content which is referenced by other commits). This is
certainly a use case i'll explore in libfossil (where i've got a bit more
leeway in making changes).
> > 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.
>
i've only ever used the index for (basically) an undo area, but you're
right, that's probably not what most people use it for. In my mind the
index is basically "autosync=0," but of course that's a hugely
oversimplified world view.
> 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.
>
i have some ideas about how this could be done. In libf it would be
relatively straightforward, i think, because it allows the client more
control over the source and destination of the content bytes. In fossil it
would require more infrastructure, but probably not prohibitively much.
> 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.
>
The stash is similar, at least in principal, so there may already be a
basis in place for something like this.
> If your index is empty and you commit, you get the same behavior as today.
>
Sounds reasonable.
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.
>
Fair enough. i've just jotted down some ideas to play with, but i can't
commit to any timeframe.
Ideas on implementation strategies are of course welcomed!
--
----- 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
