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