[dune-pdelab] Workflow

[Jö Fahlke]

Am Thu, 25. Jun 2015, 15:20:11 +0200 schrieb Steffen Müthing:
> after discussing this with Dominic, I think this resulted from a little mixup because he
> accidentally did his changes on his local master branch and directly pushed that master
> branch to a remote feature branch, causing some confusion when trying to resolve the
> manual merge.
> 
> That said, I think that merging master into a feature branch should be a *last resort* measure;
> normally, you want to do the exact opposite, i.e. merge feature branches *into* master.

I don't quiet understand what would be so bad about this.  It's not like we
have a master and a release branch and you'd accidentially merge master into
release that way.  And if we had, we'd need to be extra careful anyway,
e.g. when choosing the base of our feature branches.  But anyway, let's go
with it for now.

> AFAIU, the default workflow should be:
> 
> 1) See whether the automatic merge using the button works. If it does, use it.
> 2) If it does NOT work, do the following:
> 
> - Push the latest version of your feature branch to GitLab
> - Switch to master - git checkout master
> - Update master to the most recent version - git pull
> - Merge the feature request without fast forward (that can’t happen anyway in this case;
>   otherwise the automatic merge in GitLab would work) - git merge —no-ff feature/my-branch
> - IMPORTANT: Make sure to include the line "See merge request !<mr-number>“ into your commit
>   message, as well as something like „Fixes #<bug-number>“ if this merge request resolves a bug
> - EVEN MORE IMPORTANT: Make sure that your merge hasn’t broken anything by running
>   "make build-tests“ as you might have broken something when resolving merge conflicts

I didn't know about this target.  It is probably a good idea, and I'll give it
a try, but I doubt I can rely on it all that much.  In pdelab many files are
probably not checked by this, since we don't really have comprehensive unit
tests, and I usually have to go find an example in pdelab-howto instead to do
my testing.  And pdelab-howto does not compile as a whole for me, so
build-test would probably fail even before any my changes I made.

> - Push your master branch with the merge to GitLab - git push

Can everyone push to the master currently?  This would not work for anybody
who can't.  AFAIK they can do merge requests, and they would be able to merge
a newer master into their branch, thus resolving merge conflicts.  But the way
you describe it the manual merge has to be done by the one accepting the
merge.  The one requesting the merge can do little to help with that, even
though he is probably better prepared to do this, since he at least knows the
ins and outs of one side of the merge.

> - If the verification step took too long and there are new commits on master that keep you from pushing,
>   *do not rebase or pull* unless you know exactly what you’re doing (git rebase -p anyone?). Just rewind
>   your master (git reset —hard HEAD~), then update (git pull) and then redo the merge. You can enable
>   rerere (git config —global rerere.enabled true) so that git remembers your manual conflict resolutions and
>   you don’t have to do them a second time.

Regards,
Jö.

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Das Erststudium soll bis zum berufsqualifizierenden Abschluss
gebührenfrei bleiben, also bis zur Erlangung der Taxi-Lizenz.
-- Akrützel, Ausgabe vom 16.5.2002 (www.akruetzel.de)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150625/e445c2b3/attachment.sig>