Use rebase instead of merge to accept pull request

[Strong Liu <st...@apache.org>]

Hi guys,

as $subject, rebase would give us a much much cleaner view to see what’s
happening :D

it is really hard to trace the commit history, for example

WDYT?

Re: Use rebase instead of merge to accept pull request

[Scott Ganyo <sc...@ganyo.com>]

This is also described here: http://differential.io/blog/best-way-to-merge-a-github-pull-request. 

Note: Also includes a good reason why to *not* use/allow fast-forward.

Scott

On Apr 21, 2014, at 9:58 AM, Shaozhuang Liu <st...@hibernate.org> wrote:

> in hibernate project, we do the following to accept a PR:
> 
> 1. check out a local branch from the original PR creator's branch
> 2. rebase it to the master (or whatever the target branch is)
> 3. push master
> 
> of course, there will be some conflicts if the creator's branch can't be fast forwarded
> personally, I'd resolve the conflicts if it is not too complicated, but usually, I'd say it is the creator's job to make sure the PR can be fast forward.
> 
> and this process surely is more complicated than click the "merge" button, but, you will get a liner history, I'd say it is much more important for an open source project.
> 
> IIRC, there is a git config to only allow fast forward merge.
> 
> and keep the PR small would resolve most of conflicts, or easier.
> 
> here is an example of hibernate validator project commit history
> 
> the "incrementing brower versioning" PR and my 'Miscellaneous" PR (see attach) both can be rebased w/o any conflicts I think
> 
> 
>  
> 
> 
> 
> On Tue, Apr 22, 2014 at 12:28 AM, Todd Nine <to...@gmail.com> wrote:
> Hey Strong,
>   What would your proposed flow be for rebasing before PR?  I agree it's
> much cleaner from a commit history standpoint.  For me, I've never
> successfully managed to rebase anything without receiving merge errors for
> every commit replay.  When you have a large feature branch that's touched a
> lot of code, manually merging each commit during the rebase is really
> painful.  We've been using merge because from a developer perspective it
> "just works".  If you have a strategy that has worked well for you in the
> past, I'm all for giving it a try.
> 
> Thoughts?
> Todd
> 
> 
> On Mon, Apr 21, 2014 at 9:14 AM, Strong Liu <st...@apache.org> wrote:
> 
> > Hi guys,
> >
> > as $subject, rebase would give us a much much cleaner view to see what’s
> > happening :D
> >
> > it is really hard to trace the commit history, for example
> >
> > WDYT?
> >
> 

Re: Use rebase instead of merge to accept pull request

[Shaozhuang Liu <st...@hibernate.org>]

in hibernate project, we do the following to accept a PR:

1. check out a local branch from the original PR creator's branch
2. rebase it to the master (or whatever the target branch is)
3. push master

of course, there will be some conflicts if the creator's branch can't be
fast forwarded
personally, I'd resolve the conflicts if it is not too complicated, but
usually, I'd say it is the creator's job to make sure the PR can be fast
forward.

and this process surely is more complicated than click the "merge" button,
but, you will get a liner history, I'd say it is much more important for an
open source project.

IIRC, there is a git config to only allow fast forward merge.

and keep the PR small would resolve most of conflicts, or easier.

here is an example of hibernate validator project commit history

the "incrementing brower versioning" PR and my 'Miscellaneous" PR (see
attach) both can be rebased w/o any conflicts I think






On Tue, Apr 22, 2014 at 12:28 AM, Todd Nine <to...@gmail.com> wrote:

> Hey Strong,
>   What would your proposed flow be for rebasing before PR?  I agree it's
> much cleaner from a commit history standpoint.  For me, I've never
> successfully managed to rebase anything without receiving merge errors for
> every commit replay.  When you have a large feature branch that's touched a
> lot of code, manually merging each commit during the rebase is really
> painful.  We've been using merge because from a developer perspective it
> "just works".  If you have a strategy that has worked well for you in the
> past, I'm all for giving it a try.
>
> Thoughts?
> Todd
>
>
> On Mon, Apr 21, 2014 at 9:14 AM, Strong Liu <st...@apache.org> wrote:
>
> > Hi guys,
> >
> > as $subject, rebase would give us a much much cleaner view to see what’s
> > happening :D
> >
> > it is really hard to trace the commit history, for example
> >
> > WDYT?
> >
>

Re: Use rebase instead of merge to accept pull request

[Todd Nine <to...@gmail.com>]

Hey Strong,
  What would your proposed flow be for rebasing before PR?  I agree it's
much cleaner from a commit history standpoint.  For me, I've never
successfully managed to rebase anything without receiving merge errors for
every commit replay.  When you have a large feature branch that's touched a
lot of code, manually merging each commit during the rebase is really
painful.  We've been using merge because from a developer perspective it
"just works".  If you have a strategy that has worked well for you in the
past, I'm all for giving it a try.

Thoughts?
Todd


On Mon, Apr 21, 2014 at 9:14 AM, Strong Liu <st...@apache.org> wrote:

> Hi guys,
>
> as $subject, rebase would give us a much much cleaner view to see what’s
> happening :D
>
> it is really hard to trace the commit history, for example
>
> WDYT?
>