[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