The 17/06/09, Junio C Hamano wrote: > We do want our commands to be able to act intelligently and/or differently > depending on what commit says in some cases. It is does not make sense to > insist that the command line or configuration mechanism must be used. > > A really trivial example. "git log -p" shows the patch text for non-merge > commits but not for merge commits. "git log --grep=foo" shows only > commits that says "foo" and "git log --author=Nicolas" shows only commits > written by you. We used to leave an explicit note in the message part of > cherry-picked commits where they were cherry-picked from; "git merge" > and/or "git rebase" could have paid attention to it to act differently > (i.e. "ah, even though that commit is not in the ancestry, the moral > equivalent patch is already applied"). But I see a huge difference between a message added by the program itself to act well on possible comming cases and a message added by the user to act differently at the commit time. The latter case is exposed to the user mistakes (wrong typo, unintentional matching pattern, etc) which could leave the repository in unexpected states. Git is enough hard to learn. Please, don't make the learning curve even worse. Having the commit message possibly making git acts differently is not usual or expected by most users. > Besides, if you as the end user want to tell this and that commit are > special among other commits that are being rebased to the command, which > is the scenario Nana's patch is about, how would you do that from the > command line option? "rebase -i --move=4-to-2 --squash=2"? Well, as we always squash to one of the first direct ancestor and as squashing to a merge is not usual (here at least), in most cases it just gives "rebase -i --move=4-to-2" wich sounds reasonable enough to me. -- 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