not rebasing after PR?

[Andrew Wilkins]

On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall <casey.marshall at canonical.com
> wrote:

> On 06/05/2014 10:22 AM, Nate Finch wrote:
> > This mashes all your pre-PR commits into one, so hides some commit spam
> > that way, but then keeps the post-PR commits, to preserve comments.  It
> > sounds like we can still get a list of just the merges from git, to
> exclude
> > all the commits during code review.
> >
> > This sounds like the best of both worlds (or as close as we can get) and
> > removes one more step (rebasing after code review changes), which seems
> > like a good thing.
> >
> > Thoughts?
> >
>
> Completely agree. Rebase (or rewriting history in general, like git
> commit --amend) should only be done in private branches. Use it to clean
> up your own personal commits (which are less interesting to have in a
> main master branch), and to replay upstream's newer commits in front of
> your current WIP.
>

I consider my fork of juju on github to be more-or-less private; I would be
surprised if anyone was branching off anything on there.

Once that branch hits a pull request, it's public, and needs to be
> merged in public.
>
> We should never, ever need to do a 'git push -f', unless something has
> gone horribly wrong. When you force push, you break that branch for
> everyone else who has it.
>

This is a problem if people are branching off your fork. How often do
people do that in practice?
If the answer is "never" or "very rarely" then I don't think it's really a
problem.

>
> >
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140606/c3b98764/attachment.html>