Re: [Q] Mark files for later commit?

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

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.