Jerome Lovy <t2a2e9z8ncbs9qg@xxxxxxxxxxxxx> writes: > Johannes Schindelin wrote: >> On Thu, 14 Dec 2006, Andy Parkins wrote: >> >>> "master" shouldn't get special treatment; making different log >>> messages based on the name of the branch is bad form. What if a >>> user likes "my/master" or "my/head" as their master branch? >> >> I do not agree. There is usually a principal branch, where you >> collect the topics, and you do want to treat that special. As for >> the name: better have a convention here than configurability. You >> would not want "git" to be called "guitar" for some users, just >> because they happen to like that name more, either, right? > > because I like the pattern framework described in the book "Software > Configuration Management Patterns", I like to use "mainline" instead > of "master", for example. Tough. Like it or not, 'master' has been the name of the default branch since very early days of git (May 30, 2005). I think you guys are barking up the wrong tree. I do not agree it is wrong to treat the principal branch (or branches, such as my 'master' and 'maint', or Jeff's 'ALL' and 'upstream') in a different way from other branches. Quite the opposite. It is a wonderful thing for something like fmt-merge-message. The recommended workflow when you have topic branches is to cook new things in the topics and merge them into principal branches, and never merge the other way or across topics unless you absolutely need to (i.e. the topic's evolution depends on something new in your principal branches or another topic). So merging into your principal branch is a normal event and giving short message makes tons of sense, while merging into a topic is an abnormal situation that warrants "into this-topic" along with an explanation why that unusual cross merge was needed. What we could improve is to allow people to use different names other than 'master' for their principal branches, to help use of words like 'mainline' and 'upstream'. We can have a new configuration under "branch.*" namespace to mark branches that tells fmt-merge-msg to drop "into branch" part from its output. When you have more than one principal branches, it may be useful be able to tell which principal branch was merged into with a particular merge, and in such a situation, you may want your config to tell fmt-merge-msg not to drop "into branch" for any branch. On this "master is not special" topic, I would accept the 'status' patch that always makes it to say "on this branch" for all branches, but this is not because 'master' is not special. Committing on principal branches and committing on topic branches both happen as a normal event, and I think it is not unusual to have more than one principal branches in an advanced usage scenario. It is very prudent thing to remind the user what branch he is on, so that he can tell he is about to make a commit on a wrong branch. - 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