From: Nicolas Pitre Date: Wed, 01 Feb 2006 21:34:34 GMT Subject: Re: [Census] So who uses git? Message-ID: In-Reply-To: On Wed, 1 Feb 2006, Linus Torvalds wrote: > > > On Wed, 1 Feb 2006, Junio C Hamano wrote: > > > > How about this: > > > > - "git commit --also fileA..." means: update index at listed > > paths (add/remove if necessary) and then commit the tree > > described in index (the current behaviour with explicit paths). > > I'd suggest "--incremental" instead of "--also". > > > - "git commit fileA..." means: create a temporary index from the > > current HEAD commit (or empty index if there is none), update > > it at listed paths (add/remove if necessary) and commit the > > resulting tree. Also update the real index at the listed > > paths (add/remove if necessary). In the original index file, > > the paths listed must be either empty or match exactly the > > HEAD commit -- otherwise we error out (Linus' suggestion). > > Yes. Agreed. > > - "git commit" means: update index with all local changes and > > then commit the tree described in index (current "-a" > > behaviour). > > No. Please no. "git commit" should continue to do what it does now. > Otherwise you can't do the two-stage thing in any sane way. > > Requiring "--incremental"/"--also" is very confusing. > > If somebody doesn't know about the index, he normally will never have > index changes _anyway_, except for the "git add" case. In which case "git > commit" does the right thing for him: it will either commit the added > files, or it will say "nothing to commit". Sensible. As long as "commit files..." actually commits _only_ those files unless --index (or something) is specified to also explicitly include the index changes. What is really counter-intuitive is to have index changes merged by default when a single file is specified as argument to commit. Nicolas