yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Bruno Chareyre said:     (by the date of Tue, 8 Jan 2019 17:50:02 +0100)

> On Tue, 8 Jan 2019 at 09:56, Jerome Duriez <jerome.duriez@xxxxxxxxx> wrote:
> 
> > let's maybe try to avoid switching from only one branch to more than
> > three ?...
> >  
> 
> We have already 19 branches on github/yade/trunk, plus other branches under
> personal accounts.
> Limiting the number of branches is not a realistic objective, don't worry
> about that. It will become more clear with concrete usage, and you will not
> have to handle them all anyway.
> This being said, I'm also not sure we really need that develop-master
> duality.

in fact since all works happens in personal repos I could use this
model (which I like) myself like I used it before. And afterwards do a MR ;)
 
> Very liberal config for exp, and conservative for dev (even very
> conservative initially, we will see if it is too conservative).
> exp will *not* merge to develop, it will diverge progressively, most
> likely, but it is not an issue. It can be re-synced. No commits can be lost
> since by definition a MR to exp is from somewhere.

To re-sync the method of doing control merges can help a lot:
https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

It works in such a way, that when you feel like it, you try to merge
exp with dev branch. See the conflicts and resolve them. Then delete
this merge so that it is not polluting your history.

When the time comes to do the real merge git will remember all your
resolved conflicts that you periodically were doing, and will apply
them.

This is awesome, because you solve conflict once, and never go back
to it. The best part is that even when the conflict occurs again in
some other branch, git still remembers how you solved it.

I have just recently found that method and still need to employ it in
my workflow. But it is very promising.

 
> Anton, do you have comments on MR on Gitlab interface? Do you confirm that
> they are a must? Did you ever hack the API to trigger them from CLI (that
> would mae Janek happy ;) )?

oh, I never insisted that everything must be done from CLI :-)
I am not afraid of learning some www-clicking ;) I was simply
unfamiliar with this.


Janek