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. 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
