Daniel Nyström venit, vidit, dixit 29.03.2011 11:18: > Den 29 mars 2011 09:51 skrev Junio C Hamano <gitster@xxxxxxxxx>: >>> Daniel Nyström <daniel.nystrom@xxxxxxxxxxxxxxx> writes: >>>> 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. >> >> If that is the case, then probably you shouldn't be even updating the >> "changelog" file constantly to begin with. Instead, how about creating a >> separate "changelog+" file that is not tracked, and keep its contents >> maintained continuously so stuff won't be forgotten? When the time to >> release comes, you can "mv changelog changelog", and commit it. > > If we ignore this particular case, how would a "git hold <file>..." feature do? > -- > $ git status > # On branch master > # Changed but not updated: > # (use "git add <file>..." to update what will be committed) > # (use "git checkout -- <file>..." to discard changes in working directory) > # > # modified: package/qt/qt.mk > # > # Changed but on hold: > # (use "git add --holds <file>..." to update what will be committed) > # > # modified: CHANGES > # > no changes added to commit (use "git add" and/or "git commit -a") > -- > Would there be other use-cases? As Junio pointed out, your "hold file" (ChangeLog+) is really not versioned (tracked) at all, so it has no place in the worktree. Otherwise you'll have constant nagging during the release cycle one way or the other, if you want git to remind you of the files on hold. If you don't need the reminder, git does not need to know about the file. Simply store it somewhere else (such as in .git/description if you don't use that, or under .git/info/). 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