One option would be to add some scripts / commands to fenics-developer-tools (containing now fenics-install.sh, fenics-install-all.sh and fenics-install-component.sh). We could add:
fenics-branch <foo> fenics-merge-next <foo> fenics-merge-master <foo> -- Anders tis 23 juni 2015 kl 13:48 skrev Jan Blechta <[email protected]>: > 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 >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
