[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Using git-flow branching model?




Sébastien Dinot <sebastien.dinot@c-s.fr> a écrit :



To avoid oversight, you can add the following lines in your ~/.gitconfig:
------------------------------------------------------------------------
[merge]
    ff = no
------------------------------------------------------------------------


I have set up this configuration parameter, however, it has a nasty side effect.

The attached image shows what just happened to me after having synched my workspace with
the master repo, in order to include Maxime latest fix.

On my own workspace (the blue line on the left), I created a local branch fixing issue 355, 3 days ago (commit 18c6856), merged it to my local develop branch (which with --no-ff created a merge commit 4ac5f8e), and pushed my local develop branch to origin (the master repo on
orekit.org).

Then I created a local branch fixing issue 356, 2 days ago (commit a177f45), merged it to my local develop branch (which with --no-ff created a merge commit 73fd58a), and pushed my local
develop branch to origin.

Then Maxime created a local branch fixing issue 354, yesterday (commit 04e4b61), merged it to his local develop branch (which with --no-ff created a merge commit a769ff7), and pushed his
local develop branch to origin.

So far, so good.

At this level, my local develop branch was still at commit 73fd58a, so I had to synched my copy to take Maxime fix into account. At this level, I would have prefered *this* merge to be a fast-forward and to directly jump to a769ff7 instead of adding yet another merge 57a789a. As this spurious commit is only on my local repo, I will remove it manually and
make sure my local develop branch head point to commit a769ff7.

To conclude, enforcing ff = no in git configuration ensures you don't miss merge commit,
but does it too well, and sometimes even when you do not want it.

I tried to use ff=only (equivalent to --ff-only), but it seems to act the same as -ff when merging an issue fixing branch back, so it is not what we want. I don't know if it is possible to enforce git to insert merge commits when the merged branches have different
names.

We will have to be carefull and either set ff=no and remove the extra merge commit manually or not configure merge automatically and take care to insert these merge
commits for the issue fixing and feature branches ourselves.

best regards,
Luc

Attachment: git-merge-history.png
Description: PNG image