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
http://www.yahoo.com/r/hs
-
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
