automake-patches
[Top][All Lists]
Advanced

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

Re: merging msvc in branch-1.11


From: Stefano Lattarini
Subject: Re: merging msvc in branch-1.11
Date: Thu, 10 Nov 2011 14:54:28 +0100
User-agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )

On Thursday 10 November 2011, Peter Rosin wrote:
> 
> 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.
>
The problem with this approach (as well as with the similar one of
keeping a "separate hierarchy" of "rebasable" topic branches, say
`experimental/name-of-topic') is that, for long-lived branches (think
e.g., of `testsuite-work', or of the former `test-protocols'), continuous
rebasing became unwieldy and unacceptably maintainance-intensive, while
one-time rebasing (say, just before before merging) is too brittle, and
will leave a vision of the project history that might be a huge big lie
(unless you re-review and re-test each single commit).

> Don't merge maint into branch-1.11/master four times a week unless
> there are *really* good reasons, each time.
>
I think following this suggestion is unfeasible, since ideally *each*
commit in `maint' should have a good reason to be merged into `master'
ASAP.  That's because, ideally, commits that go into `maint' should be
only bug-fixes or, at most, minor feature additions (and intended to
remain in place in future automake versions as well); so you want
them into `master' as well, and as soon as possible, unless you resign
to have either spurious failures in the testsuite (in case the commits
from `maint' have fixed testsuite bugs) or testsuite runs that are
less faithful to the reality of the project status (in case the
commits from `maint' have fixed real bug(s) that weren't exposed by
the pre-existing testsuite coverage).

> Try a throwaway merge and check for conflicts. If there are none,
> it is certainly possible to leave the merging for later.
>
OTOH, this could be feasible and useful for branches other than master
(looking at the history, I now wish I hadn't been so agressive in
merging `maint' back into `java-work' and `python-work').  Probably,
having a script that can automatize this check would help in making
it more accepted and widespread.  Any taker? ;-)

> Or, release from master more often, then
> the maint-maze problem will be a non-problem :-)
>
Hmm... Honestly I don't see how that would fix the current issues.

Regards,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]