Duy Nguyen <pclo...@gmail.com> writes: > On Thu, Jan 10, 2013 at 4:04 AM, Junio C Hamano <gits...@pobox.com> 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