On 2014-09-24 11:00-0700 David MacMahon wrote: > Hi, Alan, > > On Sep 23, 2014, at 10:41 PM, Alan W. Irwin wrote: > >> On 2014-09-23 16:01-0700 David MacMahon wrote: >> >>> Just to nit pick: [...] >> >> Your comment above caught this nit-picker's attention. :-) > > Takes one to know one! :-) :-) :-) > >> What I was referring to (see README.developers) is we recommend each >> developer configure their local PLplot git repo using >> >> git config merge.ff only > > Maybe I'm just getting caught up on the semantics of the word "enforcement", > but I don't consider that client side enforcement. It requires developer > intervention to setup and can be overridden via the --no-ff option. If that > counts as client side enforcement, then you could just as easily consider a > client side pre-commit hook to be client side enforcement. That also > requires developer intervention and has a command line override (--no-verify). > >> This command should stop merge commits of any kind for the local >> PLplot repo where it is run. > > This prevents (in the absence of --no-ff) the local creation of merge > commits, but it does not prevent merge commits from appearing in the history. > >> I agree one of the client-side merges >> tested by this configuration occurs just before the push in our >> workflow so you could claim it is just a pre-push check. However, I >> think it is a little broader than that. For example, if the PLplot >> developer made some mistake by doing a git fetch and merge or >> equivalent git pull from some random unofficial private PLplot >> repository that included merge commits by accident, my understanding >> is this configuration option would catch that issue before the local >> repo was contaminated by those merge commits. >
> I think you are expecting too much from --ff-only. Running "get merge --ff-only new_branch" while on the master branch will prevent the creation of a merge commit if master cannot be fast-forwarded to new_branch. It will NOT prevent the fast forwarding of master to new_branch if any of the intervening commits are merge commits. git will happily fast forward master over any number of merge commits so long as master is an ancestor of new_branch. > What could happen is that a PLplot developer starts with master that is up-to-date with sf.net and with "merge.ff=only" configured locally. Then the developer fetches a bunch of commits (that include merge commits) from a rogue repo. The rogue repo's build tests out OK, so the developer pushes the commits (including the merge commits) to the master branch on sf.net. None of this is prevented by --ff-only. With an suitable server side hook, the server side could reject the push, otherwise the public repo will end up with merge commits from the rogue repo. > A client-side pre-commit hook could alert the developer to merge commits in the history, but that only fires if a commit is being done. A client-side pre-push hook could alert the developer to this situation before pushing, but that would happen only slightly sooner than a server-side pre-commit hook would reject things. Thanks very much for these clarifications of the limitations of git merge --ff-only for the case where a PLplot developer uses a non-official repo where someone by accident has done a merge commit in violation of our workflow policy. Of course, PLplot development is (thank God) far from a police state. Instead, we expect all PLplot developers to be responsible about using non-official repos, i.e., use with extreme caution and especially pay close attention to the caveats concerning sharing work via non-official repos that are mentioned in README.developers. The only "enforcement" of our workflow policy that we do now is a suitable server side hook has been put in place to prevent merge commits being pushed and deletion of tags on the remote. See git_hooks/update. I have tested this hook with a test remote repo, and it appears to work as expected. For the others here, it is this server-side hook that is generating such messages as remote: Checking: commit 6f5dc7b546f05c79af9c6f406bd0c9db0f38736c on master not a merge commit (ok) remote: Checking: commit fce8ae116d4e0479d1ee9c5455b1198659262105 on master not a merge commit (ok) when you push your commits to our SF server repo. If you ever get a message that that test is failing, then you should carefully review the commits you are trying to push and figure out a way to get your desired changes on your local master branch without using merge commits before you push that local master branch to origin master. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
