Re: gcc-cvs mails for personal/vendor branches for merge commits
Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : On Wed, Jan 15, 2020 at 04:37:49PM +, Iain Sandoe wrote: I’m guessing that public development branches will probably gravitate to the no non-FF mode, if they are to be used by people other than the primary author .. although that does somewhat limit things; rebasing WIP onto trunk and reorganising / squashing is useful as well. If a branch does rebase all people who commit to it need to make sure not to overwrite others' work. Your pushes are always non-fast-forward, so you do not notice you did not incorporate someone else's new work if you do not take care. There is the git push --force-with-lease option to avoid that. Its goal is to force a non-fast-forward push, but only if the remote position (HEAD) is actually where you expect it to, that is no work you don't know about has been pushed in the mean time. I strongly recommend to use --force-with-lease on non-user branches. User branches you usually control totally and are the only one to push to, so that's less an issue. One easy way to avoid this is to just have only one person pushing to a certain branch. Segher
Re: Proposal for the transition timetable for the move to GIT
Le 29/12/2019 à 17:32, Richard Earnshaw a écrit : We agreed that for changes in our current workflow practices we'd defer that until *after* we'd switched to git; so this is getting off topic. On the other hand, we do need to sort out what we do with existing merge history, as that forms part of the conversion. Can we stick to what's relevant, please, at least in this thread? I never wanted to make the GCC project choose new rules now. What I advise (and you are more than able to choose to follow or not) is only to avoid taking decisions right now, as part of the migration, that would impair establishing better rules later, especially if those decisions come from (bad?) habits that were taken during the SVN era, due to the idiosyncrasies of SVN itself. Julien
Re: Proposal for the transition timetable for the move to GIT
Le 29/12/2019 à 14:31, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: At worst, no commit is testable in the branch except the last, and git will say that the bug was introduced in the branch, which is not worse that what you'd get without a merge commit. We normally require every commit to be tested, so it is a lot worse, yes. That's very good, and should not change. I test every commit of every merge request I submit, even on projects that use real merges. It is easy to create CI/CD configurations and/or hooks that enforce that when trying to push a patch set, with or without a merge commit. Merge commits have the great effect of separating the history into related chunks. Without them, you don't really know if a single bugfix is logically part of a set (because it fixes something important to pave the way) or not, and you have to think harder to detect the end of a set and the start of another (with maybe single commits inbetween). Segher
Re: Proposal for the transition timetable for the move to GIT
Le 29/12/2019 à 14:26, Segher Boessenkool a écrit : 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. I don't think merges make looking at history more or less painful, unless you consider projects like git where there are a inordinate amount of merges. And even then, I think they have solutions. Something that we do in GCC more often than in most other projects. I would have expected a lot if not all projects to look often in history, at least for projects with significant complexity. Which is almost *never* the case for GCC, in my opinion. Almost all commits are smallish improvements / bugfixes. Which are indepenent, clearly. 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. Indeed, the rebased series would be what is reviewed and pushed upstream. Which can be done with a merge commit anyway. I think you really should look at the workflow of the git project (and they have their share of interdependent strange things that happen too; of course less than GCC due to the complexity of the project, but the techniques to ensure you don't get bitten by that are the same). They use merges extensively, and have a very very good track record of non-broken master (or at least had last time I looked). 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. Of course ! I am not suggesting you change everything. But setting in stone hard rules that force the SVN mindset is harmful too. Merges aren't scary. Merges are inconvenient. No they are not. You are unaccustomed to them, which is different. People that only ever used DVCS feel merges are much more natural and even productivity increasing. Some even do "bad merges", like "sync from trunk" every other commit, which I very much frown against. Which brings me to something I find strange in your policy: to me, merges from trunk to branches should be rare if not nonexistent. And you are deciding to banish merges the other way around. Julien
Re: Proposal for the transition timetable for the move to GIT
Le 29/12/2019 à 12:02, Richard Biener a écrit : On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool wrote: On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we can help that. It disagrees with our documented "submitting patches" protocol. I don't see how that can be correct. Linux is heavily "submitting patches" based, with stringent reviews on LKML, yet heavily uses merges. Linux has most development done in separate trees, one for each maintainer. That is not how GCC works. I was talking about https://gcc.gnu.org/contribute.html , see heading "submitting patches" :-) Nothing should ever be flattened to a single commit. But before patches hit trunk, the patch series can be made nicer than it was at the start of its development. I quite agree with that, and it resonates with my TL;DR chunk of text above. Yup. Rebasing is superior to merging in many ways. Merging is appropriate if there is parallel development of (mostly) independent things. Features aren't that, usually: they can be rebased easily, and they should be posted for review anyway. It is very easy to use merges more often than is useful, and it hurts. For bisecting trunk a merge would be a single commit, right? Not exactly. It will if the bug was not introduced by the merge, but if so then "git bisect" will start looking at individual commits in the branch, which is IMHO very good. It is far easier to have a bug pinned to a single change (or say 5-6 commits, if all were not buildable or testable), than a whole branch. At worst, no commit is testable in the branch except the last, and git will say that the bug was introduced in the branch, which is not worse that what you'd get without a merge commit. Julien
Re: Proposal for the transition timetable for the move to GIT
Le 29/12/2019 à 11:41, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we can help that. It disagrees with our documented "submitting patches" protocol. I don't see how that can be correct. Linux is heavily "submitting patches" based, with stringent reviews on LKML, yet heavily uses merges. Linux has most development done in separate trees, one for each maintainer. That is not how GCC works. I mentioned the git development for a reason. They use merges for *everything*, including patchsets by people who never contributed before and might never contribute afterwards. The very *concept* of a DVCS is that each developer has a separate tree, not each maintainer. 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. Nothing should ever be flattened to a single commit. But before patches hit trunk, the patch series can be made nicer than it was at the start of its development. I quite agree with that, and it resonates with my TL;DR chunk of text above. Yup. Rebasing is superior to merging in many ways. That's not what I agreed with. I agreed with « the patch series can be made nicer », which I took to be the contrary of « append patches at the end ». Rebasing is *one* of the ways to do that, especially interactive rebasing to shuffle patches around, check that each step compiles and passes the full test suite (updating it if needed and correct), reword messages, and think a lot of times about the best progression. But I never opposed rebasing to merging. In particular, I clearly wrote that *even if you rebased*, there are very strong arguments out there about refusing fast-forward merges, that is *always* generate a real merge commit, with a cover letter message roughly corresponding to the mail people send on the ML to convince people their patch series are worth including in GCC. That leaves individual commit messages to explain the local rationale behind each discrete change (not the how, as it is readily apparent from the code, unless the code is very clever and then an in-code comment is warranted) Merging is appropriate if there is parallel development of (mostly) independent things. Which is almost always the case. 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 ? 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. 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. 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. 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. Julien
