On Tue, 23 Jun 2015 11:50:55 +0000 Anders Logg <[email protected]> wrote:
> 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> I don't like this. It needs to be transparent (as git hooks are) otherwise nobody would use it. It can be successful only if we stick to a contract of using 'fenics-branch' instead of 'git-branch', 'git-checkout' or anything else ever. Jan > > -- > 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
