not rebasing after PR?

[roger peppe]

I'd love to ditch rebasing if it was reasonable to do so.
It just adds overhead to an already tiresome procedure.


On 5 June 2014 16:22, Nate Finch <nate.finch at canonical.com> wrote:
> 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?
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>