[chirp_devel] git vs hg patches [was: [PATCH 1/4] chirp.py: add --list-radios option (#2343)]
Dan Smith
Tue Feb 24 11:42:45 PST 2015
> Good points. Even with hg's mq, don't developers already need to
> handle tip moving underneath?
Yes, but that's the point of mq. If they have to commit the patches in
mq in order to submit, then they have to rip them out and back into mq
patches in order to revise, then repeat the process. It'd be insanely
painful, which is why I say we really need to agree to move entirely
away from mq, as bridging _that_ gap locally is not a reasonable workflow.
> One of the reasons that I love git is 'rebase' (and I see that
> mercurial has its own variant of it). These days, I can't imagine
> doing development without it, particularly when dealing with projects
> where the tip/master branch is moving fast.
Yeah, but mq is less complicated than rebase, and more
flexible/forgiving. The first time a non-power-user accidentally does a
commit whilst in a rebase merge and has to reflog their way back to
their code, I'd expect to hear some frustration. Since I really value
contributions from those people, the text-patch-based approach of mq is
simpler, safer, and more predictable for them. Maybe those people will
be happy with guilt as a substitute (although I wasn't).
Like I say, I use git all day long for work and would like the benefits
it brings for testing branches. However, I also spend time most weeks
helping (or watching) professional developers work (or struggle) with
git. I just want to make sure we don't lower the bar for git-preferring
people and raise the bar for everyone else.
--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/ff7b81c9/attachment-0001.bin
More information about the chirp_devel
mailing list