Nicolas Sebrecht <nicolas.s.dev@xxxxxx> writes: > The 18/06/09, Johannes Schindelin wrote: > >> > When the commit log message begins with "squash to ...", and there >> >> I do not like this at all. It assumes that you never have valid commit >> messages starting with "squash to". > > Plus, a commit message should not be anything else that a message about > a commit. Please, don't make the Git's behavior depends on the commit > message itself. > > If we need a program to have various behaviours, we have: > - the compilation options; > - the command line options; > - the configuration files. Sorry, but I have to disagree to such a dogmatic statement. 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"). 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"? I do not necessarily think the behaviour suggested by the patch should be the default, but as an optional feature, it makes perfect sense for a command to pay attention to commit messages when deciding what to do. IOW, I understand Dscho's objection that there is a risk that this feature may trigger when not wanted (but more on this later), and I'd be fine if it can fire only with an extra option, e.g. "git rebase -i --autosquash". But from the workflow point of view, I think what the patch tries to do (I haven't studied the actual implementation carefully, so it may not be what it actually _does_) makes perfect sense, and it matches what I often do very well. Accumulate changes as a series of basically sound commits, queue some small "fix this breakage in that commit" commits on top of them while proofreading, and finish the series with "rebase -i" to reorder, squash and typofix. Now, I initially had the same reaction as Dscho. What happens if I really want to write a commit message that begins with "squash to "? But after thinking about it a bit more, I do not think it is as bad as it sounds anymore. 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. -- 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