Basically, a rule-of-thumb would be "once a week is reasonable", but on
the other hand, if you have actual conflicts, more often is fine, and if
you know your area isn't impacted (eg most filesystems), you'd probably
only try to synchronize at release points or something like that.
The reason to avoid doing overly many merges is
- merging with me at random points is usually not a good idea anyway,
unless you have a really strong reason for it. Yes, my tree is fairly
stable, but still..
(This also implies that merging with my *tags* is usually a better idea
than merging with some random point in time, and is one reason it makes
sense to try to merge with major releases rather than anything else)
- the history just looks cleaner and is easier to follow when there
aren't criss-crossing merges.
This may not matter most of the time, but it *does* make a difference
when doing "git bisect". I don't know about others, but I often do "git
bisect visualize" then I have some totally unknown bug and I'm trying
to guess what's going on - it's a great way to give people a heads up
saying "ok, I'm in the middle of a bisection run, and it _looks_ like
it may be due to you".
So trying to have fairly clean history is worth it (it also makes it
slightly faster to bisect when you don't have lots of criss-cross merges,
but that's a fairly small factor).
Yes. I think you guys already have a test branch for the "join it all
together" case, don't you?
Linus
--
