[Dune-devel] Accidential merge
Jö Fahlke
jorrit at jorrit.de
Thu Mar 10 01:27:08 CET 2016
Am Wed, 9. Mar 2016, 19:37:05 +0100 schrieb Markus Blatt:
> On Wed, Mar 09, 2016 at 06:40:09PM +0100, Jö Fahlke wrote:
>
> > Does anyone has any good idea how to clean this up? I'm trying to collect
> > ideas in https://gitlab.dune-project.org/core/dune-common/issues/26, but so
> > far I haven't come up with any good one. Which means I'm do nothing about the
> > merge unless it creates any problems or unless someone suggests a better
> > solution.
>
> If master is still working, just leave it as it is. If not, fix it.
>
> We should never ever reset the master, period.
> The only viable way would be to revert the individual commits.
>
> Out of curiosity: How did you accidentally merge it? Was it part of
> another branch, that you merged?
Exactly. I had a small documentation fix on top of some other documentation
improvements in my working branch 'patches', which also included the 'Vc'
branch. I wanted to push the small documentation fix to master so I created a
feature branch for it and did an interactive rebase to remove the the commits
from my working branch which were not supposed to go into the topic branch.
And this is were it went wrong. I think I forgot that I had the 'Vc' branch
in 'patches', and chose the last merge commit as the base for the rebase. I
thought that was the last commit on master (since the tip of master is
typically a merge nowadays), but it must have been the merge of master and Vc
to form my working branch 'patches'. I also did not get suspicious that there
were only very few commits to kill in the interactive rebase since I had
forgotten about the Vc branch, so I saw exactly what I expected.
The next opportunity to notice the mistake would have been in gitlab in the
merge screen. But it was supposed to be only a small documentation update, so
I did not recheck the patch there. It did not help that I had committed a few
fixes that I had lying around in the last few days and was getting into the
swing of things.
I /think/ I would have cought this at the last moment in my normal
(i.e. non-gitlab) workflow: usually I merge the feature into master locally,
then I look at the history of the new master before pusing it. And by
"looking at the history" I mean looking at the full graph in gitg or magit,
which makes it easy (for me) to spot such problems.
So what do I learn from this? I guess that in the future I'll stick to my
familiar workflow, at least for small patches that I think will be
uncontroversial. We can still push directly to master, right? And a merge
request won't do much good anyway if I intent to immediately merge it.
For things that may be controversial or that require discussion for other
reasons I will continue to open merge requests, of course.
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
A mathematician is a device to turn coffee into theorems.
-- Paul Erdős
-------------- 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-devel/attachments/20160310/a4f282ae/attachment.sig>
More information about the Dune-devel
mailing list