[dune-pdelab] Workflow

[Dominic Kempf]

I think what Steffen meant by "push your master branch to gitlab" was
something like

git push gitlab master:feature/somefeature

which you can always do.

On Thu, Jun 25, 2015 at 4:19 PM, Jö Fahlke <jorrit at jorrit.de> wrote:

> 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)
>
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150625/561beeaf/attachment.htm>