Re: Importing from tarballs; add, rm, update-index?
- From
Brian Gernhardt <benji@silverinsanity.com>
- Date
- Jan 13, 2007, 16:45 UTC
- 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:
Show 19 quoted lines
> 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