Re: [Q] Mark files for later commit?

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 29.03.2011 08:49:
> Daniel Nyström <daniel.nystrom@timeterminal.se> writes:
> 
>> 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.
> 

While I've used assume-unchanged before, it really is a great foot-gun
(to shoot yourself into...) to be used only when circumstances force you.

In your case, if you really can't use shortlog or the like, a "light"
way of generating a changelog might be using notes. Attach changelog
notes to each commit (maybe in refs/notes/changelog rather than the
standard). Then, when you need to create the changelog between vX and
vY, you can do

git log --pretty="%N%n" vX..vY

(and go wild on the pretty format, of course). Note that you can share
notes when you set up refspecs etc in a push/pull based workflow. (I'm
not sure how well we support merging/pulling notes refs yet.) This does
not work well in a patch/e-mail-based workflow.

Michael