Re: merging msvc in branch-1.11

[Peter Rosin]

Stefano Lattarini skrev 2011-11-10 12:30:
> On Thursday 10 November 2011, Peter Rosin wrote:
>> Stefano Lattarini skrev 2011-11-10 11:02:
>>> In the meantime, removing some already-merged and now inactive branches
>>> (e.g., `prove' and `remove-deansification') might simplify the situation
>>> a bit.  Will do shortly.
>>
>> This is not at all my concern.
>>
> OK.  But I think removing those branches is a good move regardless (they
> have always be thought as temporary topic branches, so no need to keep
> them around now that they've been happily merged).

Sure.

>>>> Is it
>>>> really desired to merge back maint and master into the work branches
>>>> with such extreme frenzy?
>>>>
>>> I'd say yes, to avoid potential future bigger conflicts when merging.
>>>
>>> Such conflicts are bound to be more difficult to resolve, firstly
>>> because they will be bigger, and secondly (and most importantly)
>>> because the will involve much more changes done in a wider temporal
>>> interval -- changes whose details or exact reason we might even have
>>> forgotten in the meantime!
>>
>> Just have a look at the attached picture (if the ml doesn't eat it) and
>> try to convince me that you like what you see.
>>
> I don't; that's why I only visulize a set of *related* branches at once,
> not all of them at the same time (for example, visualizing `master' and
> `maint' and `testsuite-work' at the same time is not confusing (since
> `maint' is merged into `master', which is merged into `testsuite-work').
> OTOH, there is no clear relationship between `maint' and `branch-1.11'
> (except for the fact that they share maint as a common "baseline"), so
> trying to visulize them at once is bound to end in a mess; and notice
> that this happened also *before* I started to introduce my umpteenth
> topic branches.

That doesn't help if you visualize some branch that contains all those
merges.

I had troubles following where a change was made, and was fooled by
several merges before locating the correct commit. And sorry for blaming
"your" work branches for the state of branch-1.11 which is where the big
merge frenzy occurs.

>> That nest will not go away by removing branches.
>>
> While I don't consider the current situation as a problem, I agree it is
> suboptimal in some aspects; so, if you have suggestions about how it
> could be improved, I'm all ears :-)

I'm just not happy with how the commit graph looks (at least as shown by
gitk). I don't really know what to do about it, and I realize that the
topic branches are not the sole culprits, sorry for pointing the finger
at you...

Some ideas though:

Don't have work type branches in the main repo. It's certainly possible
to set up a repo for each topic instead of a new branch. Then you
can throw away "bad" work much easier, and you are freer to rebase
the work if it turns out it takes a long time to complete and/or has a
lot of undesired merge-backs. Rebasing can be done for work branches
in the main repo as well, but IMO it doesn't feel as bad to rebase in a
separate work repo.

Don't merge maint into branch-1.11/master four times a week unless
there are *really* good reasons, each time. Try a throwaway merge and
check for conflicts. If there are none, it is certainly possible to
leave the merging for later. Or, release from master more often, then
the maint-maze problem will be a non-problem :-)

Cheers,
Peter