Below is a sketch of hooks and rewind script.
Note this will warn quite late (on merge) if one branches from next.
Jan
rewind-next.sh
=============================================================
#!/bin/sh
set -e
: ${ORIGIN:="origin"}
git fetch $ORIGIN
git checkout next
git reset --hard $ORIGIN/master
cat << EOF | git commit --allow-empty -F-
Hic sunt leones
EOF
echo "Think once more and then type"
echo " git push -f $ORIGIN next"
=============================================================
.git/hooks/post-merge
=============================================================
#!/bin/sh
# Allow anything on next branch
#TODO: Is this check robust
if [ "$(git rev-parse --abbrev-ref HEAD)" = "next" ]
then
return 0
fi
#TODO: Add check that user is not commiting with message "Hic sunt leones"
# (unless on next)
# Check that not merging next by checking for predefined sentinel commit
NEXT_SENTINEL_COMMIT=$(git rev-list --grep="Hic sunt leones" next)
echo $NEXT_SENTINEL_COMMIT
if git merge-base --is-ancestor $NEXT_SENTINEL_COMMIT HEAD
then
echo "What are you doing?!"
echo "You've just merged 'next' into $(git rev-parse --abbrev-ref HEAD)!"
echo "Resetting softly to $(git rev-parse HEAD@{1})..."
git reset --soft HEAD@{1}
fi
=============================================================
On Tue, 23 Jun 2015 14:03:09 +0200
Martin Sandve Alnæs <[email protected]> wrote:
> Can we have a hook that rejects pushing a branch containing the 'next
> sentinel commit' to fenics-project/*/master? That would keep the
> problem contained if it occurs, and the responsible will have to
> clean it up locally before publishing.
>
> I don't think it matters much how many tools and instructions we
> make, the problem is that people make mistakes or ignore advice. If
> pushing content from next to fenics-project/master is possible it
> will happen somehow.
>
> The solution to check if you've included next in your topic branch is
> simple btw. I almost always do this:
> git log master..martinal/topic-foobar
> This shows exactly which commits you're about to merge.
>
> Martin
>
> On 23 June 2015 at 13:47, Jan Blechta <[email protected]>
> wrote:
>
> > On Tue, 23 Jun 2015 09:50:18 +0200
> > Martin Sandve Alnæs <[email protected]> wrote:
> >
> > > The problem is rather large:
> > >
> > > git log | grep 'into next' | wc
> > > 641 3243 35210
> > >
> > > And from the gitk visual commit graph it looks pretty hard to
> > > clean up.
> > >
> > > It's also not the first time, 1.5 contains at least one explicit
> > > merge of next into a user branch:
> > >
> > > 2014-11-21 09:38:36
> > > Merge https://bitbucket.org/fenics-project/dolfin/branch/next
> > > into tianyi/nls-tao-nonlinear
> > >
> > >
> > > Points we need to address:
> > >
> > > 1) We need to identify and revert unwanted changes.
> > >
> > > 1a) We'll have to accept the ugly old history and the existence of
> > > 'into next' commits in master. A history rewrite is a lot of work
> > > and will invalidate _all_ branches out there. However the master
> > > source code should be corrected if necessary before the release.
> > >
> > > 1b) Commits that were reverted in next before next became part of
> > > master should already be reverted in master. If we're lucky
> > > there's nothing we have to fix. Can everyone think very hard on
> > > changes they commited to next and later reverted, and check if
> > > those changes are not part of the source code in master? Maybe
> > > someone can look over 'git log | grep revert' and check?
> > >
> > > 2) We need to avoid this in the future.
> > >
> > > 2a) Is there a way to enforce a check? I.e. a hook that does not
> > > accept merging anything into master that contains a merge commit
> > > with the word 'next'? It needs to cover both errors of checking
> > > out from next and merging next into another branch.
> >
> > Pre-receive hooks are not supported by bitbucket yet
> > https://bitbucket.org/site/master/issue/5658
> >
> > If we develop algorithmic way of checking it, we can make it
> > responsibility of guys with write access to master. Each developer
> > could install it as a post-commit hook locally or run it manually.
> >
> > My first idea for the algorithm was:
> >
> > 1. after rewinding next, make a dummy commit 'xxxx' to next
> > 2. the actual check would be that master does not contain commit
> > 'xxxx'
> >
> > After every rewind of next, 'xxxx' will have different sha but it
> > can have defined commit message (or some other property) so that it
> > can be algorithmically found. Moreover, there can be a post-rewrite
> > hook installed (locally by each dev) which ensures that this dummy
> > commit is done after every rewind.
> >
> >
> > Checking out from next could be prevented by post-checkout hook.
> >
> >
> > All those hooks could be committed to the repo but they would
> > explicitly need to be enabled (e.g. by symlinking) by local user.
> >
> >
> > Let me remind that git-prompt (and git-tab-completion) is almost
> > necessary tool
> >
> > https://bitbucket.org/fenics-project/dolfin/wiki/developer-instructions-git#markdown-header-prompt
> >
> > >
> > > 2b) We should update the git instructions to 'git checkout master
> > > -b username/topic-featurename' and 'git merge --no-ff' as Jan
> > > suggested, and write clearly that merge of next into anything or
> > > checkout from next is under no circumstances allowed.
> >
> > It is clearly written in the wiki:
> >
> > Do not start from next!
> >
> > Never merge next into your branch.
> >
> > It is never merged into another branch and new development never
> > starts on next.
> >
> > Jan
> >
> > >
> > > Ultimately this depends on having everyone with write access on
> > > board to take the time to do this correctly, both as users and
> > > when merging user pull requests.
> > >
> > > Martin
> > >
> > >
> > > On 19 June 2015 at 23:14, Anders Logg <[email protected]>
> > > wrote:
> > >
> > > > So the problem was I created my topic branch from next. This
> > > > seems like a probable mistake (having just merged another
> > > > branch into next for testing). I know new branches should be
> > > > based on master, so if I understand correctly our workflow is
> > > > correct but failed this time because of a human error?
> > > >
> > > > --
> > > > Anders
> > > >
> > > >
> > > > fre 19 juni 2015 kl 22:06 skrev Martin Sandve Alnæs
> > > > <[email protected]>:
> > > >
> > > >> Ok Jan, then we're in agreement.
> > > >>
> > > >> I think the "merge master into master" message occurs when
> > > >> someone has their own fork and merges the official master in
> > > >> the web interface.
> > > >>
> > > >> We should ask that people don't do that. I.e don't merge
> > > >> anything into your topic branch unless it's for a good reason.
> > > >>
> > > >> Martin
> > > >> 19. jun. 2015 21.32 skrev "Jan Blechta"
> > > >> <[email protected]>:
> > > >>
> > > >>> On Fri, 19 Jun 2015 18:30:26 +0100
> > > >>> "Garth N. Wells" <[email protected]> wrote:
> > > >>>
> > > >>> > On 19 June 2015 at 17:21, Jan Blechta
> > > >>> > <[email protected]> wrote:
> > > >>> > > Next has been (at least once) accidentally merged into
> > > >>> > > master.
> > > >>> > >
> > > >>> > > $ git branch --contains 832946b
> > > >>> > > * master
> > > >>> > > morandini/add-matrix-get-diagonal
> > > >>> > > next
> > > >>> > > $ git show --oneline 832946b
> > > >>> > > 832946b Merge branch 'logg/fix-issue-328' into next
> > > >>> > >
> > > >>> > > I think that master should be carefully examined that it
> > > >>> > > does not contain any throw-away changes. Any opinions
> > > >>> > > here?
> > > >>> > >
> > > >>> > > Next time, please, avoid this. More generally, we should
> > > >>> > > reduce using merge as a tool for resolution of every
> > > >>> > > problem
> > > >>> > > - merging from everything to everything. I think it
> > > >>> > > happens too often and history is unreadable many times.
> > > >>> > >
> > > >>> >
> > > >>> > Maybe you could write-up some guideline/instruction notes to
> > > >>> > help us use rebase to keep the history cleaner?
> > > >>>
> > > >>> I don't want to encourage more rebasing but less
> > > >>> (non-fast-forward) merging. Everybody should read and follow
> > > >>>
> > > >>>
> > https://bitbucket.org/fenics-project/dolfin/wiki/developer-instructions-git
> > > >>>
> > > >>> On the other hand, integration of topic branches (into master)
> > > >>> shouldn't typically be fast-forward:
> > > >>> (master) $ git merge --no-ff author/topic
> > > >>>
> > > >>> Jan
> > > >>>
> > > >>> >
> > > >>> > Garth
> > > >>> >
> > > >>> > > Jan
> > > >>> > > _______________________________________________
> > > >>> > > fenics mailing list
> > > >>> > > [email protected]
> > > >>> > > http://fenicsproject.org/mailman/listinfo/fenics
> > > >>> > _______________________________________________
> > > >>> > fenics mailing list
> > > >>> > [email protected]
> > > >>> > http://fenicsproject.org/mailman/listinfo/fenics
> > > >>>
> > > >>> _______________________________________________
> > > >>> fenics mailing list
> > > >>> [email protected]
> > > >>> http://fenicsproject.org/mailman/listinfo/fenics
> > > >>>
> > > >>
> >
> >
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
