Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Wed, 17 Jun 2009, Junio C Hamano wrote: > ... >> The commit not only must begin with "squash to " but also there has to >> be a matching commit whose message begins with the remainder of the >> title of the "squash to" commit _in the range you are rebasing >> INTERACTIVELY_. >> >> In addition, the resulting rebase insn is presented in the editor, and >> in a rare case where you do have such a commit, you can rearrange it >> back. > > Well, that really sounds pretty awkward to me. I regularly call such > commits "amend". If there is a risk I confuse myself as to which commit > needs to be amended, I use "amend.<short-hint>". > > I'd really rather stay with "fixup". And as I use single-letter commands > quite often, I'd also rather stay away from that magic "!". And by > "magic" I really mean that: people will not find that magic intuitive at > all. > > My vote is for "fixup". I am too tired to either make the final judgement nor proposal on this topic now, but before I forget here is one tangent. 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 ... -- 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