Hi, Alan, On Sep 23, 2014, at 12:35 PM, Alan W. Irwin wrote:
> On 2014-09-23 09:54-0700 David MacMahon wrote: > >> Emailing patches is tedious and error prone. > > I disagree. I have been applying user-generated patches to PLplot for > years without any patch-related errors. And I really like the git > format-patch command to generate a patch (which I have used to submit > fixes to the cmake developer's list just like many others do there > because that is the patch format particularly encouraged by Brad King > for use by external developers). And I have had no problem already > applying (using git am) an external patch for PLplot a git > format-patch to PLplot supplied by an external developer. And sharing > work using patches generated by git format-patch has not been an issue > for years on the cmake-devel mailing list, the wine-devel list, and > for the X intel graphics list and the cairo list when I was monitoring > those. OK, maybe I my tolerance for handling patches is lower than others'. Git certainly does make it easy to generate and apply patches. It's almost the same a low-tech push/pull. Applying patches to the same commit from which they were generated will create a sequence of commits that have the same tree contents, log messages, and author info, but this sequence of commits will have different committer info and therefore they will be different commits (i.e. have different commit IDs). There are two issues here: 1) correctly applied patches will create different commits than the originals and 2) the patch files contain only the before/after SHA1 IDs of the patched files but no information about the un-patched files, which means that it is possible to successfully apply the patches to the incorrect commit. Issue 1 results in collaborators having different commit IDs for what are otherwise the same commit which can lead to confusion. Issue 2 results in collaborators having to carefully s pecify which commits their patches are based on (or more broadly applicable to) yet because of issue 1 they can't use commit IDs to do that. Yuck! In practice, this is rarely a problem for occasional/casual contributors, but for two actively collaborating developers sending patches back and forth it can be. >> Hope this helps > > Yes it does because workflow choice is an extremely important topic to > discuss for any group developing software using git. I think we are > mostly in agreement here. I'm happy to offer my thoughts where they are appreciated. I agree that we are mostly in agreement! :-) > note that > there is no simple way to enforce the first-parent workflow on the > client side. Push hooks can provide server-side enforcements, but I don't think git provides any way to enforce client-side workflows. > In contrast, that can easily be done for the current > rebase workflow (see our README.developers file for details) so that > our developers have the opportunity to catch rebase workflow errors > right away rather than having to wait to see whether the server > rejects their push. Just to nit pick: isn't this more of a pre-push check rather than client side enforcement? Nit picking aside, I agree that with rebase-only it easier to check for potential push problems on the client side *before* pushing. It sounds like you are on a prudent path forward! Dave ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
