The 18/06/09, Junio C Hamano wrote: > I also often use "magic" commit log message in other occasions. The most > important is "[DONTMERGE]" prefix to somebody else's commit I queue to > 'pu' (or leave unmerged even to 'pu'---just keeping on a topic branch). I > accept a patch with "am" and then "amend" after review when I find that it > needs more work. One day I am hoping to write a pre-merge hook that > forbids commits marked with such magic to come into 'next' and down. > > The point? > > Earlier somebody objected to a command that changes behaviour based on > what is in the commit log message, but for the private commits the patch > under discussion deals with and the ones I mark with "[DONTMERGE]", the > commit log message _is_ the right place to leave a mark for commands to > take notice and act differently. > > Of course we _could_ use notes for that, but that won't play well with > rebasing I suppose ... Not for now; you're right. But what I see here is all about commit/branch metadata to make our like with workflows easier. What about implementing a true metadata feature into Git? There are a lot of nice possible functionalities around metadata. Fast, stupid and superficial thoughts on that: - have metadata to make git to act differently and/or for information purpose; - let the user create its own metadata for his own purpose; - let the user have hooks script where appropriate. -- Nicolas Sebrecht -- 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