Duy Nguyen writes:
> On Thu, Jan 10, 2013 at 4:04 AM, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'.
>
> I see you start to use no-change commits as a way to keep notes in
> 'pu'. Isn't git notes designed for that?
It is not designed for this.
You could (ab)use notes for that purpose, but at the semantic level,
I do not think notes is a good match.
The branches 'pu' and its subset 'jch' (designed to be slightly
ahead of 'next', and this is what I regularly do my Git work with)
are rebuilt on top of 'master' in every integration cycle (like 2 to
3 times a day). The insn to rebuild the latter currently looks like
this (familiarity with the Documentation/howto/maintain-git.txt
document in 'pu' would help understanding this section):
$ cat Meta/redo-jch.sh
Meta/Reintegrate <<\EOF
jc/format-patch-reroll
nd/retire-fnmatch
...
jk/maint-fast-import-doc-reorder
nd/upload-pack-shallow-must-be-commit
ap/log-mailmap
### match next
jc/doc-maintainer
mk/complete-tcsh
pe/doc-email-env-is-trumped-by-config
as/check-ignore
EOF
The Reintegrate machinery merges the topic listed on each line, and
the "### match next" marks the point _between_ the two merges to
remind me that merging everything before this line to 'master' must
match what the 'next' branch has. The markers on 'pu' are similar.
You can emulate that semantics by attaching a note to the merge
commit that merges ap/log-mailmap topic, but that is unwieldy, and
more importantly, it does not correctly express the meaning of the
marker. I often reorder lines before that "### match next" marker
between integration rounds, to float topics that are more ready than
others near the top, to make sure that they do not depend on other
topics and cause mismerges when merged to 'master' without others.
The next integration cycle may have ap/log-mailmap earlier, e.g.
$ cat Meta/redo-jch.sh
Meta/Reintegrate <<\EOF
nd/upload-pack-shallow-must-be-commit
ap/log-mailmap
jc/format-patch-reroll
...
jk/maint-fast-import-doc-reorder
nd/retire-fnmatch
### match next
jc/doc-maintainer
mk/complete-tcsh
...
and having a note on the previous merge of ap/log-mailmap does not
help expressing the semantics correctly. It is not like I cease to
declare the merge of ap/log-mailmap ought to match 'next' and now
declare the merge of nk/retire-fnmatch ought to match 'next'.
It's much clearer to have the marker as a separate entity, as
opposed to emulating it with an attribute of a merge commit that
happens to be adjacent to what I really want to mark (i.e. a place
*between* two merge commits).
Another way you could use notes to emulate this is to give each
merge that comes before the marker line a note that says "this merge
is before the marker line". But it still is more work to present
the result as "here is a sequence, then a marker, and then another
sequence, then another marker...". In short, notes may be able to
emulate it but it is not the best tool for the job.
It is not like I'll be running format-patch and rebasing these
throw-away integration branches, so no-change commits are the best
way to express what I want to in the history.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
