On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp <d...@sqlite.org> wrote: > On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams <n...@cryptonector.com> > wrote: >> 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". > > My view is that the Git staging area (I really dislike the use of the word > "index" in that context) merely makes Git more difficult for people to > understand and complicates the interface without adding any new capability.
I felt it was a power feature that made my power user life better. Then I showed my wife how to use SourceTree on OS X. I had figured that I'd never show her the index. ETOOHARD I thought. Until something came up where she needed to discard some changes and keep others she had made to a file. SourceTree's GUI interface to the index turns out to be very natural and easy to you. I couldn't believe it, but she picked it up immediately even though she'd never before used git and I'd never thought of how to build a UI to the index. In retrospect the thing is this: at a CLI level, yes, the index requires that users know how do deal with and even edit patch chunks in order to make powerful use of it, and for most users that's just a lot of detail. But in a GUI it turns out that the index can be made a very easy to use feature. > 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. > 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. > > 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? > 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. > > 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. > > Please keep all thoughts of a staging area far, far away from Fossil. > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
