Hi! On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > I'm not arguing that you should go that route, it seems a bit extreme to > me. But outright refusing merges on the basis they are painful is (if > you can accept the strong word) ludicrous.
They are painful for everyone working with the history later. Something that we do in GCC more often than in most other projects. > >Merging is appropriate if there is parallel development of (mostly) > >independent things. > > Which is almost always the case. Which is almost *never* the case for GCC, in my opinion. Almost all commits are smallish improvements / bugfixes. And most bigger things are not independent enough -- we require the resulting thing to be (regression) tested before pushing it upstream, and that is because often that *does* find problems! > >Features aren't that, usually: they can be rebased easily, and they should > >be posted > >for review anyway. > How often successive features checked into GCC are dependent on each > other ? Almost always, one way or the other. It's not just the GCC code itself you have to consider here, there things are easily independent enough, but looking at the code generated by GCC often shows unexpected interactions. > The fact that they can be rebased either way and easily is > almost a testimony of that. And the fact that they need review has > nothing to do with anything. Every patch should normally be posted to the mailing lists for review. Such patches should be against trunk. And *that* patch will be approved, so *that* is the one you will commit and push upstream eventually. Those are the procedures we currently have, and it is necessary to keep the tree even somewhat working most of the time. Too often the tree is broken for days on end :-( > >It is very easy to use merges more often than is useful, and it hurts. > > And it is very easy to use SVN-like workflows, and it hurts far more. > SVN, due to its centrality and inherent impossibility to encode logical > relationships between changes (as opposed to time-based evolution), > slowly impaired most developers mind openness about what can be done in > a worthwhile VCS. Moving to git is an opportunity to at last free > yourselves, not continue that narrow treading on SVN paths. We cannot waste a year on a social experiment. We can slowly and carefully adopt new procedures, certainly. But anything drastic isn't advisable imo. Also, many GCC developers aren't familiar with Git at all. It takes time to learn it, and to learn new ways of working. Small steps are needed. > SVN was like an almanac listing successive events without any analysis. > That's not History (as in the field of study). Git at least can let you > express and use to your common benefit logical links between > modifications. Don't miss that train. I think you seriously overestimate how much information content is in a merge (esp. as applied to the GCC context). Let's start with using good commit messages (or actual commit messages *at all*), that has a much better pain/gain ratio. > Merges are not scary when the tools are good. Even the logs are totally > usable with a lot of merges, with suitable tools. The tool has to adapt, > not you. Merges aren't scary. Merges are inconvenient. And yes, there is no way that all of us will change on a non-geological time scale. Segher
