[dune-pdelab] Workflow

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Thu Jun 25 15:20:11 CEST 2015


Hi,


> Am 25.06.2015 um 14:10 schrieb Jö Fahlke <jorrit at jorrit.de>:
> 
> Am Thu, 25. Jun 2015, 08:58:25 +0000 schrieb Dominic Kempf:
>> Date: Thu, 25 Jun 2015 08:58:25 +0000
>> From: Dominic Kempf <gitlab at conan2.iwr.uni-heidelberg.de>
>> To: jorrit at jorrit.de
>> Subject: Re: dune-pdelab | [cleanup] remove leftover from mfd code (#28)
>> 
>> New comment for Merge Request 28
>> 
>> http://conan2.iwr.uni-heidelberg.de/git/pdelab/dune-pdelab/merge_requests/28#note_1156
>> 
>> 
>> Dominic Kempf
>> 
>> Oh, well I branched this from an older master. In the meantime, somebody changed a file that I wanted to fully delete. That prohibited a fast forward merge for my first merge request.
>> 
>> I solved the problem by cherry-picking my commit onto a fresh master. That resulted in an easy to resolve merge, as I was deleting the file that was having conflicts.
> 
> Hi!
> 
> I did merge that request now, but I want to take the opportunity to discuss
> the workflow a little, now that I have 24h of experience with merge requests.
> 
> One question: did you mean automatic merge instead of fast-forward merge?  As
> far as I remember, we try to avoid fast-forward merges, if the changes are
> complex (i.e. enough to warrent a merge request).  In fast forward merges
> there will be no merge commit, so no opportunity do document the merged branch
> as a whole, and not opportunity to record a reference to the merge request.
> 
> I think in this case it would have been best to merge master into you branch
> and to use the result in the merge request.  Yes, that would mean a bit of
> back-and-forth merging and the history graph would be a bit more complex, but
> at least it would tell us what actually happened.

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.

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
- Push your master branch with the merge to GitLab - git push

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

Best,
Steffen

> 
> @all: do you agree or did I misunderstand the workflow?
> 
> 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
> 
> If you receive something that says "Send this to everyone you know,"
> pretend you don't know me.
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150625/f873df57/attachment.sig>


More information about the dune-pdelab mailing list