Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > .... As a person reading the history, I admit I don't like it. > I enjoyed being able to get a simple overview at a higher level of > what has been happening in "pu" with "git log --merges junio/pu" or > "git log --first-parent junio/pu", and these extra lines before and > adjacent to the "* name of topic:" header interfere with that. I'd hold making that judgement for a several weeks until my eyes get used to if I were you. I've seen that people (including myself) react really badly to _any_ change and make loud noises (including "we will never get used to this updated output, it is horrible!"), and then eventually get used to it as if nothing happened, and that happened often enough recently. In any case, if you only look at "git log --first-parent" output and search for your own topic, it of course is useless to see your name there, as you already know. > By contrast, the > ... > descriptions in Linus's repo are very pleasant. When you compare Linus's history and my history between master..pu, you are literally comparing apples and oranges. The merges between master..pu are made several times a day, with a series of mechanical "merge --no-edit" process and automated tree tweaking (including but not limited to rerere). The purpose of these merges is primarily to reduce the risk of mismerges to master (and next to a lessor degree), especially when one topic among many that have been cooking between master..pu gets closer to graduation. By shuffling the order of topics that are merged between master..pu so that topics close to graduation come earlier in the fully rebuilt pu, a mid-point in master..pu is verified to exactly match the tree of next (otherwise you may have spotted a mismerge to next, and I did spot a few mismerges to next this way). This also allows earlier parts of the master..pu to be tested individually. The purpose of these merges is _not_ about describing what the side branches are about. Unlike Linus's lieutenants' "for-linus" branch names, the branch names are often enough to describe that they are. On the other hand, the merges on Linus's tree are etched in stone, and he has every incentive to record what happened in the side branch for the _last_ time with carefully chosen words. Having said that, I tweaked the automated rebuilding procedure a bit today, and made it annotate these merges with snippets from the branch description in the "What's cooking" document, so the commits on master..pu are hopefully "very pleasant"ly annotated. This not only prettifies the merges between master..pu, but more importantly, would save effort to explain the merges when a topic finally hits master. If I have a good description in "What's cooking", I can then reuse it in these merges and also in the release notes. The update to the rebuild procedure is not published yet. I'll be playing with it for a few days before publishing the changes. -- 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