On 06/06/14 11:52, Andrew Wilkins wrote: > On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall > <[email protected] <mailto:[email protected]>> 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
