From: Michael J Gruber Date: Fri, 18 Jul 2008 09:55:35 GMT Subject: Addremove equivalent [was: Re: Considering teaching plumbing to users harmful] Message-ID: <48806897.1080404@fastmail.fm> In-Reply-To: Johannes Schindelin venit, vidit, dixit 17.07.2008 20:43: > Hi, > > On Thu, 17 Jul 2008, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >>>> Is there a way to commit the contents of a tarball without using >>>> plumbing? I occasionally want to track an upstream that I know only >>>> as a series of tarballs, so I do something like: >>>> >>>> cd repo/ >>>> git checkout upstream >>>> rm -rf * >>>> tar -xzvf ../new-version.tar.gz >>> How about "git add -u" and "git add ."? >> It would work only if new version never removes files. > > You made me doubt for a second there. But "git add -u" updates the index > when a tracked files was deleted. So after "rm -rf *", "git add -u" would > empty the index. This brings me to a question I never dared to ask so far. In fact, I'm happy with git-add and using the index explicitly rather than implicitly. Still, sometimes I find my self wanting an "addremove", such as in a situation like above. (E.g., tracking a dir which is synced by different means.) Say I have a modified file a, removed file b (rm'ed, not git-rm'ed) and a new file c. Then: git add . would add the changes to a and c git add -u would add the changes to a and (the removal of) b git commit -a would commit the changes to a and b (it does add -u + commit) So, if I want to add and commit all three kinds of changes using porcelaine I have to do: git add . git commit -a or git add . git add -u git commit AFAICT this means that git will scan for modifications to tracked files which still exist twice. While this will be noticeable only with large dirs on slow FS it's conceptually not so nice. Is there any (porc.) way around? I don't know the internals, though; maybe there's no second scan (stat...). Cheers Michael