<div dir="ltr"><div><div>I think what Steffen meant by "push your master branch to gitlab" was something like<br><br></div>git push gitlab master:feature/somefeature<br><br></div>which you can always do.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 25, 2015 at 4:19 PM, Jö Fahlke <span dir="ltr"><<a href="mailto:jorrit@jorrit.de" target="_blank">jorrit@jorrit.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am Thu, 25. Jun 2015, 15:20:11 +0200 schrieb Steffen Müthing:<br>
> after discussing this with Dominic, I think this resulted from a little mixup because he<br>
> accidentally did his changes on his local master branch and directly pushed that master<br>
> branch to a remote feature branch, causing some confusion when trying to resolve the<br>
> manual merge.<br>
><br>
> That said, I think that merging master into a feature branch should be a *last resort* measure;<br>
> normally, you want to do the exact opposite, i.e. merge feature branches *into* master.<br>
<br>
</span>I don't quiet understand what would be so bad about this.  It's not like we<br>
have a master and a release branch and you'd accidentially merge master into<br>
release that way.  And if we had, we'd need to be extra careful anyway,<br>
e.g. when choosing the base of our feature branches.  But anyway, let's go<br>
with it for now.<br>
<span class=""><br>
> AFAIU, the default workflow should be:<br>
><br>
> 1) See whether the automatic merge using the button works. If it does, use it.<br>
> 2) If it does NOT work, do the following:<br>
><br>
> - Push the latest version of your feature branch to GitLab<br>
> - Switch to master - git checkout master<br>
> - Update master to the most recent version - git pull<br>
> - Merge the feature request without fast forward (that can’t happen anyway in this case;<br>
>   otherwise the automatic merge in GitLab would work) - git merge —no-ff feature/my-branch<br>
> - IMPORTANT: Make sure to include the line "See merge request !<mr-number>“ into your commit<br>
>   message, as well as something like „Fixes #<bug-number>“ if this merge request resolves a bug<br>
> - EVEN MORE IMPORTANT: Make sure that your merge hasn’t broken anything by running<br>
>   "make build-tests“ as you might have broken something when resolving merge conflicts<br>
<br>
</span>I didn't know about this target.  It is probably a good idea, and I'll give it<br>
a try, but I doubt I can rely on it all that much.  In pdelab many files are<br>
probably not checked by this, since we don't really have comprehensive unit<br>
tests, and I usually have to go find an example in pdelab-howto instead to do<br>
my testing.  And pdelab-howto does not compile as a whole for me, so<br>
build-test would probably fail even before any my changes I made.<br>
<span class=""><br>
> - Push your master branch with the merge to GitLab - git push<br>
<br>
</span>Can everyone push to the master currently?  This would not work for anybody<br>
who can't.  AFAIK they can do merge requests, and they would be able to merge<br>
a newer master into their branch, thus resolving merge conflicts.  But the way<br>
you describe it the manual merge has to be done by the one accepting the<br>
merge.  The one requesting the merge can do little to help with that, even<br>
though he is probably better prepared to do this, since he at least knows the<br>
ins and outs of one side of the merge.<br>
<span class=""><br>
> - If the verification step took too long and there are new commits on master that keep you from pushing,<br>
>   *do not rebase or pull* unless you know exactly what you’re doing (git rebase -p anyone?). Just rewind<br>
>   your master (git reset —hard HEAD~), then update (git pull) and then redo the merge. You can enable<br>
>   rerere (git config —global rerere.enabled true) so that git remembers your manual conflict resolutions and<br>
>   you don’t have to do them a second time.<br>
<br>
</span><span class="">Regards,<br>
Jö.<br>
<br>
--<br>
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,<br>
University of Münster, Orleans-Ring 10, D-48149 Münster<br>
Tel: <a href="tel:%2B49%20251%2083%2035146" value="+492518335146">+49 251 83 35146</a> Fax: <a href="tel:%2B49%20251%2083%2032729" value="+492518332729">+49 251 83 32729</a><br>
<br>
</span>Das Erststudium soll bis zum berufsqualifizierenden Abschluss<br>
gebührenfrei bleiben, also bis zur Erlangung der Taxi-Lizenz.<br>
-- Akrützel, Ausgabe vom 16.5.2002 (<a href="http://www.akruetzel.de" rel="noreferrer" target="_blank">www.akruetzel.de</a>)<br>
<br>_______________________________________________<br>
dune-pdelab mailing list<br>
<a href="mailto:dune-pdelab@dune-project.org">dune-pdelab@dune-project.org</a><br>
<a href="http://lists.dune-project.org/mailman/listinfo/dune-pdelab" rel="noreferrer" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-pdelab</a><br>
<br></blockquote></div><br></div>