Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. Let's step back a bit, as I think "mark them not to be added" is a classic XY problem. First let's concentrate on this part: "a certain file contains a human written changelog, which is modified (not prepended) for each single commit in the project, is being committed along with the actual patch." Doesn't that sound quite similar to our release notes? So far, I've been updating the file after topics graduate to the 'master' branch, but there is no fundamental reason not to make it a responsibility of the patch contributors to add an entry to the release notes when they make their changes to the system. Then when the topics graduate, the entry that describes the topic will be automatically merged into the release notes of the 'master' branch. What will happen if we made that the convention of our project? For one thing, I don't have to spend time on coming up with a concise and clear description of the topics (the contributor that worked on the topic should be better equipped to describe it than I am). People may make their own entries in the single release notes file in various places (by convention, the entries are sorted by the name of the command the change affects, except for the ones that have system-wide effects that are described at the top), and merging them might produce many conflicts, though. But what choice would I have? Obviously I shouldn't be punting on the merges, taking one side of the release notes file as the merge result using "-s ours" or other silly magic and discarding the valuable input from contributors. I _do_ want all the release notes entries from all topics. Merging such a conflict-heavy file and keeping it maintained properly is an important part of the job (iow, "suck it up"). I suspect that using the "union" merge attribute may be a possibility in this case; even though the release notes is not an "append only" file, it is an "insert only" file, and it is a very good candidate for the union merge driver. Now let's look at this part: "The changelog is only supposed to be committed at new releases, but is kept maintained continuously so stuff won't be forgotten." You are willing to leave your changes uncommitted in the working tree, and not committing it until the release (perhaps using your Y solution that lets you mark it not to be committed without --force option), is perfectly Ok by you. You are not getting any accident protection benefit from your SCM until the next release point and the intermediate changes between releases you make to this file are not version controlled. 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. That would still require you to find a relevant entry in changelog+ and modify the true changelog file if you cherry pick a particular change to an older maintenance track and make a release out of it. Keeping the entries in the changelog, and cherry picking the changes together with the associated entries will probably reduce that "remembering" mental burden, while it may require trivial conflict resolutions in the file that can be helped with the union merge driver. Just a few cents. -- 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