sent too soon.
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp <d...@sqlite.org> wrote:
> The staging area is another element of state on a check-out. It is one more
> thing that the developer must keep in mind. Better to minimize the amount
> of "mind-space" required for the VCS in order to leave as much mind-space
> available to the application as possible. Mind-space is a finite resource.
> Use it wisely.
Not really. A developer need not know anything about the index:
% <make changes>
% git commit -a
or
% git commit file list
or
% git add file list
% git commit
The power features are in git add -e/-p. If you don't use them, you
don't need to know much at all about the index.
> The staging area complicates the interface. Instead of just a diff between
> the current check-out and the most recent check-in, now you have to add
> syntax for a diff between the checkout and the staging area and a diff
> between the staging area and the most recent check-in. Multiply that by as
> many commands as you have that involve both the repository and the current
> check-out.
I never need to diff the staging area to the HEAD. Only the workspace
to the HEAD+staging area, which is what git diff does.
> Does undo/redo effect the staging area? What if you "update" in order to
> pull in changes made by a collaborator before you commit - how does that
> effect the staging area? How does the staging area interact with the stash?
I don't use the stash, so I don't know the answer to the last. If
there's an undo/redo in git, I also don't use it.
As for a git pull -u, or a git checkout, with a dirty index, you get an error:
error: Your local changes to the following files would be overwritten
by checkout:
README
Please, commit your changes or stash them before you can switch branches.
Aborting
> If you are making a change in one branch and decide you'd really rather have
> that change in a different branch (or you just happen to discover that you
> were mistakenly on the wrong branch - which is the usual reason this comes
> up for me) and you move all your changes to a different branch prior to
> check-in, does your staging area move with you or not? Thousands of details
> like this need to be considered. And all of these details and complications
> and the associated mental clutter can be quickly and easily eliminated
> simply by omitting the staging area.
I either a) unstage the changes in the index, then checkout the other
branch, of b) I create a new branch from the current HEAD, commit my
changes, checkout the other branch, cherry-pick the commit, and then
delete the branch I just created if I had no use for it.
> My understanding is that the Git staging area arose as part of the
> implementation showing through into the interface. In Git-speak, it is
> plumbing that is visible from the porcelain. It is a misfeature. My
> readings on the matter suggest that most people agree with me on that point.
I don't see how git ever needed to have the index. It just happens to
be incredibly useful, and so I suspect it arose out of a need that
Linus and friends had, not out of an implementation detail.
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
