I've updated https://bitbucket.org/fenics-project/dolfin/wiki/developer-instructions-git a bit with e.g. explicit checkout from master and --no-ff for merges. I also ask that merges into topic branches are avoided without good reason and state the reason by adding --edit to the merge command. Not sure if anyone reads this in such detail though.
The section on ## Long running development does not quite work with how we're using next though, it seems to encourage including next in user branches. It should either be updated or removed. Opinions on this? Martin On 23 June 2015 at 14:03, 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
