On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> 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 :).
This is a very polite crowd. When in Rome... :)
>> - 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).
Right, the index is a very light-weight mechanism for giving the user
power in deciding what to commit. I.e., more fine-grained control
than "choose what files to commit".
>> [...]. 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 index is very ephemeral, unlike stashing. I never use git stash,
and I don't care for it. "stage" is close to "stash", so I can see
the confusion.
> 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.
In terms of primitives it's not much.
You should play briefly with the index in git:
% git init
% date > somefile
% git add somefie
% git commit -m initial
% date > somefile
% sleep 1
% date > somefile
% git add -e somefile
<select the one hunk and choose to edit it so as to take one, but not
the other of the two new lines>
% git commit -m "add a date"
% git diff
% git commit -m "add another date"
% git log -p
Now picture working on some bug and then you realize you've written a
fix for two different things, and you want to disentangle them into
two commits. How? You could checkout a clean workspace and manually
add the changes for one fix, commit, and go from there. Or, you can
use git add -p or git add -e and it's much, much easier.
>> 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.
The stash is much more permanent. The index is much more ephemeral.
These are the things you can do with an index:
- add to it
- inspect it
- remove from it
- commit it
A stash is a more complicated beast, as it's really saving extant
changes in a bundle with a name.
But you're right that the stash too is something that can be bolted on
the side of the VCS with relatively little help from the VCS. In a
sense the index and stashing are alike.
But the index is much easier to use and explain. If you can use OS X
and try out the SourceTree app.. that will make it even easier,
self-evident even, straightforward. I mean, my wife discovered the
SourceTree equivalent of git add -e and just used it, even though she
was days into learning how to use SourceTree. It allowed her to
really solve a real problem without having to learn how to rebase to
split commits (which is a much more difficult thing to explain!).
> Sounds reasonable.
:)
I have to use Mercurial in some cases. My commit history for git
projects tends to be much cleaner than for Mercurial projects, and
this is largely due to the index and git add -p/-e (and the way _I_ go
about writing code).
> Fair enough. i've just jotted down some ideas to play with, but i can't
> commit to any timeframe.
I ask for no commitments. I wanted only to plant seeds. :)
> Ideas on implementation strategies are of course welcomed!
I will look at Fossil source and think about it.
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
