Junio C Hamano wrote:

>I am reluctant to actually do this right away, because this is
>an incompatible change from the current format:
>    $ git format-patch his mine

Of course this breaks qgit interface to git-format-patch-script
but if you think it's better this way....

>The same goes for rebase (and therefore cherry).  I could use an
>ugly heuristics for backward compatibility like "if invoked with
>exactly two parameters, and there is no prefix ^ nor .. in these
>two, then use the old interpretation, otherwise give them to
>rev-parse", but I think this is ugly.
>So my question to the list is: do people mind this change?

I think it's ugly too, in this early phase of git development 
better go with proper solution then compatibility compromises.

A suggestion I would like to present is if can be useful a
kind of scheduling/list of planned compatibility break features so
 that developers can know in advance when and what will break
 their stuff and users can know when they will need to upgrade.

Start your day with Yahoo! - make it your home page 
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to