not rebasing after PR?

Casey Marshall casey.marshall at canonical.com
Thu Jun 5 17:22:26 UTC 2014


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.

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.

> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140605/04a44e8a/attachment.pgp>


More information about the Juju-dev mailing list