[PATCH] commitextras: move fb's extension which add extras to a commit to core

Sean Farley sean at farley.io
Fri Jul 7 14:33:58 EDT 2017


Kevin Bullock <kbullock+mercurial at ringworld.org> writes:

>> On Jul 7, 2017, at 13:25, Martin von Zweigbergk via Mercurial-devel <mercurial-devel at mercurial-scm.org> wrote:
>> 
>> On Fri, Jul 7, 2017 at 11:23 AM, Sean Farley <sean at farley.io> wrote:
>>> 
>>> Yuya Nishihara <yuya at tcha.org> writes:
>>>> 
>>>> debugcommit seems fine.
>>>> 
>>>> FWIW, --extra value will need some encoding handling depending on its
>>>> type, e.g. convert labels to utf-8, but keep file path as bytes.
>>> 
>>> Yeah, seems fine to me too. But was there any reason we're avoiding the
>>> path of new-thing-as-extension first, then into core second?
>> 
>> If we decide to put it in debugcommit, we provide no BC guarantee
>> (AFAIK), so we can remove it later if we see a reason. That buys us
>> the same flexibility as having it in an extensions, it seems.
>
> Hmm, I'm not sure we throw out BC guarantees for debug commands. Per <https://www.mercurial-scm.org/wiki/CompatibilityRules#Commands>, there is somewhat of a gradient to the strength of BC guarantees, but as I read it, debug commands aren't exempt.
>
> Also just as a reminder for those following along, we only suspend the BC guarantees for extensions that are marked EXPERIMENTAL.

Ah, yeah. Though, I might disagree a bit with debug* being BC that's
another discussion entirely.

For this case, it would seem that marking this as an EXPERIMENTAL
extension that adds the 'debugcommit' command would cover all these
points / issues?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170707/b99f34ec/attachment.sig>


More information about the Mercurial-devel mailing list