Hi! On Tue, Jun 16, 2020 at 11:11:01AM +0200, Martin Jambor wrote: > On Mon, Jun 15 2020, Segher Boessenkool wrote: > > What. > > > > Of course it is not a fast-forward. I rebase the branches I publish, > > what is the point of publishing them otherwise? This is so that people > > can see the stuff that will make its way into master *later*. > > > > The number of new commits is nonsense (it is just 13), and the number of > > emails that triggers should be 0. > > > > Please fix? Or, what else is wrong? > > while I tend to agree that sending emails about commits to user branches > is not a good idea, I also believe that you should (almost?) never > rebase a public branch.
It is *my* branch. Containing *my* work. So I rebase it whenever I need to refactor it, or simply when the base changed (there *are* commits to trunk after all ;-) ). The reason to make this work "public" is so that other people can follow it. It *has to* rebase in any case, if you want it to converge on what will eventually be submitted, instead of diverging wildly from that. Since merges aren't allowed at all on trunk (and that is a very good thing), all work destined for trunk *has to* rebase. So, the *common* case for user branches is that they rebase (and some others will just not change at all ever, until they are deleted). > Certainly not if you expect anyone else to > fetch it or - god forbid - base some of their commits on it, as opposed > to just reading it through the web interface. I'd suggest appending a > date to the namer of the branch and thus always publish a new branch, > making it clear that its history is different. This is easy to deal with for those users, too. They just have to know the branch rebases. Segher
