mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Afrooze, Sina" <>
Subject Re: Which merge option to use on the Import Julia binding PR?
Date Thu, 27 Sep 2018 00:54:46 GMT
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" <> wrote:

    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
     * 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 <> 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 <> wrote:
    > > The Import Julia binding PR ,(
    > >, 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
    > >

View raw message