Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

On 2014-08-21 06:20-0400 Hazen Babcock wrote:

>>
>> @Everybody:
>> Instead of writing a rebase workflow document myself that we could
>> use, I have been looking for something like that written by someone
>> else. What do you think of adopting (the quite restrictive) rebase
>> workflow outlined in
>>  to start?  No
>> integration branches other than master.  No published topic branches.
>> But dead simple and very much like our previous svn-based workflow.
>
> Looks good to me. I think we should at least make a copy in the project,
> which I volunteer to do once we can commit again.  I'll update
> README.developers unless someone thinks this is better somewhere else.

Yes, please!

I think this deserves its own file.  So I assume you will call that
file README.git_workflow, and I will output that name to the user in
the update hook logic I hope to test (in a mini-project) and then
install in our SF repo later today.  Once I get that installed, I will
make the git repo pushable by all our developers, and we will be live!

> Also, we need to update our web-page to point to the git repository and
> not the svn repository.

That should be on our ToDo list, but first all the scripts that update
the website have to be changed from svn logic to equivalent git logic.
I will likely let all this slide for a while (maybe even until we make
our first post-git release several months from now) until I get a lot
more used to using git.

The alternative was asking you to do that website update, but when I
took over the website update duty from you as release manager, there
was a nasty permissions issue that took a lot of commands done by hand
(deleting directory and contents at SF working up from the deepest
subdirectories using sftp commands) to straighten out.  So if we
switch to you now (just for the website update) you would have to deal
with that permissions issue again by hand.  (I am pretty sure there is
a way to overcome these permission issues in an automatic way (perhaps
by playing with the group permissions), but I haven't figured that
out.)

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
__

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

>
> @Everybody:
> Instead of writing a rebase workflow document myself that we could
> use, I have been looking for something like that written by someone
> else. What do you think of adopting (the quite restrictive) rebase
> workflow outlined in
>  to start?  No
> integration branches other than master.  No published topic branches.
> But dead simple and very much like our previous svn-based workflow.

Looks good to me. I think we should at least make a copy in the project, 
which I volunteer to do once we can commit again.  I'll update 
README.developers unless someone thinks this is better somewhere else.

Also, we need to update our web-page to point to the git repository and 
not the svn repository.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

Correcting the subject line..

On 8/20/2014 11:29 AM, Hazen Babcock wrote:
> On 8/20/2014 5:51 AM, plplot-devel-requ...@lists.sourceforge.net wrote:
>> Date: Tue, 19 Aug 2014 12:24:54 -0700 (PDT)
>> From: "Alan W. Irwin" 
>
> ..
>
>> In sum, I think rebase-only is not only back on the table for our
>> initial workflow model due to Brad's recommendation of it for that
>> purpose but also likely the final choice (enforced by server-side
>> update hook logic at push time as recommended by Brad).
>
> I'm also ok with rebase only, at least to start. I think it should work
> well enough as the project is not super active so we should not have too
> many problems with "racing to commit". I agree with Phil that this will
> mean that there is only a master branch.
>
> One project that has taken this approach is SBCL:
> http://www.sbcl.org/
>
> Thoughtfully they provide the hook that they use to enforce rebase only
> on their master branch:
> http://sourceforge.net/p/sbcl/sbcl-git-hooks/ci/master/tree/update
>
> -Hazen
>


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

Below is another extremely useful e-mail from Brad King that I
would like to preserve on the plplot-devel list because it includes
the detailed update hook logic needed for enforcement of
a good history shape for a merge workflow and other useful comments.  If we 
decide to
start with a merge workflow, we can use this logic immediately.  If
we decide instead to follow Brad's suggestion of starting with
a rebase workflow and moving to a merge workflow later, then
this logic will be useful on that later occasion.

Note, buried in Brad's e-mail from yesterday was a comment on
the alternative update hook enforcement logic
for the rebase workflow which I repeat here to make sure
the two alternative sets of update hook logic appear in the same e-mail.

[For the rebase approach u]se a server-side "update" hook to check that every 
commit in
"git rev-list $oldrev..$newrev" has only one parent.

That is not as detailed as what he said below, but I think it should
be completely straightforward to figure out a bash loop to stick in
the update hook to check a list of commits created as above to make
sure if developers have used merges they have been of the fast-forward
variety.

So Brad has effectively supplied the update hook enforcement logic we
need for each of the two general rebase or merge workflow
alternatives.  The next thing we have to do is to decide whether we
adopt rebase workflow now and move to merge workflow later (as
suggested by Brad to all groups of developers he has advised who are
starting out with git) or jump into merge workflow immediately.  As I
said earlier today, I am leaning pretty hard towards Brad's
suggestion, but I would appreciate your comments on this issue, and I
also need some time to read more about rebase workflow before we come
to a final decision.  With your help, I hope that decision is by late
this week so we can start developing PLplot using git without too much
further delay.

To summarize what has been going on so far in these discussions, I
discovered very soon in my wholesale introduction to git that merges
are an incredibly powerful weapon in the git arsenal.  And I think
everyone who has more experience with git or done their initial
reading about it will confirm that assessment.  So developers for a
given project like PLplot (or timeephem) should have a firm workflow
policy decided in advance about how to constrain the use of that merge
weapon. Thanks to quite useful recent input from Brad King, I think we
are getting much closer to a decision about what initial workflow to
adopt for PLplot.

Alan

On 2014-08-19 15:41-0400 Brad King wrote:

> On 08/18/2014 02:06 PM, Alan W. Irwin wrote:
>> The current set of active core PLplot developers is a small but quite
>> disciplined group, and there has been quite a lot of interest in
>> keeping a clean history shape in discussions of our git workflow.
>
> Okay.
>
>>> I can explain how the history shape hooks work if needed.
>>
>> Thanks. I would appreciate that.
> [snip]
>> I have already looked at the possibility of complementing the update
>> hook rule referred to above with the (voluntary) client-side rules "no
>> merges from next to any branch" and "no merges from master except to
>> next" to implicitly preserve good shape of history.  But I am pretty
>> sure the problem with that approach is identifying the parents and
>> associated branches of the merge commit that is about to take place
>> using a client-side hook. Is that what you are implying by the remark
>> above? If identifying the parents is impossible from the client-side,
>> I will give up on that approach and stick with an update push rule
>> alone.
>
> It is not possible to check this from the client side because it is
> always possible that someone else will win the race to push.  The
> history shape enforcement depend on checking the way a branch head
> moves forward on each push, so it must be server-side.
>
> The server-side history shape checks are implemented in the 'update'
> hook, which gets 'refname', 'oldrev', and 'newrev' arguments.  I'll
> assume they have been parsed into such-named shell variables.  The
> checks are implemented as follows in pseudo-shell code:
>
> * fast-forward update
>  Check that the oldrev is reachable from the newrev:
>
>   base=$(git merge-base $oldrev $newrev)
>   test $base = $oldrev
>
> * first-parent sequence preserved
>  Check that the oldrev is reachable in a first-parent walk from
>  the newrev:
>
>   first=$(git rev-list --reverse --first-parent $oldrev..$newrev | head -n 1)
>   base=$(git rev-parse $first^1)
>   test $base = $oldrev
>
> * 'next' not reachable from other branches
>  The first (merge) commit in 'next' should never be reachable from
>  other branches.  If $refname is not 'next' then check that the
>  commit is not reachable from $newrev:
>
>   if test "$refname" != "refs/heads/next"; then
> base=$(git merge-base $newrev $first_commit_in_next)
> test "$base" != $first_commit_in_next
>   fi
>
> -B

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

I have a lot of respect for Brad King (the git guru for the CMake
software project, and the moving force behind CMake development).
Here is part of what he had to say in response to an e-mail
I sent him.

On 2014-08-18 09:20-0400 Brad King wrote:

> The server side hooks of course go on the server and their impl
> is not visible to clients.  Our server-side hooks are not easily
> re-usable because they are integrated into a bunch of ad-hoc
> custom infrastructure.  However, I can explain how the history
> shape hooks work if needed.

I replied essentially with "yes please", but we will see whether he
responds further to that, and it may be moot (see rebase-only workflow
comments below).

Now to the interesting advice he had in general with my
own remarks to you scattered throughout.

> Having converted many different groups over to Git over the years
> I have some advice:
>
> * Server-side checks form a barrier to entry for newcomers who get
>  frustrated trying to get past them.  Often a history shape
>  failure requires advanced understanding to overcome.  Without
>  such understanding the value of well-shaped history is not clear
>  and the developers get turned off to Git and perhaps to working
>  on your project.

I thought  was
pretty clear on a good model for merge-only workflow and also felt
our developers are disciplined enough to follow this workflow from the
start, but Brad's experience seems to say I am wrong about that, and
we should adopt a much-easier for developers rebase-only workflow
instead (see below).

>
> * For outside contributers, encourage use of "git format-patch"
>  and "git am" to transfer patches by email.  This avoids needing
>  to deal with accounts, authentication, and push instructions,
>  and gives you a chance to review the changes while applying them.

Yep.

>
> * Start off with a rebase-only workflow to preserve linear history.
>  Use a server-side "update" hook to check that every commit in
>  "git rev-list $oldrev..$newrev" has only one parent.  This will
>  give people a chance to get used to the tools without making a
>  mess of history.  When the hook rejects someone's push, have
>  workflow documentation explaining how to rebase.  That is a
>  fairly simple recovery compared to more complex history shapes.

This gets back to Hazen's important question of rebase-only or
merge-only.  And this recommendation from Brad has a lot of impact
since it is coming from the guy who put together the CMake merge-only
workflow that I thought we had the developer discipline to start with.

> * Later when you want to allow merges, have a single integration
>  manager responsible for doing them properly.  Once experience is
>  gained then others can be trained.

I am not keen on this Linus-type central dictator model.  Under
subversion we have trusted all our core developers not to clobber svn/trunk
in the official svn repo (in git terms svn/trunk was effectively our
only branch of development done with a rebase workflow).  The result
was svn/trunk was pretty high quality with only a few minor episodes
where the result was not buildable with default CMake options.  And I
want to continue that model under git where our core developers (the
list given at ) all
take responsibility to produce a high-quality result.  I assume you
do not need a central dictator to get merge-only to work.  But we
don't have to worry about this issue (at least to start) if we adopt a 
rebase-only
workflow initially.

> * When you eventually want to have multiple people merging regularly,
>  use a server-side tool to do the merges for you.  We use Gerrit
>  Code Review for several projects other than CMake.

I included this here to complete his list of recommendations, but let
us ignore it for now since I suspect it is only going to be a
long-term concern if/when we move from our rebase-only workflow.

In sum, I think rebase-only is not only back on the table for our
initial workflow model due to Brad's recommendation of it for that
purpose but also likely the final choice (enforced by server-side
update hook logic at push time as recommended by Brad). There are some
cons to rebase-only (see 

but Brad appears to be practical rather than ideological concerning
the debate between rebase-only and merge-only, and obviously he does
not feel rebase-only would be difficult for us to adopt for our
initial git workflow. Furthermore, we have been using rebase-only
workflow now for a long time (what happens with svn/trunk) so I am now
strongly leaning toward rebase-only for our first git workflow with
periodic review of that decision (say every year or so).

I now have to read more about how rebase-only workflow works for git
(especially for multiple branches which we have not used very much for
subversion) to make sure I see no issues for such an i

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

On 2014-08-17 06:29-0700 phil rosenberg wrote:


Hi Alan
I'm not great with shell scripts - I use them so infrequently I never remember 
the syntax. However I have quickly tried to modify the hook 
fromhttps://gist.github.com/caniszczyk/1327469. Basically you are trying to do 
something like:

git rev-list --first-parent newrev | grep `git rev-list --first-parent 
--max-count=1 oldrev`

where newrev is the revision being pushed and oldrev is the revision being 
updated.

If this gives an empty string then then newrev is not a direct descendant of 
oldrev. This could be because the merge was done the wrong way round (which is 
the check described on the CMAKE page) or because someone has modified oldrev 
on the server before the push occurred.

The command works because git rev-list --first-parent commit lists the sha 
values for each parent of the commit choosing only the first parent, rather 
than the merged in parent in the case of a merge. Therefore if you have merged 
the wrong way the new commit will not inherit from the parent of the old 
commit. Note that the one exception is a fast forward commit, however in this 
case the result is identical no matter which way the merge was performed so it 
makes no difference.

If you intend to have a "next" branch then you could also ensure that the topic 
branch being merged in inherits from master (instead of next or bugfixes or whatever), by 
branching next, making a change to master. Finding the sha for this first commit which is 
not on next and grepping for it in the same way as above.

Attached is my quick hack of that script which just replaces the requirement 
for fast forward merges only, with the requirement above - I haven't tested it 
or tried to run it and it will have windows line endings but I haven't got time 
right now. The syntax might be wrong, but I'm sure you can see the intent. I'm 
sure you can have a look at it and have a play with the git rev-list command to 
see what is happening and add stuff if you like.



Hi Phil:

I am impressed at how far you have gotten with this! This sounds like
it may lead to the exact server-side hook that we need. Note, it is
going to take me a while to follow what you have discovered in any
detail because I am distracted by the client-side hook implementation
that should nicely complement the server-side hook implementation, and
I still need to get up to speed on some of the commands you are using
and relate them to what the wiki says about maintaining a "clean shape
of history".

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
__#!/bin/sh

#
# For each ref, validate the commit.
#
# - It disallows deleting branches without a /.
# - It disallows non fast-forward on branches without a /.
# - It disallows deleting tags without a /.
# - It disallows unannotated tags to be pushed.

validate_ref()
{
# --- Arguments
oldrev=$(git rev-parse $1)
newrev=$(git rev-parse $2)
refname="$3"

allownonffpush=$( git config --bool hooks.allownonffpush )
allowdeletebranch=$( git config --bool hooks.allowdeletebranch )
allowdeletetag=$( git config --bool hooks.allowdeletetag )
allowcreatenottopicbranch=$( git config --bool 
hooks.allowcreatenottopicbranch )
# oldrev could be 0s which means creating refname
# newrev could be 0s which means deleting refname

case "$refname" in
refs/heads/*)
branch=$(expr "$refname" : "refs/heads/\(.*\)")
topicbranch=$(expr "$branch" : "\(.*/.*\)")
topicuser=$(expr "$branch" : "\(.*\)/.*")
if [ 0 -ne $(expr "$newrev" : "0*$") ]; then # deleting
# only topic branches can be deleted
if [ "$allowdeletebranch" != "true" -a -z 
"$topicbranch" ]; then
fail=1
echo >&2 "*** Deleting the branch 
$branch is not permitted. ***"
return
fi
if [  "$allowdeletebranch" != "true" -a "$USER" 
!= "$topicuser" ]; then
fail=1
echo >&2 "*** Deleting the branch 
$branch is not permitted by $USER. ***"
return
 

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

On 2014-08-16 22:55-0400 Hazen Babcock wrote:

> On 8/16/2014 1:50 PM, Alan W. Irwin wrote:
>> On 2014-08-16 06:50-0400 Hezekiah M. Carty wrote:
>> 
>>> I agree with Hazen here - adding hooks on day one seems overkill for
>>> the project.  [...]
>>> Given that the project and developers are overall new to git I think
>>> it would be premature to start stacking automated restrictions on top
>>> of our use of the tool.
>> 
>> That said, I appreciate you and Hazen are anxious to get started with
>> git for PLplot after such a long wait, and I also feel similarly even
>> though I am pretty much still a git newbie.  So I suggest we should
>> jointly review my decision (to not allow push to the official repo
>> until we get the required modification of the update hook figured out)
>> sometime late next week (say roughly in 6 days from now).  That gives
>> enough time to find out if Brad King is willing to share his
>> implementation, and also to pursue a lot further the backup plan of
>> modifying .git/hooks/update(.sample) appropriately ourselves.
>
> Unfortunately all I can report so far is that I have not had much luck with 
> the obvious google searches such as "git hook enforce merge only". So while 
> presumably this enforcement is possible, it also seems to be rare.

Just to give some background for those who are not aware of it yet,
hooks are executable scripts with specific names (from a list
recognized by git) in .git/hooks which can occur on the server side
(the repo that is cloned from, e.g., the official SF repo) or the
client side (the repo that is created by git clone from the server
side repo and which has generic sample files in .git/hooks/*.sample
rather than anything specific from the server side. git interacts with
these named hooked files at certain stages of the git process and with
certain arguments.  But the documentation (git help hooks) shows the
hooks system has grown like topsy with some rather different uses of
the same hook.  Also, I believe that documentation is seriously out of
date (i.e., missing some additional official hook names such as
"pre-merge" which google searches tell me has gone into git, but only
documented within the git code).


>From the CMake wiki they enforce their desired workflow result via the
update hook script (i.e., .git/hooks/update) on the server side (in
this case the official CMake repo hosted by Kitware). An advantage of
this technique is such enforcement cannot be gotten around by changing
.git/hooks/update on the client side.  The only way you can change it
is via ssh access to the server-side repo (in our case that normally
would be PLplot's official SF repo).  A drawback is the enforcement
only occurs on pushes substantially after the fact when the workflow
error actually occurred which makes the logic of the update hook
somewhat complicated because it needs to figure out whether the push
would change the server-side history into non-clean "shape of
history".  (I am still struggling with this logic by mentally
rearranging tinker toys corresponding to various DAGs consisting of
git commits that are infected with prior git merges to the wrong
branch).  Another drawback is that users who are not that familiar
with the workflow constraints may have trouble figuring out which
merge to the wrong branch (perhaps weeks previous) is causing the 
"non-clean shape of history" push rejection.

But there is a potential client-side complement to the push constraint
that probably avoids that last issue.  What is needed is a client side
hook for merge commits that immediately rejects any wrong moves such
as merging from master to any branch not named "next" (which
immediately stops all merging of master to topic branches), and from
next to any branch at all.  An advantage of such client-side
enforcement rules for the workflow is the logic a lot more
straightforward then in the update hook case since it consists simply
of identify the "from" and "to" branches involved in merge commits and
applying the rules considering their names.  However, a disadvantage
is users must apply these rules themselves.  In other words, if they
don't bother with installing these client-side hooks, then their bad
workflow is only caught at push time.  Nevertheless, since the logic
should be easier I am starting with the voluntary client hooks to see
exactly what is involved.

One current issue for me (see the explanation of the git hooks mess
above) is finding the right hook to use which will fire at merge
commit time for the client-side and which will have the needed
information available (especially the id of the merge commit so its
parents can be found and their associated branch names). Another
uncertainty is that the commit part of merge commits (which you are
guaranteed to get if all your merges are --no-ff) apparently does not
fire some/all of the commit hooks.  So my goal for today is to dig
through the git code to see all hooks that are actually available by
name (e.g., the und

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[phil rosenberg]

Sorry, replied rather than replied to all with this - Alan please see below
 




 From: phil rosenberg 
To: Hazen Babcock  
Sent: Sunday, 17 August 2014, 13:44
Subject: Re: [Plplot-devel] Trying to understand how git workflow for CMake is 
enforced
  


Hi Alan
I'm not great with shell scripts - I use them so infrequently I never remember 
the syntax. However I have quickly tried to modify the hook 
fromhttps://gist.github.com/caniszczyk/1327469. Basically you are trying to do 
something like:

git rev-list --first-parent newrev | grep `git rev-list --first-parent 
--max-count=1 oldrev`

where newrev is the revision being pushed and oldrev is the revision being 
updated.

If this gives an empty string then then newrev is not a direct descendant of 
oldrev. This could be because the merge was done the wrong way round (which is 
the check described on the CMAKE page) or because someone has modified oldrev 
on the server before the push occurred.

The command works because git rev-list --first-parent commit lists the sha 
values for each parent of the commit choosing only the first parent, rather 
than the merged in parent in the case of a merge. Therefore if you have merged 
the wrong way the new commit will not inherit from the parent of the old 
commit. Note that the one exception is a fast forward commit, however in this 
case the result is identical no matter which way the merge was performed so it 
makes no difference.

If you intend to have a "next" branch then you could also ensure that the topic 
branch being merged in inherits from master (instead of next or bugfixes or 
whatever), by branching next, making a change to master. Finding the sha for 
this first commit which is not on next and grepping for it in the same way as 
above.

Attached is my quick hack of that script which just replaces the requirement 
for fast forward merges only, with the requirement above - I haven't tested it 
or tried to run it and it will have windows line endings but I haven't got time 
right now. The syntax might be wrong, but I'm sure you can see the intent. I'm 
sure you can have a look at it and have a play with the git rev-list command to 
see what is happening and add stuff if you like.

All the best

Phil
 
 From: Hazen Babcock 
To: Alan W. Irwin ; Hezekiah M. Carty 
 
Cc: PLplot development list  
Sent: Sunday, 17 August 2014, 3:55
Subject: Re: [Plplot-devel] Trying to understand how git workflow for CMake is 
enforced
  

On 8/16/2014 1:50 PM, Alan W. Irwin wrote:
> On 2014-08-16 06:50-0400 Hezekiah M. Carty wrote:
>
>> I agree with Hazen here - adding hooks on day one seems overkill for
>> the
 project.  [...]
>> Given that the project and developers are overall new to git I think
>> it would be premature to start stacking automated restrictions on top
>> of our use of the tool.
>
> That said, I appreciate you and Hazen are anxious to get started with
> git for PLplot after such a long wait, and I also feel similarly even
> though I am pretty much still a git newbie.  So I suggest we should
> jointly review my decision (to not allow push to the official repo
> until we get the required modification of the update hook figured out)
> sometime late next week (say roughly in 6 days from now).  That gives
> enough time to find out if Brad King is willing to share his
> implementation, and also to
 pursue a lot further the backup plan of
> modifying .git/hooks/update(.sample) appropriately ourselves.

Unfortunately all I can report so far is that I have not had much luck 
with the obvious google searches such as "git hook enforce merge only". 
So while presumably this enforcement is possible, it also seems to be rare.

As an aside, an interesting
 client-side hook to develop would be one 
that automatically runs uncrustify. I know that I'm not very good about 
doing this manually.


-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel#!/bin/sh

#
# For each ref, validate the commit.
#
# - It disallows deleting branches without a /.
# - It disallows non fast-forward on branches without a /.
# - It disallows deleting tags without a /.
# - It disallows unannotated tags to be pushed.

validate_ref()
{
# --- Arguments
oldrev=$(git rev-parse $1)
newrev=$(git rev-parse $2)
refname="$3"

allownonffpush=$( git config --bool hooks.allownonffpush )
allowdeletebranch=$( git config --bool hooks.allowdeletebranch )
allowdeletetag=$( git config --bool hooks.allowdeletetag )
allowcreatenottopicbranch=$( git config --bool 
hooks.allowcreatenottopicbranch )
# oldrev could be 0s which means cre

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

On 8/16/2014 1:50 PM, Alan W. Irwin wrote:
> On 2014-08-16 06:50-0400 Hezekiah M. Carty wrote:
>
>> I agree with Hazen here - adding hooks on day one seems overkill for
>> the project.  [...]
>> Given that the project and developers are overall new to git I think
>> it would be premature to start stacking automated restrictions on top
>> of our use of the tool.
>
> That said, I appreciate you and Hazen are anxious to get started with
> git for PLplot after such a long wait, and I also feel similarly even
> though I am pretty much still a git newbie.  So I suggest we should
> jointly review my decision (to not allow push to the official repo
> until we get the required modification of the update hook figured out)
> sometime late next week (say roughly in 6 days from now).  That gives
> enough time to find out if Brad King is willing to share his
> implementation, and also to pursue a lot further the backup plan of
> modifying .git/hooks/update(.sample) appropriately ourselves.

Unfortunately all I can report so far is that I have not had much luck 
with the obvious google searches such as "git hook enforce merge only". 
So while presumably this enforcement is possible, it also seems to be rare.

As an aside, an interesting client-side hook to develop would be one 
that automatically runs uncrustify. I know that I'm not very good about 
doing this manually.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

On 2014-08-16 06:50-0400 Hezekiah M. Carty wrote:

> I agree with Hazen here - adding hooks on day one seems overkill for
> the project.  [...]
> Given that the project and developers are overall new to git I think
> it would be premature to start stacking automated restrictions on top
> of our use of the tool.

Hi Hez:

I would likely be amenable to just immediately going ahead with git if
we were developing our own workflow ideas from scratch, and I hadn't
read all those cautionary tails (after Hazen brought up the subject,
by the way) concerning tangled and largely useless git logs because of
bad workflow. However, because there was group concern about that
issue, we have pretty much arrived at a consensus that we should base
our workflow on what has worked since 2010 for the CMake software
project (which has a large web-based development community with many
of them git newbies when they start and thus prone to making workflow
mistakes).  If you haven't done so already, please take a look at that
workflow  to make
sure you are willing to go along with that workflow for PLplot.

In my opinion, a killer feature of that workflow implementation is it
has workflow rules that are enforced with an update hook (much more
appealing to me than time-consuming human intervention by some inner
core of our developers) to automatically make sure nobody screws up
the desired "clean shape of history" of the integration branches.  So
leaving out that killer feature just does not make sense to me.

That said, I appreciate you and Hazen are anxious to get started with
git for PLplot after such a long wait, and I also feel similarly even
though I am pretty much still a git newbie.  So I suggest we should
jointly review my decision (to not allow push to the official repo
until we get the required modification of the update hook figured out)
sometime late next week (say roughly in 6 days from now).  That gives
enough time to find out if Brad King is willing to share his
implementation, and also to pursue a lot further the backup plan of
modifying .git/hooks/update(.sample) appropriately ourselves.

As I already stated to Hazen I am actively pursuing that backup plan
as my current top priority. He and you are certainly invited to
participate in this mini-project if you have time at the moment, but
in any case stay tuned to this thread where I will be documenting my
progress.

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
__

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hezekiah M. Carty]

On Fri, Aug 15, 2014 at 8:45 PM, Hazen Babcock  wrote:
> On 8/15/2014 2:53 PM, Alan W. Irwin wrote:
>> Hi Hazen:
>>
>> Earlier today I sent an e-mail to Brad King, the CMake git guru (with
>> CC to you to keep you fully informed) asking how they implemented the
>> enforcement hooks in their git repo to maintain the desired
>> --first-parent properties of the integration branches used in their
>> workflow.  Assuming we adopt their workflow, then I think it is
>> absolutely essential that we get these enforcement hooks in place
>> before proceeding further with PLplot development using git so I think
>> it is a good idea to make our SF git repo read-only until this
>> implementation issue for our workflow is resolved.  I plan to do that
>> later today if you don't have any strong objections.
>
> I object, but not strongly. What is the worst thing that can happen? We
> have to delete the repo and start over? Hooks or no hooks, mistakes are
> going to be made and will have to be dealt with, might as well start
> learning how to do that now.
>
> In Arjen's case he would do the following:
>
> git checkout master
> git pull
> git checkout -b fix_replot_08_15_2014
> ..
> edit files
> ..
> git add -- files
> git commit -m "Fixed width issue in replot."
>
> ..
> check that the fix works
> ..
>
> git checkout next
> git pull
> git merge fix_replot_08_15_2014
> git push sf-repo next
>
> The only sticking point would be that we don't yet have a next (or a
> release) branch in our repo..
>

I agree with Hazen here - adding hooks on day one seems overkill for
the project.  Further, if we do go the github route then using
Github's pull request structure provides a means of enforcement and
verification of whatever pre-merge checks we want to enforce.

With the github fork + pull request approach a developer (any
developer - core or external) would create a personal 'fork' of the
main repository.  A fork in this case is simply a github-generated and
hosted clone of the official PLplot repository.  The developer would
clone their forked repository to their local machine, make and commit
their changes and push the changes back to their fork on github.  Once
the developer is happy with their changes they can submit a pull
request for their changes back to the main repository.  It would then
be up to one or more core developers (people with write access to the
official repository) to review and accept the pull request.  Once the
pull request is acceppted and merged the result is a nice, clear
history showing when changes were made and when they were merged.

Given that the project and developers are overall new to git I think
it would be premature to start stacking automated restrictions on top
of our use of the tool.

Hez

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Alan W. Irwin]

On 2014-08-15 20:45-0400 Hazen Babcock wrote:

> On 8/15/2014 2:53 PM, Alan W. Irwin wrote:
>> Hi Hazen:
>> 
>> Earlier today I sent an e-mail to Brad King, the CMake git guru (with
>> CC to you to keep you fully informed) asking how they implemented the
>> enforcement hooks in their git repo to maintain the desired
>> --first-parent properties of the integration branches used in their
>> workflow.  Assuming we adopt their workflow, then I think it is
>> absolutely essential that we get these enforcement hooks in place
>> before proceeding further with PLplot development using git so I think
>> it is a good idea to make our SF git repo read-only until this
>> implementation issue for our workflow is resolved.  I plan to do that
>> later today if you don't have any strong objections.
>
> I object, but not strongly. What is the worst thing that can happen? We have 
> to delete the repo and start over? Hooks or no hooks, mistakes are going to 
> be made and will have to be dealt with, might as well start learning how to 
> do that now.

Hi Hazen:

Thanks for your response.  I do feel strongly about the necessity of
the hooks principally because the CMake software project finds them to
be essential for automatically maintaining the "clean shape of
history" they find to be so useful.  Also, I think it is important to
start with git the way we mean to go on. Therefore, because you do not
have a strong objection, I have just now made the SF git repo for PLplot
read-only until we can get the hooks implemented which will be my
first priority from now on.

Hopefully, this git hold up will all get resolved early next week if Brad
King is cooperative about sharing his hooks implementation.  But if
not, I plan to fall back to learning enough about git hooks to
implement this myself, and I would welcome your help or advice with this effort
as well if you have the time right now to participate.

By the way, you likely know this already, but for the others here
hooks can simply be shell scripts (see the part of the Pro Git book
that discusses git hooks) that exit with appropriate error message and
non-zero return code if certain logical conditions are not met.  Also,
there is a tonne of reference material on git hooks and git hook
examples at http://githooks.com/ which I will be looking at.

I feel comfortable writing shell scripts, so for me, the sticking
points for an implemention of the hook (or hooks) we need are (1)
knowing what logical conditions must be met to maintain the "clean
shape of history" (i.e., "--first-parent traversal of an integration
branch, such as master, should see only the merge commits that
integrate topics into the branch"), and (2) figuring out the git
commands to test those logical conditions.  I think (2) will be pretty
straightforward (since I used git commands a lot in my script to test
our git repo versus our svn repo).  With regard to (1) there is a
logical rule mentioned in the 
 discussion of how
the hook rejects a bad workflow example which is probably what is
required here.  The current status is I don't completely understand
that example and its discussion, but I am working on it.

More later as this git hooks project progresses (or Brad King shortens
it by sharing his own implementation).

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
__

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

On 8/15/2014 2:53 PM, Alan W. Irwin wrote:
> Hi Hazen:
>
> Earlier today I sent an e-mail to Brad King, the CMake git guru (with
> CC to you to keep you fully informed) asking how they implemented the
> enforcement hooks in their git repo to maintain the desired
> --first-parent properties of the integration branches used in their
> workflow.  Assuming we adopt their workflow, then I think it is
> absolutely essential that we get these enforcement hooks in place
> before proceeding further with PLplot development using git so I think
> it is a good idea to make our SF git repo read-only until this
> implementation issue for our workflow is resolved.  I plan to do that
> later today if you don't have any strong objections.

I object, but not strongly. What is the worst thing that can happen? We 
have to delete the repo and start over? Hooks or no hooks, mistakes are 
going to be made and will have to be dealt with, might as well start 
learning how to do that now.

In Arjen's case he would do the following:

git checkout master
git pull
git checkout -b fix_replot_08_15_2014
..
edit files
..
git add -- files
git commit -m "Fixed width issue in replot."

..
check that the fix works
..

git checkout next
git pull
git merge fix_replot_08_15_2014
git push sf-repo next

The only sticking point would be that we don't yet have a next (or a 
release) branch in our repo..

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel