Junio C Hamano venit, vidit, dixit 29.03.2011 08:49: > Daniel NystrÃm <daniel.nystrom@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html