not rebasing after PR?

[Tim Penhey]

On 06/06/14 11:52, Andrew Wilkins wrote:
> On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall
> <casey.marshall at canonical.com <mailto: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.

Me too

>     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.

I agree.

I also treat my juju branches as private.

Tim