[Development] Please warn of force pushes...

[Oswald Buddenhagen]

On Tue, Apr 23, 2013 at 08:16:24AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de abril de 2013 11.18.33, Oswald Buddenhagen wrote:
> > On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote:
> > > These people need to be warned that the branch rebases.
> > 
> > why would they? they can adapt once it happens. i mean, it's a bit of a
> > surprise, but it doesn't change much in the end.
> 
> Because the surprise is quite big. If you do a git pull --rebase or git pull, 
> it might blow up after dozens lines have scrolled out. People don't pay 
> attention to the output of the fetch part.
> 
i don't see that as a problem. if it blows one can easily roll back
with rebase --abort. in the worse case one needs to manually rebase out
some leftovers.

> Though I have to grant that novice users are unlikely to be following those 
> branches in the first place. But then, we're left with somewhat knowledgeable 
> users following the branches, so they are more likely to have extra commits 
> and then have no clue on how to rebase their work on top of the rebased base.
> 
> 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

> > > > > Ok, then add "rebasing" to the branch name somewhere. Preferably:
> > > > > 	wip/rebasing/xxx
> > > > 
> > > > sounds over-engineered to me.
> > > > and unnecessarily restrictive, as the policy may change ad-hoc as things
> > > > progress.
> > > 
> > > 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.

> > > In any case, why does this branch rebase? Can't they live with
> > > merges?
> > 
> > well, the wip/ branches often have rather lax review policies (often
> > bypassing domain experts in the case of platform ports) and no CI.
> 
> If they're bypassing the reviewers and bypassing the CI, why do they
> need to be in the main Git repositories in Gerrit in the first place?
> 
they are not bypassing review alltogether, they are just "taking
shortcuts".

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