From: Brian Gernhardt Date: Sat, 13 Jan 2007 16:45:29 GMT Subject: Re: Importing from tarballs; add, rm, update-index? Message-ID: <6C7B9A8F-122D-446A-AF25-409C9DCAA592@silverinsanity.com> In-Reply-To: <87y7o6x60w.wl%cworth@cworth.org> 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