Hi Carin - I highly recommend to squash and commit because:
- Every single commit in the repo is guaranteed to be buildable and to have
passed all unit-tests (very important when looking for regressions)
- It is easy to correlate each commit with its corresponding PR. Otherwise I
believe the PR number would be missing from the commit log messages.
- Best, Sina
On 9/26/18, 5:35 PM, "Carin Meier" <carinme...@gmail.com> wrote:
Chiyuan,
Thanks for the prompt to find some clarity of the pros and cons of each. I
think that will help drive us to the right decision. I think some of those
reasons are the ones you listed. I will take a stab below at outlining what
I see. Feel free to chime in if I missed any.
*Squash and Merge*
*Pros* - It is the project standard
- It will provide one commit for the feature and lessen the need
for 700+ commits rebased on top of master.
- It is easier for a user to do git log to browse commits and see
what was features were added.
*Cons* - I don't know how github would handle squashing all those commit
messages into one. Will it be too much?
- You lose the granularity of the features individual commits
*Rebase and Merge*
* Pros *- You don't have a huge commit message with one commit
- You do have the granularity of the individual features of the
commit
* Cons *- It is not the project standard
- You have 700+ commits on top of master that might be harder to
see the ones that went in right before. (like someone browsing commits)
On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang <plus...@gmail.com> wrote:
> Hi Carin,
>
> Can you clarify the pros and cons of the two approaches? Is the main
> concern here about logistics (e.g. preserving the history of the original
> repo and developments) or technical issue (e.g. using squash might end up
> with a huuuuge commit message that might be difficult or hard to handle)?
>
> I think it might not be very likely that someone is going to cherry pick
> revert some of the commits. But preserving the commit history is still
> useful in case one need to trace the change or bisect for some regression
> bugs, etc.
>
> Just to provide some context: the PR actually contains 700+ commits, and
it
> dates back to 2015. The development of the Julia binding started in the
> early stage of MXNet. We started with a separate repo due to the
> requirement of the package system of julia.
>
> Best,
> Chiyuan
>
> On Wed, Sep 26, 2018 at 3:41 PM Carin Meier <carinme...@gmail.com> wrote:
>
> > The Import Julia binding PR ,(
> > https://github.com/apache/incubator-mxnet/pull/10149), is getting very
> > close to being merged. Because of the large number of commits there was
a
> > suggestion not to use the usual "Squash and Merge". The only option
> would
> > be "Rebase and Merge" since merging with a merge commit is not enabled
> for
> > the project.
> >
> > *Squash and Merge* - The commits from this branch will be combined into
> one
> > commit in the base branch (With all the commit messages combined)
> >
> > *Rebase and Merge* - The commits from this branch will be rebased and
> added
> > to the base branch
> >
> > The PR is over 250+ commits (Github won't show all of them)
> >
> > Thoughts about how we should handle the merge?
> >
> > Thanks,
> > Carin
> >
>
