Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]

[Michael J Gruber <michaeljgruber+gmane@fastmail.fm>]

Johannes Schindelin venit, vidit, dixit 17.07.2008 20:43:
> Hi,
> 
> On Thu, 17 Jul 2008, Junio C Hamano wrote:
> 
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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