On Jan 13, 2007, at 11:09 AM, Carl Worth wrote:
Also, this would even make it possible to provide an accurate index-based description of "commit paths...". Namely, something like: commit paths... This command starts with a new index initialized from the contents of the current commit (HEAD). It then performs the following commands: git refresh paths... git commit [Some extra language needed here about restoring into the index other changes that were "skipped over".] So, someone might like to have that kind of description somewhere in the technical documentation of git. (I'd still prefer to see "commit paths..." documented as simply "commits the working-tree content of all specified paths").
I fail to see why this description can't be used with s/refresh/ add/. I also don't think it's a very clear description because of the "starting with a new index" and the hand-waving involved in "restoring into the index other changes".
I can somewhat understand the desire to split git-add (although I don't share it). But I don't see the need for it to be a new git- refresh, since that functionality already exists as git-update- index. Is using git-add to add to the index a conceptual problem or is it causing actual problems in people's usage of git? If it's an issue of teaching new users, I _think_ that could be resolved very simply as "git add adds content to the index" when we explain the index as the staging area for a new commit and wean people off of "git commit -a". A short discussion of "tracking content vs. files" is probably also a good idea. (I honestly haven't read the tutorials in a long long time, so this may already be in there.)
~~ Brian - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html