[Development] Please warn of force pushes...

[Thiago Macieira]

On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
> > I, for one, will not touch any of the rebasing branches, not even to test
> > them. It's too much work to rebase on top of a moving base.
> 
> i call that making a mountain out of a molehill.
> $ git fetch
> $ git rebase --onto @{u} HEAD~4

Would you call me experienced with Git?

Well, I have never successfully used git rebase --onto without reading the man 
page first and paying attention to the ASCII Art graphs.

Besides, that's unwieldy. I don't carry a handful of commits in my branches. I 
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.

> > > > Change the branch name when the policy changes.
> > > 
> > > i really wouldn't want to do that.
> > 
> > But you're not offering a better solution either. You're just dismissing
> > the
> > problem completely:
> indeed, my solution is dismissing this NON-problem.

Thank you for your opinion. Since I'm entitled to mine, we have an impasse.

> > Especially if they're bypassing the CI, they could and should just use
> > a repository elsewhere. When the branch is ready, it will be submitted
> > as individual patches to be reviewed by the regular reviewers, maybe
> > starting the work branch.
> 
> it's unreasonable to ban everything that does not comply with the
> standard workflow for mainline branches.

Yes, it is. Why do they need to use the mainline repositories if they are not 
going to adhere to the policies that are in place?

No, really, why do those branches need to be in the main repositories?

I'll give one answer, out of past discussion, and just to prove that yes I am 
trying to understand both sides:

it is nice to be there because other people sometimes see the commits coming 
in and will comment on them.


With that in mind, I change my proposal and I will say that rebasing branches 
are acceptable in the mainline repositories, provided they are clearly marked. 
It's minimal impact and it solves the problem of surprise by selecting the 
people who may use that branch.

> and if you did, you'd need to ban playground repos as well (where
> typically non-approvers can approve changes).

By definition, a playground repository is not a mainline repository.

We no longer mark the repository by giving it a different path, so they now can 
be confused and someone might think that they are official and mainline. But to 
be honest, granting extra privileges to some people is less of a problem than 
rebasing.

Besides, the fact that we made it worse in one aspect is not a justification 
for accepting it elsewhere too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130423/8f8fe2f1/attachment.sig>