[chirp_devel] git vs hg patches [was: [PATCH 1/4] chirp.py: add --list-radios option (#2343)]

Dan Smith
Tue Feb 24 09:35:13 PST 2015


> When designing parsers, the rule is to be strict in what you emit
> and liberal in what you accept.

Surely. But I'm not writing a parser, I'm just importing the patches
with all the mercurial metadata that comes with an export. If it's not a
mercurial patch, then I have to take a completely different path of
generating that metadata and using different tools to apply and commit.

> I think that's also a good rule when it comes to handling patches in
> an open source project.  Creating a script to import a git patch
> series would be a one-time process, and it lowers to bar of entry for
> potential contributors.

So if we were on github and someone wanted to send raw diffs against
random non-tip points in the tree to the mailing list, someone should
take the time and just create pull requests out of them all? I think if
we were on github, such a request would be met with "dude, just create a
pull request!"

Most open source projects, especially ones run and funded by volunteers,
have contribution guidelines to make it easy on everyone. All the
required mercurial-fu is documented on the process page and I expect
we've spent more time discussing it than it takes to generate patches :)

> But I'll suck it up and learn to push my patches through Mercurial.
> I'm still going to use git and hg-git for my development though,
> because the workflow is so ingrained.

As long as they 'hg import' cleanly to the main repo, that's all I care
about. Thanks!

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20150224/f419ed98/attachment-0001.bin 


More information about the chirp_devel mailing list