[PATCH] Re: rebase -i: auto-squash commits

[Nicolas Sebrecht <nicolas.s.dev@gmx.fr>]

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