On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall <casey.marsh...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
