not rebasing after PR?

[Nate Finch]

I am far from a git expert, but it sounds like we can get a bzr-like
overview of merges to trunk if we give git the right command. This is from
the canonical-tech discussion:

(from Dimitri John Ledkov)
> On Thu, Jun 5, 2014 at 2:26 PM, Ian Booth <ian.booth at canonical.com> wrote:
> >
> > >  (from Nate Finch)
> > > As for bzr versus git, I honestly don't see much of a difference.  I
> know
> > > there are things that bzr does better than git, but they're not
> features I
> > > really ever used, so I don't miss them.
> > >
> >
> > What about all the complications, hassle, and extra overhead with the
> need to
> > rebase all the time due to git's logging model? There's just no need for
> that in
> > bzr so the workflow is *much* simpler [0].
> bzr defaults to showing just the first parent only, but you can see
> all the glory details with "$ bzr log -n 0".
> git defaults to glory details, but you can get equivalent to bzr
> default view as well, e.g. compare output of:
> $ git log --oneline --graph --decorate
> with
> $ git log --oneline --graph --decorate --first-parent
> If one consistently merges in, individual branches only, git will
> generate the same graph history as bzr and will be able to present it
> the same way bzr would.


This sounds like it might solve some of the problems we're worrying about
that get caused by rebasing, such as losing comments etc.

It sounds like this might be a usable workflow:


   - commit several times to your feature branch.
   - rebase into a single commit
   - submit pull request
   - comment on pull request & commit patches to pull request
   - merge pull request as-is (with extra commits after submit)


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140605/c069514a/attachment-0001.html>