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.
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.
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
