Re: [Q] Mark files for later commit?

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 29, 2011, 06:49 UTC
Message-ID: <7voc4uto9o.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTi=rPAQas3gvHJ+EFYTXP_YXuULQMk8o8pgkj=9T@mail.gmail.com>

Daniel Nyström <daniel.nystrom@timeterminal.se> writes:

Show 10 quoted lines

> So this makes me wonder, is there a way to mark certain files for
> being committed later on? Which does not automatically get added to
> the staging area (on "git commit -a" or "git add ." and so on) unless
> it's specifically mentioned by "git add"?
>
> We've discussed making it generated automatically, but that's not as
> easy as it may sound.
>
> How would you like a git feature like described above, marking files
> for later inclusion?

That does not sound like a feature but merely a source of confusion.

So far, "commit -a", "add", "add ." etc have _all_ been a way to tell git to add the current state of the content to the index. What is the point of making it more complex by letting the user say "I am telling you to add everything in the working tree by explicitly saying 'git add .', but I do not really mean it"?

In the meantime, some misguided souls might suggest assume-unchanged, but that is not guaranteed to work for this purpose, so ignore them. This is because assume-unchanged is a promise you make git that you will _not_ change the working tree files, and that promise implies a permission for git to use blob object recorded in the index that corresponds to such a path instead of reading from the working tree files while doing certain operations (such as "git diff") if it is more convenient.