Which merge option to use on the Import Julia binding PR?

[Carin Meier]

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

Re: Which merge option to use on the Import Julia binding PR?

[kellen sunderland]

My gut feel would be just to squash and merge, it usually works quite well.

Is there any chance that someone might want to cherry-pick, revert or
rebase any portions of the PR?

If so what I try and is to provide atomic commits the bring small
individual pieces of value to the codebase.  This often means at the end of
the PR I'd do some git hygiene, get rework my commits and then force push.
I try to ensure that I also leave a backup branch in GitHub that contains
my original git history.  If you have an atomic chain of commits then it
might make more sense to rebase and merge.

On Wed, Sep 26, 2018, 3:41 PM Carin Meier  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
>

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Kellen,

Thanks for your input. We can certainly try squash and merge and see if
there are any issues.

My inclination is same as yours in the case of the git rework, but I'm not
sure how feasible it is since commits go back to Jan 2017 - It's bringing
in this repo work I believe https://github.com/dmlc/MXNet.jl.

Here is an example of the first commit in the PR
Commits on Jan 29, 2017

   1.

   Merge pull request
   

#196  from
   dmlc/vc/fix_win
   

…
   [image: @vchuravy] 
   vchuravy
   
committed on Jan 29, 2017

   remove usr/setupenv.cmd because it is too invasive



On Wed, Sep 26, 2018 at 7:15 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> My gut feel would be just to squash and merge, it usually works quite well.
>
> Is there any chance that someone might want to cherry-pick, revert or
> rebase any portions of the PR?
>
> If so what I try and is to provide atomic commits the bring small
> individual pieces of value to the codebase.  This often means at the end of
> the PR I'd do some git hygiene, get rework my commits and then force push.
> I try to ensure that I also leave a backup branch in GitHub that contains
> my original git history.  If you have an atomic chain of commits then it
> might make more sense to rebase and merge.
>
> On Wed, Sep 26, 2018, 3:41 PM Carin Meier  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
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

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 hge 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 ,(
> 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
>

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

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  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 hge 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 ,(
> > 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
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Afrooze, Sina]

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:

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  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 hge 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 ,(
> > 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
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Tianqi Chen]

In this particular case, I would suggest rebase and merge.

The main reasoning is that the commit log of the Julia binding is not
simple WIP commits, every commit there has been done through testcases and
it is important for us to respect the developer of the effort. It is also
good to trace back the history of the commits more easily.

Tianqi


Tianqi

On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  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  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 hge 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 ,(
> > > 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
> > >
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Tianqi Chen]

One of the main reason for a rebase merge is that it preserves the commit
history of the MXNet.jl package contributors, and given that the project
has been evolved since 2015 and has always been a high-quality language
module for MXNet.

I think we should take an exception here to preserve the commit history of
each individual contributors to the Julia binding and welcome them to the
community.

Tianqi

On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
wrote:

> In this particular case, I would suggest rebase and merge.
>
> The main reasoning is that the commit log of the Julia binding is not
> simple WIP commits, every commit there has been done through testcases and
> it is important for us to respect the developer of the effort. It is also
> good to trace back the history of the commits more easily.
>
> Tianqi
>
>
> Tianqi
>
> On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  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  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 hge 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 ,(
>> > > 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
>> > >
>> >
>>
>

Re: Which merge option to use on the Import Julia binding PR?

[Naveen Swamy]

this PR comes from more than 1 individual, if we squash merge we'll not be
able to attribute the contribution of those individuals.

+1 to rebase merge to preserve history

On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
wrote:

> One of the main reason for a rebase merge is that it preserves the commit
> history of the MXNet.jl package contributors, and given that the project
> has been evolved since 2015 and has always been a high-quality language
> module for MXNet.
>
> I think we should take an exception here to preserve the commit history of
> each individual contributors to the Julia binding and welcome them to the
> community.
>
> Tianqi
>
> On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> wrote:
>
> > In this particular case, I would suggest rebase and merge.
> >
> > The main reasoning is that the commit log of the Julia binding is not
> > simple WIP commits, every commit there has been done through testcases
> and
> > it is important for us to respect the developer of the effort. It is also
> > good to trace back the history of the commits more easily.
> >
> > Tianqi
> >
> >
> > Tianqi
> >
> > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> 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 
> 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 hge 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 ,(
> >> > > 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
> >> > >
> >> >
> >>
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Aaron Markham]

+1 to rebase and merge to retain the efforts of all of the contributors. If
there's some git maintenance that can trim it down from 700+ commits then
maybe that's a compromise.

On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:

> this PR comes from more than 1 individual, if we squash merge we'll not be
> able to attribute the contribution of those individuals.
>
> +1 to rebase merge to preserve history
>
> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
> wrote:
>
> > One of the main reason for a rebase merge is that it preserves the commit
> > history of the MXNet.jl package contributors, and given that the project
> > has been evolved since 2015 and has always been a high-quality language
> > module for MXNet.
> >
> > I think we should take an exception here to preserve the commit history
> of
> > each individual contributors to the Julia binding and welcome them to the
> > community.
> >
> > Tianqi
> >
> > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> > wrote:
> >
> > > In this particular case, I would suggest rebase and merge.
> > >
> > > The main reasoning is that the commit log of the Julia binding is not
> > > simple WIP commits, every commit there has been done through testcases
> > and
> > > it is important for us to respect the developer of the effort. It is
> also
> > > good to trace back the history of the commits more easily.
> > >
> > > Tianqi
> > >
> > >
> > > Tianqi
> > >
> > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> > 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 
> > 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 hge 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 ,(
> > >> > > 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
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

+1 for rebase and merge

Aaron Markham  schrieb am Do., 27. Sep. 2018,
06:27:

> +1 to rebase and merge to retain the efforts of all of the contributors. If
> there's some git maintenance that can trim it down from 700+ commits then
> maybe that's a compromise.
>
> On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
>
> > this PR comes from more than 1 individual, if we squash merge we'll not
> be
> > able to attribute the contribution of those individuals.
> >
> > +1 to rebase merge to preserve history
> >
> > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
> > wrote:
> >
> > > One of the main reason for a rebase merge is that it preserves the
> commit
> > > history of the MXNet.jl package contributors, and given that the
> project
> > > has been evolved since 2015 and has always been a high-quality language
> > > module for MXNet.
> > >
> > > I think we should take an exception here to preserve the commit history
> > of
> > > each individual contributors to the Julia binding and welcome them to
> the
> > > community.
> > >
> > > Tianqi
> > >
> > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> > > wrote:
> > >
> > > > In this particular case, I would suggest rebase and merge.
> > > >
> > > > The main reasoning is that the commit log of the Julia binding is not
> > > > simple WIP commits, every commit there has been done through
> testcases
> > > and
> > > > it is important for us to respect the developer of the effort. It is
> > also
> > > > good to trace back the history of the commits more easily.
> > > >
> > > > Tianqi
> > > >
> > > >
> > > > Tianqi
> > > >
> > > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> > > 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 
> > > 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 hge 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 ,(
> > > >> > > 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)

Re: Which merge option to use on the Import Julia binding PR?

[Jason Dai]

+1 to rebase and merge to preserve and track the contributions.

Thanks,
-Jason

On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham 
wrote:

> +1 to rebase and merge to retain the efforts of all of the contributors. If
> there's some git maintenance that can trim it down from 700+ commits then
> maybe that's a compromise.
>
> On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
>
> > this PR comes from more than 1 individual, if we squash merge we'll not
> be
> > able to attribute the contribution of those individuals.
> >
> > +1 to rebase merge to preserve history
> >
> > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
> > wrote:
> >
> > > One of the main reason for a rebase merge is that it preserves the
> commit
> > > history of the MXNet.jl package contributors, and given that the
> project
> > > has been evolved since 2015 and has always been a high-quality language
> > > module for MXNet.
> > >
> > > I think we should take an exception here to preserve the commit history
> > of
> > > each individual contributors to the Julia binding and welcome them to
> the
> > > community.
> > >
> > > Tianqi
> > >
> > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> > > wrote:
> > >
> > > > In this particular case, I would suggest rebase and merge.
> > > >
> > > > The main reasoning is that the commit log of the Julia binding is not
> > > > simple WIP commits, every commit there has been done through
> testcases
> > > and
> > > > it is important for us to respect the developer of the effort. It is
> > also
> > > > good to trace back the history of the commits more easily.
> > > >
> > > > Tianqi
> > > >
> > > >
> > > > Tianqi
> > > >
> > > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> > > 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 
> > > 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 hge 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 ,(
> > > >> > > 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

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

+1 for rebase and merge. As a workaround for the aforementioned issue,
maybe we can create a tag for the commit before the merge, so that in case
people want to browse the recent main-repo commits by skipping this big
chunk of rebased commits, there is a pointer to take his or her hand on.

Best,
Chiyuan

On Thu, Sep 27, 2018 at 7:34 AM Jason Dai  wrote:

> +1 to rebase and merge to preserve and track the contributions.
>
> Thanks,
> -Jason
>
> On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham 
> wrote:
>
> > +1 to rebase and merge to retain the efforts of all of the contributors.
> If
> > there's some git maintenance that can trim it down from 700+ commits then
> > maybe that's a compromise.
> >
> > On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
> >
> > > this PR comes from more than 1 individual, if we squash merge we'll not
> > be
> > > able to attribute the contribution of those individuals.
> > >
> > > +1 to rebase merge to preserve history
> > >
> > > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
> tqc...@cs.washington.edu>
> > > wrote:
> > >
> > > > One of the main reason for a rebase merge is that it preserves the
> > commit
> > > > history of the MXNet.jl package contributors, and given that the
> > project
> > > > has been evolved since 2015 and has always been a high-quality
> language
> > > > module for MXNet.
> > > >
> > > > I think we should take an exception here to preserve the commit
> history
> > > of
> > > > each individual contributors to the Julia binding and welcome them to
> > the
> > > > community.
> > > >
> > > > Tianqi
> > > >
> > > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
> tqc...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > In this particular case, I would suggest rebase and merge.
> > > > >
> > > > > The main reasoning is that the commit log of the Julia binding is
> not
> > > > > simple WIP commits, every commit there has been done through
> > testcases
> > > > and
> > > > > it is important for us to respect the developer of the effort. It
> is
> > > also
> > > > > good to trace back the history of the commits more easily.
> > > > >
> > > > > Tianqi
> > > > >
> > > > >
> > > > > Tianqi
> > > > >
> > > > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> > > > 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 
> > > > 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 hge 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
> > > > >> >
> >

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Thanks everyone for the input. I'll try to summarize the feedback from the
responses:

Using Squash-Merge is the project standard for very good reasons. However,
in the case of this PR to bring in the Julia language from its sibling
repo, we want to preserve all the individual commits of the many
contributors that have worked over multiple years to make this a great
language binding. We will use Rebase-Merge for it.

Chiyuan - thanks for the suggestion of using a tag. I think we can try it
initially without it since there are other ways to browse the commit
history, like looking at the PRs. But, we can add the tag retroactively if
people start having trouble.

If there no objections, I will merge the PR using the above method in my
morning (EST).

Thanks everyone! I'm looking forward to having the Julia community join the
main repo and increasing our collaboration with them.

Best,
Carin

On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang  wrote:

> +1 for rebase and merge. As a workaround for the aforementioned issue,
> maybe we can create a tag for the commit before the merge, so that in case
> people want to browse the recent main-repo commits by skipping this big
> chunk of rebased commits, there is a pointer to take his or her hand on.
>
> Best,
> Chiyuan
>
> On Thu, Sep 27, 2018 at 7:34 AM Jason Dai  wrote:
>
> > +1 to rebase and merge to preserve and track the contributions.
> >
> > Thanks,
> > -Jason
> >
> > On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> aaron.s.mark...@gmail.com>
> > wrote:
> >
> > > +1 to rebase and merge to retain the efforts of all of the
> contributors.
> > If
> > > there's some git maintenance that can trim it down from 700+ commits
> then
> > > maybe that's a compromise.
> > >
> > > On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
> > >
> > > > this PR comes from more than 1 individual, if we squash merge we'll
> not
> > > be
> > > > able to attribute the contribution of those individuals.
> > > >
> > > > +1 to rebase merge to preserve history
> > > >
> > > > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > One of the main reason for a rebase merge is that it preserves the
> > > commit
> > > > > history of the MXNet.jl package contributors, and given that the
> > > project
> > > > > has been evolved since 2015 and has always been a high-quality
> > language
> > > > > module for MXNet.
> > > > >
> > > > > I think we should take an exception here to preserve the commit
> > history
> > > > of
> > > > > each individual contributors to the Julia binding and welcome them
> to
> > > the
> > > > > community.
> > > > >
> > > > > Tianqi
> > > > >
> > > > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > > wrote:
> > > > >
> > > > > > In this particular case, I would suggest rebase and merge.
> > > > > >
> > > > > > The main reasoning is that the commit log of the Julia binding is
> > not
> > > > > > simple WIP commits, every commit there has been done through
> > > testcases
> > > > > and
> > > > > > it is important for us to respect the developer of the effort. It
> > is
> > > > also
> > > > > > good to trace back the history of the commits more easily.
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > > On Wed, Sep 26, 2018 at 5:34 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
> > > > comm

Re: Which merge option to use on the Import Julia binding PR?

[Pedro Larroy]

I'm not familiar with the specifics of this contribution, as a general
approach my understanding is that if the list of commits is big and you
want to preserve history, usually merging is better so you keep history and
causality, if you rebase all the commits on top of master you are changing
the history of these commits which can't be individually reverted as some
have suggested before. Maybe is because I come from a mercurial background,
but my initial impression would be either to:
1. squash everything and rebase
2. or merge without rebasing or squashing.

Pedro.

On Thu, Sep 27, 2018 at 3:10 PM Carin Meier  wrote:

> Thanks everyone for the input. I'll try to summarize the feedback from the
> responses:
>
> Using Squash-Merge is the project standard for very good reasons. However,
> in the case of this PR to bring in the Julia language from its sibling
> repo, we want to preserve all the individual commits of the many
> contributors that have worked over multiple years to make this a great
> language binding. We will use Rebase-Merge for it.
>
> Chiyuan - thanks for the suggestion of using a tag. I think we can try it
> initially without it since there are other ways to browse the commit
> history, like looking at the PRs. But, we can add the tag retroactively if
> people start having trouble.
>
> If there no objections, I will merge the PR using the above method in my
> morning (EST).
>
> Thanks everyone! I'm looking forward to having the Julia community join the
> main repo and increasing our collaboration with them.
>
> Best,
> Carin
>
> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang  wrote:
>
> > +1 for rebase and merge. As a workaround for the aforementioned issue,
> > maybe we can create a tag for the commit before the merge, so that in
> case
> > people want to browse the recent main-repo commits by skipping this big
> > chunk of rebased commits, there is a pointer to take his or her hand on.
> >
> > Best,
> > Chiyuan
> >
> > On Thu, Sep 27, 2018 at 7:34 AM Jason Dai  wrote:
> >
> > > +1 to rebase and merge to preserve and track the contributions.
> > >
> > > Thanks,
> > > -Jason
> > >
> > > On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> > aaron.s.mark...@gmail.com>
> > > wrote:
> > >
> > > > +1 to rebase and merge to retain the efforts of all of the
> > contributors.
> > > If
> > > > there's some git maintenance that can trim it down from 700+ commits
> > then
> > > > maybe that's a compromise.
> > > >
> > > > On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
> > > >
> > > > > this PR comes from more than 1 individual, if we squash merge we'll
> > not
> > > > be
> > > > > able to attribute the contribution of those individuals.
> > > > >
> > > > > +1 to rebase merge to preserve history
> > > > >
> > > > > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
> > > tqc...@cs.washington.edu>
> > > > > wrote:
> > > > >
> > > > > > One of the main reason for a rebase merge is that it preserves
> the
> > > > commit
> > > > > > history of the MXNet.jl package contributors, and given that the
> > > > project
> > > > > > has been evolved since 2015 and has always been a high-quality
> > > language
> > > > > > module for MXNet.
> > > > > >
> > > > > > I think we should take an exception here to preserve the commit
> > > history
> > > > > of
> > > > > > each individual contributors to the Julia binding and welcome
> them
> > to
> > > > the
> > > > > > community.
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
> > > tqc...@cs.washington.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > In this particular case, I would suggest rebase and merge.
> > > > > > >
> > > > > > > The main reasoning is that the commit log of the Julia binding
> is
> > > not
> > > > > > > simple WIP commits, every commit there has been done through
> > > > testcases
> > > > > > and
> > > > > > > it is important for us to respect the developer of the effort.
> It
> > > is
> > > > > also
> > > > > > > good to trace back the history of the commits more easily.
> > > > > > >
> > > > > > > Tianqi
> > > > > > >
> > > > > > >
> > > > > > > Tianqi
> > > > > > >
> > > > > > > On Wed, Sep 26, 2018 at 5:34 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.
> > > > > > >>  

Re: Which merge option to use on the Import Julia binding PR?

[Naveen Swamy]

Should we try to first being into a branch and then try merge that branch? 

> On Sep 28, 2018, at 4:40 PM, Pedro Larroy  
> wrote:
> 
> I'm not familiar with the specifics of this contribution, as a general
> approach my understanding is that if the list of commits is big and you
> want to preserve history, usually merging is better so you keep history and
> causality, if you rebase all the commits on top of master you are changing
> the history of these commits which can't be individually reverted as some
> have suggested before. Maybe is because I come from a mercurial background,
> but my initial impression would be either to:
> 1. squash everything and rebase
> 2. or merge without rebasing or squashing.
> 
> Pedro.
> 
>> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier  wrote:
>> 
>> Thanks everyone for the input. I'll try to summarize the feedback from the
>> responses:
>> 
>> Using Squash-Merge is the project standard for very good reasons. However,
>> in the case of this PR to bring in the Julia language from its sibling
>> repo, we want to preserve all the individual commits of the many
>> contributors that have worked over multiple years to make this a great
>> language binding. We will use Rebase-Merge for it.
>> 
>> Chiyuan - thanks for the suggestion of using a tag. I think we can try it
>> initially without it since there are other ways to browse the commit
>> history, like looking at the PRs. But, we can add the tag retroactively if
>> people start having trouble.
>> 
>> If there no objections, I will merge the PR using the above method in my
>> morning (EST).
>> 
>> Thanks everyone! I'm looking forward to having the Julia community join the
>> main repo and increasing our collaboration with them.
>> 
>> Best,
>> Carin
>> 
>>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang  wrote:
>>> 
>>> +1 for rebase and merge. As a workaround for the aforementioned issue,
>>> maybe we can create a tag for the commit before the merge, so that in
>> case
>>> people want to browse the recent main-repo commits by skipping this big
>>> chunk of rebased commits, there is a pointer to take his or her hand on.
>>> 
>>> Best,
>>> Chiyuan
>>> 
 On Thu, Sep 27, 2018 at 7:34 AM Jason Dai  wrote:
 
 +1 to rebase and merge to preserve and track the contributions.
 
 Thanks,
 -Jason
 
 On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
>>> aaron.s.mark...@gmail.com>
 wrote:
 
> +1 to rebase and merge to retain the efforts of all of the
>>> contributors.
 If
> there's some git maintenance that can trim it down from 700+ commits
>>> then
> maybe that's a compromise.
> 
>> On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
>> 
>> this PR comes from more than 1 individual, if we squash merge we'll
>>> not
> be
>> able to attribute the contribution of those individuals.
>> 
>> +1 to rebase merge to preserve history
>> 
>> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
 tqc...@cs.washington.edu>
>> wrote:
>> 
>>> One of the main reason for a rebase merge is that it preserves
>> the
> commit
>>> history of the MXNet.jl package contributors, and given that the
> project
>>> has been evolved since 2015 and has always been a high-quality
 language
>>> module for MXNet.
>>> 
>>> I think we should take an exception here to preserve the commit
 history
>> of
>>> each individual contributors to the Julia binding and welcome
>> them
>>> to
> the
>>> community.
>>> 
>>> Tianqi
>>> 
>>> On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
 tqc...@cs.washington.edu>
>>> wrote:
>>> 
 In this particular case, I would suggest rebase and merge.
 
 The main reasoning is that the commit log of the Julia binding
>> is
 not
 simple WIP commits, every commit there has been done through
> testcases
>>> and
 it is important for us to respect the developer of the effort.
>> It
 is
>> also
 good to trace back the history of the commits more easily.
 
 Tianqi
 
 
 Tianqi
 
 On Wed, Sep 26, 2018 at 5:34 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

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

We are actually running into troubles with using the subtree and the
rebase. Since it looks like this is not going to be a simple, "click the
button" through the web page merge, I rather hand this task off to someone
with more context in making sure it gets in there correctly.

Chiyuan or any others, would you be willing to take this over?

Thanks,
Carin

On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:

> Should we try to first being into a branch and then try merge that branch?
>
> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy 
> wrote:
> >
> > I'm not familiar with the specifics of this contribution, as a general
> > approach my understanding is that if the list of commits is big and you
> > want to preserve history, usually merging is better so you keep history
> and
> > causality, if you rebase all the commits on top of master you are
> changing
> > the history of these commits which can't be individually reverted as some
> > have suggested before. Maybe is because I come from a mercurial
> background,
> > but my initial impression would be either to:
> > 1. squash everything and rebase
> > 2. or merge without rebasing or squashing.
> >
> > Pedro.
> >
> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> wrote:
> >>
> >> Thanks everyone for the input. I'll try to summarize the feedback from
> the
> >> responses:
> >>
> >> Using Squash-Merge is the project standard for very good reasons.
> However,
> >> in the case of this PR to bring in the Julia language from its sibling
> >> repo, we want to preserve all the individual commits of the many
> >> contributors that have worked over multiple years to make this a great
> >> language binding. We will use Rebase-Merge for it.
> >>
> >> Chiyuan - thanks for the suggestion of using a tag. I think we can try
> it
> >> initially without it since there are other ways to browse the commit
> >> history, like looking at the PRs. But, we can add the tag retroactively
> if
> >> people start having trouble.
> >>
> >> If there no objections, I will merge the PR using the above method in my
> >> morning (EST).
> >>
> >> Thanks everyone! I'm looking forward to having the Julia community join
> the
> >> main repo and increasing our collaboration with them.
> >>
> >> Best,
> >> Carin
> >>
> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
> wrote:
> >>>
> >>> +1 for rebase and merge. As a workaround for the aforementioned issue,
> >>> maybe we can create a tag for the commit before the merge, so that in
> >> case
> >>> people want to browse the recent main-repo commits by skipping this big
> >>> chunk of rebased commits, there is a pointer to take his or her hand
> on.
> >>>
> >>> Best,
> >>> Chiyuan
> >>>
>  On Thu, Sep 27, 2018 at 7:34 AM Jason Dai 
> wrote:
> 
>  +1 to rebase and merge to preserve and track the contributions.
> 
>  Thanks,
>  -Jason
> 
>  On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> >>> aaron.s.mark...@gmail.com>
>  wrote:
> 
> > +1 to rebase and merge to retain the efforts of all of the
> >>> contributors.
>  If
> > there's some git maintenance that can trim it down from 700+ commits
> >>> then
> > maybe that's a compromise.
> >
> >> On Wed, Sep 26, 2018, 21:23 Naveen Swamy 
> wrote:
> >>
> >> this PR comes from more than 1 individual, if we squash merge we'll
> >>> not
> > be
> >> able to attribute the contribution of those individuals.
> >>
> >> +1 to rebase merge to preserve history
> >>
> >> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
>  tqc...@cs.washington.edu>
> >> wrote:
> >>
> >>> One of the main reason for a rebase merge is that it preserves
> >> the
> > commit
> >>> history of the MXNet.jl package contributors, and given that the
> > project
> >>> has been evolved since 2015 and has always been a high-quality
>  language
> >>> module for MXNet.
> >>>
> >>> I think we should take an exception here to preserve the commit
>  history
> >> of
> >>> each individual contributors to the Julia binding and welcome
> >> them
> >>> to
> > the
> >>> community.
> >>>
> >>> Tianqi
> >>>
> >>> On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
>  tqc...@cs.washington.edu>
> >>> wrote:
> >>>
>  In this particular case, I would suggest rebase and merge.
> 
>  The main reasoning is that the commit log of the Julia binding
> >> is
>  not
>  simple WIP commits, every commit there has been done through
> > testcases
> >>> and
>  it is important for us to respect the developer of the effort.
> >> It
>  is
> >> also
>  good to trace back the history of the commits more easily.
> 
>  Tianqi
> 
> 
>  Tianqi
> 
>  On Wed, Sep 26, 2018 at 5:34 PM Carin Meier <
> >>> carinme...@gmail.com>
> >>> wrote:
> 
> > Chiyuan,
> >
> >>

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Pedro - Maybe a merge commit is a better answer in this case. I originally
ruled it out since it wasn't an option in the github web interface, but
since this looks like it is going to have to be done outside it because of
the subtrees anyway, it might be a better fit.

On Fri, Sep 28, 2018 at 5:07 PM Carin Meier  wrote:

> We are actually running into troubles with using the subtree and the
> rebase. Since it looks like this is not going to be a simple, "click the
> button" through the web page merge, I rather hand this task off to someone
> with more context in making sure it gets in there correctly.
>
> Chiyuan or any others, would you be willing to take this over?
>
> Thanks,
> Carin
>
> On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:
>
>> Should we try to first being into a branch and then try merge that
>> branch?
>>
>> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy 
>> wrote:
>> >
>> > I'm not familiar with the specifics of this contribution, as a general
>> > approach my understanding is that if the list of commits is big and you
>> > want to preserve history, usually merging is better so you keep history
>> and
>> > causality, if you rebase all the commits on top of master you are
>> changing
>> > the history of these commits which can't be individually reverted as
>> some
>> > have suggested before. Maybe is because I come from a mercurial
>> background,
>> > but my initial impression would be either to:
>> > 1. squash everything and rebase
>> > 2. or merge without rebasing or squashing.
>> >
>> > Pedro.
>> >
>> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
>> wrote:
>> >>
>> >> Thanks everyone for the input. I'll try to summarize the feedback from
>> the
>> >> responses:
>> >>
>> >> Using Squash-Merge is the project standard for very good reasons.
>> However,
>> >> in the case of this PR to bring in the Julia language from its sibling
>> >> repo, we want to preserve all the individual commits of the many
>> >> contributors that have worked over multiple years to make this a great
>> >> language binding. We will use Rebase-Merge for it.
>> >>
>> >> Chiyuan - thanks for the suggestion of using a tag. I think we can try
>> it
>> >> initially without it since there are other ways to browse the commit
>> >> history, like looking at the PRs. But, we can add the tag
>> retroactively if
>> >> people start having trouble.
>> >>
>> >> If there no objections, I will merge the PR using the above method in
>> my
>> >> morning (EST).
>> >>
>> >> Thanks everyone! I'm looking forward to having the Julia community
>> join the
>> >> main repo and increasing our collaboration with them.
>> >>
>> >> Best,
>> >> Carin
>> >>
>> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
>> wrote:
>> >>>
>> >>> +1 for rebase and merge. As a workaround for the aforementioned issue,
>> >>> maybe we can create a tag for the commit before the merge, so that in
>> >> case
>> >>> people want to browse the recent main-repo commits by skipping this
>> big
>> >>> chunk of rebased commits, there is a pointer to take his or her hand
>> on.
>> >>>
>> >>> Best,
>> >>> Chiyuan
>> >>>
>>  On Thu, Sep 27, 2018 at 7:34 AM Jason Dai 
>> wrote:
>> 
>>  +1 to rebase and merge to preserve and track the contributions.
>> 
>>  Thanks,
>>  -Jason
>> 
>>  On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
>> >>> aaron.s.mark...@gmail.com>
>>  wrote:
>> 
>> > +1 to rebase and merge to retain the efforts of all of the
>> >>> contributors.
>>  If
>> > there's some git maintenance that can trim it down from 700+ commits
>> >>> then
>> > maybe that's a compromise.
>> >
>> >> On Wed, Sep 26, 2018, 21:23 Naveen Swamy 
>> wrote:
>> >>
>> >> this PR comes from more than 1 individual, if we squash merge we'll
>> >>> not
>> > be
>> >> able to attribute the contribution of those individuals.
>> >>
>> >> +1 to rebase merge to preserve history
>> >>
>> >> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
>>  tqc...@cs.washington.edu>
>> >> wrote:
>> >>
>> >>> One of the main reason for a rebase merge is that it preserves
>> >> the
>> > commit
>> >>> history of the MXNet.jl package contributors, and given that the
>> > project
>> >>> has been evolved since 2015 and has always been a high-quality
>>  language
>> >>> module for MXNet.
>> >>>
>> >>> I think we should take an exception here to preserve the commit
>>  history
>> >> of
>> >>> each individual contributors to the Julia binding and welcome
>> >> them
>> >>> to
>> > the
>> >>> community.
>> >>>
>> >>> Tianqi
>> >>>
>> >>> On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
>>  tqc...@cs.washington.edu>
>> >>> wrote:
>> >>>
>>  In this particular case, I would suggest rebase and merge.
>> 
>>  The main reasoning is that the commit log of the Julia binding
>> >> is
>>  not
>>  simple WIP commit

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

Agreed with Pedro. Maybe the merge-commit option from the github interface
was disabled for a reason. But as Pedro said, maybe it is good to
temporarily enable it for this PR and merge using that.


   - It should be technically easier than rebasing due to the
   git-subtree-import issue we are currently having
   - It also avoid stacking a huge commit history on *top* of current
   history
   - The downside is probably the history of the project is not linear
   anymore, but I think this is actually what we would like to have for this
   particular case, because the contents of the main repo and the julia branch
   actually does not overlap. So it makes sense to have two tails with their
   own history.

Carin: I guess if someone with admin permission on the github could
temporarily enable the merge-commit option, then pushing the button on the
web might simply work.

Best,
Chiyuan

On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  wrote:

> Pedro - Maybe a merge commit is a better answer in this case. I originally
> ruled it out since it wasn't an option in the github web interface, but
> since this looks like it is going to have to be done outside it because of
> the subtrees anyway, it might be a better fit.
>
> On Fri, Sep 28, 2018 at 5:07 PM Carin Meier  wrote:
>
> > We are actually running into troubles with using the subtree and the
> > rebase. Since it looks like this is not going to be a simple, "click the
> > button" through the web page merge, I rather hand this task off to
> someone
> > with more context in making sure it gets in there correctly.
> >
> > Chiyuan or any others, would you be willing to take this over?
> >
> > Thanks,
> > Carin
> >
> > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:
> >
> >> Should we try to first being into a branch and then try merge that
> >> branch?
> >>
> >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> >> wrote:
> >> >
> >> > I'm not familiar with the specifics of this contribution, as a general
> >> > approach my understanding is that if the list of commits is big and
> you
> >> > want to preserve history, usually merging is better so you keep
> history
> >> and
> >> > causality, if you rebase all the commits on top of master you are
> >> changing
> >> > the history of these commits which can't be individually reverted as
> >> some
> >> > have suggested before. Maybe is because I come from a mercurial
> >> background,
> >> > but my initial impression would be either to:
> >> > 1. squash everything and rebase
> >> > 2. or merge without rebasing or squashing.
> >> >
> >> > Pedro.
> >> >
> >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> >> wrote:
> >> >>
> >> >> Thanks everyone for the input. I'll try to summarize the feedback
> from
> >> the
> >> >> responses:
> >> >>
> >> >> Using Squash-Merge is the project standard for very good reasons.
> >> However,
> >> >> in the case of this PR to bring in the Julia language from its
> sibling
> >> >> repo, we want to preserve all the individual commits of the many
> >> >> contributors that have worked over multiple years to make this a
> great
> >> >> language binding. We will use Rebase-Merge for it.
> >> >>
> >> >> Chiyuan - thanks for the suggestion of using a tag. I think we can
> try
> >> it
> >> >> initially without it since there are other ways to browse the commit
> >> >> history, like looking at the PRs. But, we can add the tag
> >> retroactively if
> >> >> people start having trouble.
> >> >>
> >> >> If there no objections, I will merge the PR using the above method in
> >> my
> >> >> morning (EST).
> >> >>
> >> >> Thanks everyone! I'm looking forward to having the Julia community
> >> join the
> >> >> main repo and increasing our collaboration with them.
> >> >>
> >> >> Best,
> >> >> Carin
> >> >>
> >> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
> >> wrote:
> >> >>>
> >> >>> +1 for rebase and merge. As a workaround for the aforementioned
> issue,
> >> >>> maybe we can create a tag for the commit before the merge, so that
> in
> >> >> case
> >> >>> people want to browse the recent main-repo commits by skipping this
> >> big
> >> >>> chunk of rebased commits, there is a pointer to take his or her hand
> >> on.
> >> >>>
> >> >>> Best,
> >> >>> Chiyuan
> >> >>>
> >>  On Thu, Sep 27, 2018 at 7:34 AM Jason Dai 
> >> wrote:
> >> 
> >>  +1 to rebase and merge to preserve and track the contributions.
> >> 
> >>  Thanks,
> >>  -Jason
> >> 
> >>  On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> >> >>> aaron.s.mark...@gmail.com>
> >>  wrote:
> >> 
> >> > +1 to rebase and merge to retain the efforts of all of the
> >> >>> contributors.
> >>  If
> >> > there's some git maintenance that can trim it down from 700+
> commits
> >> >>> then
> >> > maybe that's a compromise.
> >> >
> >> >> On Wed, Sep 26, 2018, 21:23 Naveen Swamy 
> >> wrote:
> >> >>
> >> >> this PR comes from more than 1 individual, if we s

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

I made a test regular merge commit into a copy of master. It seemed to go
fine. Here is a listing of what it will look like for everyone.

https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import

Although, I would be happy to push the merge button. I think the most
important thing is to get the PR merged, so whatever way is the best to
make that happen, let's do it.

So - Does the regular merge seem like a good option?
If so, what is the best way to make that happen?


On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang  wrote:

> Agreed with Pedro. Maybe the merge-commit option from the github interface
> was disabled for a reason. But as Pedro said, maybe it is good to
> temporarily enable it for this PR and merge using that.
>
>
>- It should be technically easier than rebasing due to the
>git-subtree-import issue we are currently having
>- It also avoid stacking a huge commit history on *top* of current
>history
>- The downside is probably the history of the project is not linear
>anymore, but I think this is actually what we would like to have for
> this
>particular case, because the contents of the main repo and the julia
> branch
>actually does not overlap. So it makes sense to have two tails with
> their
>own history.
>
> Carin: I guess if someone with admin permission on the github could
> temporarily enable the merge-commit option, then pushing the button on the
> web might simply work.
>
> Best,
> Chiyuan
>
> On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  wrote:
>
> > Pedro - Maybe a merge commit is a better answer in this case. I
> originally
> > ruled it out since it wasn't an option in the github web interface, but
> > since this looks like it is going to have to be done outside it because
> of
> > the subtrees anyway, it might be a better fit.
> >
> > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> wrote:
> >
> > > We are actually running into troubles with using the subtree and the
> > > rebase. Since it looks like this is not going to be a simple, "click
> the
> > > button" through the web page merge, I rather hand this task off to
> > someone
> > > with more context in making sure it gets in there correctly.
> > >
> > > Chiyuan or any others, would you be willing to take this over?
> > >
> > > Thanks,
> > > Carin
> > >
> > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy 
> wrote:
> > >
> > >> Should we try to first being into a branch and then try merge that
> > >> branch?
> > >>
> > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > >> wrote:
> > >> >
> > >> > I'm not familiar with the specifics of this contribution, as a
> general
> > >> > approach my understanding is that if the list of commits is big and
> > you
> > >> > want to preserve history, usually merging is better so you keep
> > history
> > >> and
> > >> > causality, if you rebase all the commits on top of master you are
> > >> changing
> > >> > the history of these commits which can't be individually reverted as
> > >> some
> > >> > have suggested before. Maybe is because I come from a mercurial
> > >> background,
> > >> > but my initial impression would be either to:
> > >> > 1. squash everything and rebase
> > >> > 2. or merge without rebasing or squashing.
> > >> >
> > >> > Pedro.
> > >> >
> > >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> > >> wrote:
> > >> >>
> > >> >> Thanks everyone for the input. I'll try to summarize the feedback
> > from
> > >> the
> > >> >> responses:
> > >> >>
> > >> >> Using Squash-Merge is the project standard for very good reasons.
> > >> However,
> > >> >> in the case of this PR to bring in the Julia language from its
> > sibling
> > >> >> repo, we want to preserve all the individual commits of the many
> > >> >> contributors that have worked over multiple years to make this a
> > great
> > >> >> language binding. We will use Rebase-Merge for it.
> > >> >>
> > >> >> Chiyuan - thanks for the suggestion of using a tag. I think we can
> > try
> > >> it
> > >> >> initially without it since there are other ways to browse the
> commit
> > >> >> history, like looking at the PRs. But, we can add the tag
> > >> retroactively if
> > >> >> people start having trouble.
> > >> >>
> > >> >> If there no objections, I will merge the PR using the above method
> in
> > >> my
> > >> >> morning (EST).
> > >> >>
> > >> >> Thanks everyone! I'm looking forward to having the Julia community
> > >> join the
> > >> >> main repo and increasing our collaboration with them.
> > >> >>
> > >> >> Best,
> > >> >> Carin
> > >> >>
> > >> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
> > >> wrote:
> > >> >>>
> > >> >>> +1 for rebase and merge. As a workaround for the aforementioned
> > issue,
> > >> >>> maybe we can create a tag for the commit before the merge, so that
> > in
> > >> >> case
> > >> >>> people want to browse the recent main-repo commits by skipping
> this
> > >> big
> > >> >>> chunk of rebased commits, there is a pointer to 

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

Are we sure that this is due to lacking permissions and not because of some
technical limitation? If we are certain, we can ask out mentors to create a
ticket with Apache Infra to make that switch.

-Marco

Carin Meier  schrieb am Sa., 29. Sep. 2018, 01:17:

> I made a test regular merge commit into a copy of master. It seemed to go
> fine. Here is a listing of what it will look like for everyone.
>
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
>
> Although, I would be happy to push the merge button. I think the most
> important thing is to get the PR merged, so whatever way is the best to
> make that happen, let's do it.
>
> So - Does the regular merge seem like a good option?
> If so, what is the best way to make that happen?
>
>
> On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang  wrote:
>
> > Agreed with Pedro. Maybe the merge-commit option from the github
> interface
> > was disabled for a reason. But as Pedro said, maybe it is good to
> > temporarily enable it for this PR and merge using that.
> >
> >
> >- It should be technically easier than rebasing due to the
> >git-subtree-import issue we are currently having
> >- It also avoid stacking a huge commit history on *top* of current
> >history
> >- The downside is probably the history of the project is not linear
> >anymore, but I think this is actually what we would like to have for
> > this
> >particular case, because the contents of the main repo and the julia
> > branch
> >actually does not overlap. So it makes sense to have two tails with
> > their
> >own history.
> >
> > Carin: I guess if someone with admin permission on the github could
> > temporarily enable the merge-commit option, then pushing the button on
> the
> > web might simply work.
> >
> > Best,
> > Chiyuan
> >
> > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
> wrote:
> >
> > > Pedro - Maybe a merge commit is a better answer in this case. I
> > originally
> > > ruled it out since it wasn't an option in the github web interface, but
> > > since this looks like it is going to have to be done outside it because
> > of
> > > the subtrees anyway, it might be a better fit.
> > >
> > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> > wrote:
> > >
> > > > We are actually running into troubles with using the subtree and the
> > > > rebase. Since it looks like this is not going to be a simple, "click
> > the
> > > > button" through the web page merge, I rather hand this task off to
> > > someone
> > > > with more context in making sure it gets in there correctly.
> > > >
> > > > Chiyuan or any others, would you be willing to take this over?
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy 
> > wrote:
> > > >
> > > >> Should we try to first being into a branch and then try merge that
> > > >> branch?
> > > >>
> > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > I'm not familiar with the specifics of this contribution, as a
> > general
> > > >> > approach my understanding is that if the list of commits is big
> and
> > > you
> > > >> > want to preserve history, usually merging is better so you keep
> > > history
> > > >> and
> > > >> > causality, if you rebase all the commits on top of master you are
> > > >> changing
> > > >> > the history of these commits which can't be individually reverted
> as
> > > >> some
> > > >> > have suggested before. Maybe is because I come from a mercurial
> > > >> background,
> > > >> > but my initial impression would be either to:
> > > >> > 1. squash everything and rebase
> > > >> > 2. or merge without rebasing or squashing.
> > > >> >
> > > >> > Pedro.
> > > >> >
> > > >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier <
> carinme...@gmail.com>
> > > >> wrote:
> > > >> >>
> > > >> >> Thanks everyone for the input. I'll try to summarize the feedback
> > > from
> > > >> the
> > > >> >> responses:
> > > >> >>
> > > >> >> Using Squash-Merge is the project standard for very good reasons.
> > > >> However,
> > > >> >> in the case of this PR to bring in the Julia language from its
> > > sibling
> > > >> >> repo, we want to preserve all the individual commits of the many
> > > >> >> contributors that have worked over multiple years to make this a
> > > great
> > > >> >> language binding. We will use Rebase-Merge for it.
> > > >> >>
> > > >> >> Chiyuan - thanks for the suggestion of using a tag. I think we
> can
> > > try
> > > >> it
> > > >> >> initially without it since there are other ways to browse the
> > commit
> > > >> >> history, like looking at the PRs. But, we can add the tag
> > > >> retroactively if
> > > >> >> people start having trouble.
> > > >> >>
> > > >> >> If there no objections, I will merge the PR using the above
> method
> > in
> > > >> my
> > > >> >> morning (EST).
> > > >> >>
> > > >> >> Thanks everyone! I'm looking forward to having the Julia
> community
> > > >>

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

I believe so, but if someone wants to confirm it would be great.
Unfortunately, I just came down with a cold/flu so I will be out of
communication for a bit

On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
 wrote:

> Are we sure that this is due to lacking permissions and not because of some
> technical limitation? If we are certain, we can ask out mentors to create a
> ticket with Apache Infra to make that switch.
>
> -Marco
>
> Carin Meier  schrieb am Sa., 29. Sep. 2018, 01:17:
>
> > I made a test regular merge commit into a copy of master. It seemed to go
> > fine. Here is a listing of what it will look like for everyone.
> >
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >
> > Although, I would be happy to push the merge button. I think the most
> > important thing is to get the PR merged, so whatever way is the best to
> > make that happen, let's do it.
> >
> > So - Does the regular merge seem like a good option?
> > If so, what is the best way to make that happen?
> >
> >
> > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang  wrote:
> >
> > > Agreed with Pedro. Maybe the merge-commit option from the github
> > interface
> > > was disabled for a reason. But as Pedro said, maybe it is good to
> > > temporarily enable it for this PR and merge using that.
> > >
> > >
> > >- It should be technically easier than rebasing due to the
> > >git-subtree-import issue we are currently having
> > >- It also avoid stacking a huge commit history on *top* of current
> > >history
> > >- The downside is probably the history of the project is not linear
> > >anymore, but I think this is actually what we would like to have for
> > > this
> > >particular case, because the contents of the main repo and the julia
> > > branch
> > >actually does not overlap. So it makes sense to have two tails with
> > > their
> > >own history.
> > >
> > > Carin: I guess if someone with admin permission on the github could
> > > temporarily enable the merge-commit option, then pushing the button on
> > the
> > > web might simply work.
> > >
> > > Best,
> > > Chiyuan
> > >
> > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
> > wrote:
> > >
> > > > Pedro - Maybe a merge commit is a better answer in this case. I
> > > originally
> > > > ruled it out since it wasn't an option in the github web interface,
> but
> > > > since this looks like it is going to have to be done outside it
> because
> > > of
> > > > the subtrees anyway, it might be a better fit.
> > > >
> > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> > > wrote:
> > > >
> > > > > We are actually running into troubles with using the subtree and
> the
> > > > > rebase. Since it looks like this is not going to be a simple,
> "click
> > > the
> > > > > button" through the web page merge, I rather hand this task off to
> > > > someone
> > > > > with more context in making sure it gets in there correctly.
> > > > >
> > > > > Chiyuan or any others, would you be willing to take this over?
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy 
> > > wrote:
> > > > >
> > > > >> Should we try to first being into a branch and then try merge that
> > > > >> branch?
> > > > >>
> > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > > > pedro.larroy.li...@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > I'm not familiar with the specifics of this contribution, as a
> > > general
> > > > >> > approach my understanding is that if the list of commits is big
> > and
> > > > you
> > > > >> > want to preserve history, usually merging is better so you keep
> > > > history
> > > > >> and
> > > > >> > causality, if you rebase all the commits on top of master you
> are
> > > > >> changing
> > > > >> > the history of these commits which can't be individually
> reverted
> > as
> > > > >> some
> > > > >> > have suggested before. Maybe is because I come from a mercurial
> > > > >> background,
> > > > >> > but my initial impression would be either to:
> > > > >> > 1. squash everything and rebase
> > > > >> > 2. or merge without rebasing or squashing.
> > > > >> >
> > > > >> > Pedro.
> > > > >> >
> > > > >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier <
> > carinme...@gmail.com>
> > > > >> wrote:
> > > > >> >>
> > > > >> >> Thanks everyone for the input. I'll try to summarize the
> feedback
> > > > from
> > > > >> the
> > > > >> >> responses:
> > > > >> >>
> > > > >> >> Using Squash-Merge is the project standard for very good
> reasons.
> > > > >> However,
> > > > >> >> in the case of this PR to bring in the Julia language from its
> > > > sibling
> > > > >> >> repo, we want to preserve all the individual commits of the
> many
> > > > >> >> contributors that have worked over multiple years to make this
> a
> > > > great
> > > > >> >> language binding. We will use Rebase-Merge for it.
> > > > >> >>
> > > > >> >> Chiyuan - thanks for the suggestion of using a tag. I think we
> > can

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

There is an option in the repo settings menu to disable or enable
merge-commit for PR, see a screenshot below (from a different github
project):

[image: image.png]

My guess is that this is disabled for the reason to avoid creating
non-linear history for standard PRs (as oppose to technical problem). But
this is only my guess, it would be great if someone could confirm.

Best,
Chiyuan

On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  wrote:

> I believe so, but if someone wants to confirm it would be great.
> Unfortunately, I just came down with a cold/flu so I will be out of
> communication for a bit
>
> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>  wrote:
>
> > Are we sure that this is due to lacking permissions and not because of
> some
> > technical limitation? If we are certain, we can ask out mentors to
> create a
> > ticket with Apache Infra to make that switch.
> >
> > -Marco
> >
> > Carin Meier  schrieb am Sa., 29. Sep. 2018, 01:17:
> >
> > > I made a test regular merge commit into a copy of master. It seemed to
> go
> > > fine. Here is a listing of what it will look like for everyone.
> > >
> > >
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > >
> > > Although, I would be happy to push the merge button. I think the most
> > > important thing is to get the PR merged, so whatever way is the best to
> > > make that happen, let's do it.
> > >
> > > So - Does the regular merge seem like a good option?
> > > If so, what is the best way to make that happen?
> > >
> > >
> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> wrote:
> > >
> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> > > interface
> > > > was disabled for a reason. But as Pedro said, maybe it is good to
> > > > temporarily enable it for this PR and merge using that.
> > > >
> > > >
> > > >- It should be technically easier than rebasing due to the
> > > >git-subtree-import issue we are currently having
> > > >- It also avoid stacking a huge commit history on *top* of current
> > > >history
> > > >- The downside is probably the history of the project is not
> linear
> > > >anymore, but I think this is actually what we would like to have
> for
> > > > this
> > > >particular case, because the contents of the main repo and the
> julia
> > > > branch
> > > >actually does not overlap. So it makes sense to have two tails
> with
> > > > their
> > > >own history.
> > > >
> > > > Carin: I guess if someone with admin permission on the github could
> > > > temporarily enable the merge-commit option, then pushing the button
> on
> > > the
> > > > web might simply work.
> > > >
> > > > Best,
> > > > Chiyuan
> > > >
> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
> > > > originally
> > > > > ruled it out since it wasn't an option in the github web interface,
> > but
> > > > > since this looks like it is going to have to be done outside it
> > because
> > > > of
> > > > > the subtrees anyway, it might be a better fit.
> > > > >
> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> > > > wrote:
> > > > >
> > > > > > We are actually running into troubles with using the subtree and
> > the
> > > > > > rebase. Since it looks like this is not going to be a simple,
> > "click
> > > > the
> > > > > > button" through the web page merge, I rather hand this task off
> to
> > > > > someone
> > > > > > with more context in making sure it gets in there correctly.
> > > > > >
> > > > > > Chiyuan or any others, would you be willing to take this over?
> > > > > >
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  >
> > > > wrote:
> > > > > >
> > > > > >> Should we try to first being into a branch and then try merge
> that
> > > > > >> branch?
> > > > > >>
> > > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > > > > pedro.larroy.li...@gmail.com>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > I'm not familiar with the specifics of this contribution, as a
> > > > general
> > > > > >> > approach my understanding is that if the list of commits is
> big
> > > and
> > > > > you
> > > > > >> > want to preserve history, usually merging is better so you
> keep
> > > > > history
> > > > > >> and
> > > > > >> > causality, if you rebase all the commits on top of master you
> > are
> > > > > >> changing
> > > > > >> > the history of these commits which can't be individually
> > reverted
> > > as
> > > > > >> some
> > > > > >> > have suggested before. Maybe is because I come from a
> mercurial
> > > > > >> background,
> > > > > >> > but my initial impression would be either to:
> > > > > >> > 1. squash everything and rebase
> > > > > >> > 2. or merge without rebasing or squashing.
> > > > > >> >
> > > > > >> > Pedro.
> > > > > >> >
> > > > > >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier <
> > > carinme...@gmail.com

Re: Which merge option to use on the Import Julia binding PR?

[Naveen Swamy]

yes, AFAIK I think Apache Infra has disabled the merge option.

If there is a valid reason(and this is one), we could ask our Mentors to
help us create a INFRA ticket to temporarily enable this option and once we
are done merging we can request to disable it again.

On Sat, Sep 29, 2018 at 9:44 PM Chiyuan Zhang  wrote:

> There is an option in the repo settings menu to disable or enable
> merge-commit for PR, see a screenshot below (from a different github
> project):
>
> [image: image.png]
>
> My guess is that this is disabled for the reason to avoid creating
> non-linear history for standard PRs (as oppose to technical problem). But
> this is only my guess, it would be great if someone could confirm.
>
> Best,
> Chiyuan
>
> On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  wrote:
>
>> I believe so, but if someone wants to confirm it would be great.
>> Unfortunately, I just came down with a cold/flu so I will be out of
>> communication for a bit
>>
>> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>>  wrote:
>>
>> > Are we sure that this is due to lacking permissions and not because of
>> some
>> > technical limitation? If we are certain, we can ask out mentors to
>> create a
>> > ticket with Apache Infra to make that switch.
>> >
>> > -Marco
>> >
>> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
>> 01:17:
>> >
>> > > I made a test regular merge commit into a copy of master. It seemed
>> to go
>> > > fine. Here is a listing of what it will look like for everyone.
>> > >
>> > >
>> >
>> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
>> > >
>> > > Although, I would be happy to push the merge button. I think the most
>> > > important thing is to get the PR merged, so whatever way is the best
>> to
>> > > make that happen, let's do it.
>> > >
>> > > So - Does the regular merge seem like a good option?
>> > > If so, what is the best way to make that happen?
>> > >
>> > >
>> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
>> wrote:
>> > >
>> > > > Agreed with Pedro. Maybe the merge-commit option from the github
>> > > interface
>> > > > was disabled for a reason. But as Pedro said, maybe it is good to
>> > > > temporarily enable it for this PR and merge using that.
>> > > >
>> > > >
>> > > >- It should be technically easier than rebasing due to the
>> > > >git-subtree-import issue we are currently having
>> > > >- It also avoid stacking a huge commit history on *top* of
>> current
>> > > >history
>> > > >- The downside is probably the history of the project is not
>> linear
>> > > >anymore, but I think this is actually what we would like to have
>> for
>> > > > this
>> > > >particular case, because the contents of the main repo and the
>> julia
>> > > > branch
>> > > >actually does not overlap. So it makes sense to have two tails
>> with
>> > > > their
>> > > >own history.
>> > > >
>> > > > Carin: I guess if someone with admin permission on the github could
>> > > > temporarily enable the merge-commit option, then pushing the button
>> on
>> > > the
>> > > > web might simply work.
>> > > >
>> > > > Best,
>> > > > Chiyuan
>> > > >
>> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
>> > > wrote:
>> > > >
>> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
>> > > > originally
>> > > > > ruled it out since it wasn't an option in the github web
>> interface,
>> > but
>> > > > > since this looks like it is going to have to be done outside it
>> > because
>> > > > of
>> > > > > the subtrees anyway, it might be a better fit.
>> > > > >
>> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier > >
>> > > > wrote:
>> > > > >
>> > > > > > We are actually running into troubles with using the subtree and
>> > the
>> > > > > > rebase. Since it looks like this is not going to be a simple,
>> > "click
>> > > > the
>> > > > > > button" through the web page merge, I rather hand this task off
>> to
>> > > > > someone
>> > > > > > with more context in making sure it gets in there correctly.
>> > > > > >
>> > > > > > Chiyuan or any others, would you be willing to take this over?
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Carin
>> > > > > >
>> > > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy <
>> mnnav...@gmail.com>
>> > > > wrote:
>> > > > > >
>> > > > > >> Should we try to first being into a branch and then try merge
>> that
>> > > > > >> branch?
>> > > > > >>
>> > > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
>> > > > > pedro.larroy.li...@gmail.com>
>> > > > > >> wrote:
>> > > > > >> >
>> > > > > >> > I'm not familiar with the specifics of this contribution, as
>> a
>> > > > general
>> > > > > >> > approach my understanding is that if the list of commits is
>> big
>> > > and
>> > > > > you
>> > > > > >> > want to preserve history, usually merging is better so you
>> keep
>> > > > > history
>> > > > > >> and
>> > > > > >> > causality, if you rebase all the commits on top of master you
>> > are
>> > > > > >> changing
>> > > > > >> >

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

Could you upload the picture somewhere please? HTML is being stripped out
on email lists.

Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:

> There is an option in the repo settings menu to disable or enable
> merge-commit for PR, see a screenshot below (from a different github
> project):
>
> [image: image.png]
>
> My guess is that this is disabled for the reason to avoid creating
> non-linear history for standard PRs (as oppose to technical problem). But
> this is only my guess, it would be great if someone could confirm.
>
> Best,
> Chiyuan
>
> On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  wrote:
>
>> I believe so, but if someone wants to confirm it would be great.
>> Unfortunately, I just came down with a cold/flu so I will be out of
>> communication for a bit
>>
>> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>>  wrote:
>>
>> > Are we sure that this is due to lacking permissions and not because of
>> some
>> > technical limitation? If we are certain, we can ask out mentors to
>> create a
>> > ticket with Apache Infra to make that switch.
>> >
>> > -Marco
>> >
>> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
>> 01:17:
>> >
>> > > I made a test regular merge commit into a copy of master. It seemed
>> to go
>> > > fine. Here is a listing of what it will look like for everyone.
>> > >
>> > >
>> >
>> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
>> > >
>> > > Although, I would be happy to push the merge button. I think the most
>> > > important thing is to get the PR merged, so whatever way is the best
>> to
>> > > make that happen, let's do it.
>> > >
>> > > So - Does the regular merge seem like a good option?
>> > > If so, what is the best way to make that happen?
>> > >
>> > >
>> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
>> wrote:
>> > >
>> > > > Agreed with Pedro. Maybe the merge-commit option from the github
>> > > interface
>> > > > was disabled for a reason. But as Pedro said, maybe it is good to
>> > > > temporarily enable it for this PR and merge using that.
>> > > >
>> > > >
>> > > >- It should be technically easier than rebasing due to the
>> > > >git-subtree-import issue we are currently having
>> > > >- It also avoid stacking a huge commit history on *top* of
>> current
>> > > >history
>> > > >- The downside is probably the history of the project is not
>> linear
>> > > >anymore, but I think this is actually what we would like to have
>> for
>> > > > this
>> > > >particular case, because the contents of the main repo and the
>> julia
>> > > > branch
>> > > >actually does not overlap. So it makes sense to have two tails
>> with
>> > > > their
>> > > >own history.
>> > > >
>> > > > Carin: I guess if someone with admin permission on the github could
>> > > > temporarily enable the merge-commit option, then pushing the button
>> on
>> > > the
>> > > > web might simply work.
>> > > >
>> > > > Best,
>> > > > Chiyuan
>> > > >
>> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
>> > > wrote:
>> > > >
>> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
>> > > > originally
>> > > > > ruled it out since it wasn't an option in the github web
>> interface,
>> > but
>> > > > > since this looks like it is going to have to be done outside it
>> > because
>> > > > of
>> > > > > the subtrees anyway, it might be a better fit.
>> > > > >
>> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier > >
>> > > > wrote:
>> > > > >
>> > > > > > We are actually running into troubles with using the subtree and
>> > the
>> > > > > > rebase. Since it looks like this is not going to be a simple,
>> > "click
>> > > > the
>> > > > > > button" through the web page merge, I rather hand this task off
>> to
>> > > > > someone
>> > > > > > with more context in making sure it gets in there correctly.
>> > > > > >
>> > > > > > Chiyuan or any others, would you be willing to take this over?
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Carin
>> > > > > >
>> > > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy <
>> mnnav...@gmail.com>
>> > > > wrote:
>> > > > > >
>> > > > > >> Should we try to first being into a branch and then try merge
>> that
>> > > > > >> branch?
>> > > > > >>
>> > > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
>> > > > > pedro.larroy.li...@gmail.com>
>> > > > > >> wrote:
>> > > > > >> >
>> > > > > >> > I'm not familiar with the specifics of this contribution, as
>> a
>> > > > general
>> > > > > >> > approach my understanding is that if the list of commits is
>> big
>> > > and
>> > > > > you
>> > > > > >> > want to preserve history, usually merging is better so you
>> keep
>> > > > > history
>> > > > > >> and
>> > > > > >> > causality, if you rebase all the commits on top of master you
>> > are
>> > > > > >> changing
>> > > > > >> > the history of these commits which can't be individually
>> > reverted
>> > > as
>> > > > > >> some
>> > > > > >> > have suggested before. Maybe is because I come from a
>> mer

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

We can also request Infra directly to execute an override action on our
behalf - that way, they don't have to change the configuration and it
creates less work for them. That's something they did for us back then when
we switched CI. If we are all aligned, it shouldn't be a big deal for them
to just execute it.

Could we maybe have a dry run on a test repository to show everyone what
the outcome would look like?

Best regards,
Marco

Naveen Swamy  schrieb am So., 30. Sep. 2018, 03:49:

> yes, AFAIK I think Apache Infra has disabled the merge option.
>
> If there is a valid reason(and this is one), we could ask our Mentors to
> help us create a INFRA ticket to temporarily enable this option and once we
> are done merging we can request to disable it again.
>
> On Sat, Sep 29, 2018 at 9:44 PM Chiyuan Zhang  wrote:
>
> > There is an option in the repo settings menu to disable or enable
> > merge-commit for PR, see a screenshot below (from a different github
> > project):
> >
> > [image: image.png]
> >
> > My guess is that this is disabled for the reason to avoid creating
> > non-linear history for standard PRs (as oppose to technical problem). But
> > this is only my guess, it would be great if someone could confirm.
> >
> > Best,
> > Chiyuan
> >
> > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> wrote:
> >
> >> I believe so, but if someone wants to confirm it would be great.
> >> Unfortunately, I just came down with a cold/flu so I will be out of
> >> communication for a bit
> >>
> >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> >>  wrote:
> >>
> >> > Are we sure that this is due to lacking permissions and not because of
> >> some
> >> > technical limitation? If we are certain, we can ask out mentors to
> >> create a
> >> > ticket with Apache Infra to make that switch.
> >> >
> >> > -Marco
> >> >
> >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
> >> 01:17:
> >> >
> >> > > I made a test regular merge commit into a copy of master. It seemed
> >> to go
> >> > > fine. Here is a listing of what it will look like for everyone.
> >> > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >> > >
> >> > > Although, I would be happy to push the merge button. I think the
> most
> >> > > important thing is to get the PR merged, so whatever way is the best
> >> to
> >> > > make that happen, let's do it.
> >> > >
> >> > > So - Does the regular merge seem like a good option?
> >> > > If so, what is the best way to make that happen?
> >> > >
> >> > >
> >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> >> wrote:
> >> > >
> >> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> >> > > interface
> >> > > > was disabled for a reason. But as Pedro said, maybe it is good to
> >> > > > temporarily enable it for this PR and merge using that.
> >> > > >
> >> > > >
> >> > > >- It should be technically easier than rebasing due to the
> >> > > >git-subtree-import issue we are currently having
> >> > > >- It also avoid stacking a huge commit history on *top* of
> >> current
> >> > > >history
> >> > > >- The downside is probably the history of the project is not
> >> linear
> >> > > >anymore, but I think this is actually what we would like to
> have
> >> for
> >> > > > this
> >> > > >particular case, because the contents of the main repo and the
> >> julia
> >> > > > branch
> >> > > >actually does not overlap. So it makes sense to have two tails
> >> with
> >> > > > their
> >> > > >own history.
> >> > > >
> >> > > > Carin: I guess if someone with admin permission on the github
> could
> >> > > > temporarily enable the merge-commit option, then pushing the
> button
> >> on
> >> > > the
> >> > > > web might simply work.
> >> > > >
> >> > > > Best,
> >> > > > Chiyuan
> >> > > >
> >> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  >
> >> > > wrote:
> >> > > >
> >> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
> >> > > > originally
> >> > > > > ruled it out since it wasn't an option in the github web
> >> interface,
> >> > but
> >> > > > > since this looks like it is going to have to be done outside it
> >> > because
> >> > > > of
> >> > > > > the subtrees anyway, it might be a better fit.
> >> > > > >
> >> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier <
> carinme...@gmail.com
> >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > We are actually running into troubles with using the subtree
> and
> >> > the
> >> > > > > > rebase. Since it looks like this is not going to be a simple,
> >> > "click
> >> > > > the
> >> > > > > > button" through the web page merge, I rather hand this task
> off
> >> to
> >> > > > > someone
> >> > > > > > with more context in making sure it gets in there correctly.
> >> > > > > >
> >> > > > > > Chiyuan or any others, would you be willing to take this over?
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Carin
> >> > > > > >
> >> > > > > > On Fri, Sep 28, 2018 at 

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

Sorry, here is the image: https://imgur.com/V5wd2XB

And here is the github document on the 3 different merge options for the
web UI button: https://help.github.com/articles/about-pull-request-merges/

On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
 wrote:

> Could you upload the picture somewhere please? HTML is being stripped out
> on email lists.
>
> Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
>
> > There is an option in the repo settings menu to disable or enable
> > merge-commit for PR, see a screenshot below (from a different github
> > project):
> >
> > [image: image.png]
> >
> > My guess is that this is disabled for the reason to avoid creating
> > non-linear history for standard PRs (as oppose to technical problem). But
> > this is only my guess, it would be great if someone could confirm.
> >
> > Best,
> > Chiyuan
> >
> > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> wrote:
> >
> >> I believe so, but if someone wants to confirm it would be great.
> >> Unfortunately, I just came down with a cold/flu so I will be out of
> >> communication for a bit
> >>
> >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> >>  wrote:
> >>
> >> > Are we sure that this is due to lacking permissions and not because of
> >> some
> >> > technical limitation? If we are certain, we can ask out mentors to
> >> create a
> >> > ticket with Apache Infra to make that switch.
> >> >
> >> > -Marco
> >> >
> >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
> >> 01:17:
> >> >
> >> > > I made a test regular merge commit into a copy of master. It seemed
> >> to go
> >> > > fine. Here is a listing of what it will look like for everyone.
> >> > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >> > >
> >> > > Although, I would be happy to push the merge button. I think the
> most
> >> > > important thing is to get the PR merged, so whatever way is the best
> >> to
> >> > > make that happen, let's do it.
> >> > >
> >> > > So - Does the regular merge seem like a good option?
> >> > > If so, what is the best way to make that happen?
> >> > >
> >> > >
> >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> >> wrote:
> >> > >
> >> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> >> > > interface
> >> > > > was disabled for a reason. But as Pedro said, maybe it is good to
> >> > > > temporarily enable it for this PR and merge using that.
> >> > > >
> >> > > >
> >> > > >- It should be technically easier than rebasing due to the
> >> > > >git-subtree-import issue we are currently having
> >> > > >- It also avoid stacking a huge commit history on *top* of
> >> current
> >> > > >history
> >> > > >- The downside is probably the history of the project is not
> >> linear
> >> > > >anymore, but I think this is actually what we would like to
> have
> >> for
> >> > > > this
> >> > > >particular case, because the contents of the main repo and the
> >> julia
> >> > > > branch
> >> > > >actually does not overlap. So it makes sense to have two tails
> >> with
> >> > > > their
> >> > > >own history.
> >> > > >
> >> > > > Carin: I guess if someone with admin permission on the github
> could
> >> > > > temporarily enable the merge-commit option, then pushing the
> button
> >> on
> >> > > the
> >> > > > web might simply work.
> >> > > >
> >> > > > Best,
> >> > > > Chiyuan
> >> > > >
> >> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  >
> >> > > wrote:
> >> > > >
> >> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
> >> > > > originally
> >> > > > > ruled it out since it wasn't an option in the github web
> >> interface,
> >> > but
> >> > > > > since this looks like it is going to have to be done outside it
> >> > because
> >> > > > of
> >> > > > > the subtrees anyway, it might be a better fit.
> >> > > > >
> >> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier <
> carinme...@gmail.com
> >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > We are actually running into troubles with using the subtree
> and
> >> > the
> >> > > > > > rebase. Since it looks like this is not going to be a simple,
> >> > "click
> >> > > > the
> >> > > > > > button" through the web page merge, I rather hand this task
> off
> >> to
> >> > > > > someone
> >> > > > > > with more context in making sure it gets in there correctly.
> >> > > > > >
> >> > > > > > Chiyuan or any others, would you be willing to take this over?
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Carin
> >> > > > > >
> >> > > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy <
> >> mnnav...@gmail.com>
> >> > > > wrote:
> >> > > > > >
> >> > > > > >> Should we try to first being into a branch and then try merge
> >> that
> >> > > > > >> branch?
> >> > > > > >>
> >> > > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> >> > > > > pedro.larroy.li...@gmail.com>
> >> > > > > >> wrote:
> >> > > > > >> >
> >> > > > > >> > I'm not familiar with the specifics of thi

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Marco - Thanks for the "dry run" idea. It will give everyone a clear idea
of the process and what the expected results will look like.

- I took my fork of the repo and synced my master branch.
- @iblis17 made a copy of the branch of the Julia import PR and submitted
it to my repo
- I merged it with the "Merge" option through the web interface.

Here is a gif of the process of merging: http://g.recordit.co/DzBcFtnjmV.gif
Here is the result of the repo: https://github.com/gigasquid/incubator-mxnet

Please everyone take a look and validate that this looks ok.

If there are no objections, Marco - could you please take the lead in
requesting the actions from INFRA?

It will be great to *finally* get this PR in  :)

Thanks,
Carin





On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang  wrote:

> Sorry, here is the image: https://imgur.com/V5wd2XB
>
> And here is the github document on the 3 different merge options for the
> web UI button: https://help.github.com/articles/about-pull-request-merges/
>
> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
>  wrote:
>
> > Could you upload the picture somewhere please? HTML is being stripped out
> > on email lists.
> >
> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
> >
> > > There is an option in the repo settings menu to disable or enable
> > > merge-commit for PR, see a screenshot below (from a different github
> > > project):
> > >
> > > [image: image.png]
> > >
> > > My guess is that this is disabled for the reason to avoid creating
> > > non-linear history for standard PRs (as oppose to technical problem).
> But
> > > this is only my guess, it would be great if someone could confirm.
> > >
> > > Best,
> > > Chiyuan
> > >
> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> > wrote:
> > >
> > >> I believe so, but if someone wants to confirm it would be great.
> > >> Unfortunately, I just came down with a cold/flu so I will be out of
> > >> communication for a bit
> > >>
> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > >>  wrote:
> > >>
> > >> > Are we sure that this is due to lacking permissions and not because
> of
> > >> some
> > >> > technical limitation? If we are certain, we can ask out mentors to
> > >> create a
> > >> > ticket with Apache Infra to make that switch.
> > >> >
> > >> > -Marco
> > >> >
> > >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
> > >> 01:17:
> > >> >
> > >> > > I made a test regular merge commit into a copy of master. It
> seemed
> > >> to go
> > >> > > fine. Here is a listing of what it will look like for everyone.
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > >> > >
> > >> > > Although, I would be happy to push the merge button. I think the
> > most
> > >> > > important thing is to get the PR merged, so whatever way is the
> best
> > >> to
> > >> > > make that happen, let's do it.
> > >> > >
> > >> > > So - Does the regular merge seem like a good option?
> > >> > > If so, what is the best way to make that happen?
> > >> > >
> > >> > >
> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> > >> wrote:
> > >> > >
> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> > >> > > interface
> > >> > > > was disabled for a reason. But as Pedro said, maybe it is good
> to
> > >> > > > temporarily enable it for this PR and merge using that.
> > >> > > >
> > >> > > >
> > >> > > >- It should be technically easier than rebasing due to the
> > >> > > >git-subtree-import issue we are currently having
> > >> > > >- It also avoid stacking a huge commit history on *top* of
> > >> current
> > >> > > >history
> > >> > > >- The downside is probably the history of the project is not
> > >> linear
> > >> > > >anymore, but I think this is actually what we would like to
> > have
> > >> for
> > >> > > > this
> > >> > > >particular case, because the contents of the main repo and
> the
> > >> julia
> > >> > > > branch
> > >> > > >actually does not overlap. So it makes sense to have two
> tails
> > >> with
> > >> > > > their
> > >> > > >own history.
> > >> > > >
> > >> > > > Carin: I guess if someone with admin permission on the github
> > could
> > >> > > > temporarily enable the merge-commit option, then pushing the
> > button
> > >> on
> > >> > > the
> > >> > > > web might simply work.
> > >> > > >
> > >> > > > Best,
> > >> > > > Chiyuan
> > >> > > >
> > >> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier <
> carinme...@gmail.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > > Pedro - Maybe a merge commit is a better answer in this case.
> I
> > >> > > > originally
> > >> > > > > ruled it out since it wasn't an option in the github web
> > >> interface,
> > >> > but
> > >> > > > > since this looks like it is going to have to be done outside
> it
> > >> > because
> > >> > > > of
> > >> > > > > the subtrees anyway, it might be a better 

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

I just found out that since we are a podling, we should route all our Infra
tickets through one of our mentors and link the dev list discussion in JIRA.

Is there a mentor that is willing to help us navigate this process to get
the PR merged?

Thanks,
Carin

On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  wrote:

> Marco - Thanks for the "dry run" idea. It will give everyone a clear idea
> of the process and what the expected results will look like.
>
> - I took my fork of the repo and synced my master branch.
> - @iblis17 made a copy of the branch of the Julia import PR and submitted
> it to my repo
> - I merged it with the "Merge" option through the web interface.
>
> Here is a gif of the process of merging:
> http://g.recordit.co/DzBcFtnjmV.gif
> Here is the result of the repo:
> https://github.com/gigasquid/incubator-mxnet
>
> Please everyone take a look and validate that this looks ok.
>
> If there are no objections, Marco - could you please take the lead in
> requesting the actions from INFRA?
>
> It will be great to *finally* get this PR in  :)
>
> Thanks,
> Carin
>
> 
>
>
>
> On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang  wrote:
>
>> Sorry, here is the image: https://imgur.com/V5wd2XB
>>
>> And here is the github document on the 3 different merge options for the
>> web UI button:
>> https://help.github.com/articles/about-pull-request-merges/
>>
>> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
>>  wrote:
>>
>> > Could you upload the picture somewhere please? HTML is being stripped
>> out
>> > on email lists.
>> >
>> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
>> >
>> > > There is an option in the repo settings menu to disable or enable
>> > > merge-commit for PR, see a screenshot below (from a different github
>> > > project):
>> > >
>> > > [image: image.png]
>> > >
>> > > My guess is that this is disabled for the reason to avoid creating
>> > > non-linear history for standard PRs (as oppose to technical problem).
>> But
>> > > this is only my guess, it would be great if someone could confirm.
>> > >
>> > > Best,
>> > > Chiyuan
>> > >
>> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
>> > wrote:
>> > >
>> > >> I believe so, but if someone wants to confirm it would be great.
>> > >> Unfortunately, I just came down with a cold/flu so I will be out of
>> > >> communication for a bit
>> > >>
>> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>> > >>  wrote:
>> > >>
>> > >> > Are we sure that this is due to lacking permissions and not
>> because of
>> > >> some
>> > >> > technical limitation? If we are certain, we can ask out mentors to
>> > >> create a
>> > >> > ticket with Apache Infra to make that switch.
>> > >> >
>> > >> > -Marco
>> > >> >
>> > >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
>> > >> 01:17:
>> > >> >
>> > >> > > I made a test regular merge commit into a copy of master. It
>> seemed
>> > >> to go
>> > >> > > fine. Here is a listing of what it will look like for everyone.
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
>> > >> > >
>> > >> > > Although, I would be happy to push the merge button. I think the
>> > most
>> > >> > > important thing is to get the PR merged, so whatever way is the
>> best
>> > >> to
>> > >> > > make that happen, let's do it.
>> > >> > >
>> > >> > > So - Does the regular merge seem like a good option?
>> > >> > > If so, what is the best way to make that happen?
>> > >> > >
>> > >> > >
>> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang > >
>> > >> wrote:
>> > >> > >
>> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the
>> github
>> > >> > > interface
>> > >> > > > was disabled for a reason. But as Pedro said, maybe it is good
>> to
>> > >> > > > temporarily enable it for this PR and merge using that.
>> > >> > > >
>> > >> > > >
>> > >> > > >- It should be technically easier than rebasing due to the
>> > >> > > >git-subtree-import issue we are currently having
>> > >> > > >- It also avoid stacking a huge commit history on *top* of
>> > >> current
>> > >> > > >history
>> > >> > > >- The downside is probably the history of the project is not
>> > >> linear
>> > >> > > >anymore, but I think this is actually what we would like to
>> > have
>> > >> for
>> > >> > > > this
>> > >> > > >particular case, because the contents of the main repo and
>> the
>> > >> julia
>> > >> > > > branch
>> > >> > > >actually does not overlap. So it makes sense to have two
>> tails
>> > >> with
>> > >> > > > their
>> > >> > > >own history.
>> > >> > > >
>> > >> > > > Carin: I guess if someone with admin permission on the github
>> > could
>> > >> > > > temporarily enable the merge-commit option, then pushing the
>> > button
>> > >> on
>> > >> > > the
>> > >> > > > web might simply work.
>> > >> > > >
>> > >> > > > Best,
>> > >> > > > Chiyuan
>> > >> > > >
>> > >> > > > O

Re: Which merge option to use on the Import Julia binding PR?

[Michael Wall]

Hi Carin,

I will take a look at this tonight.  I am not tracking everything, so I
want to go back and make sure I understand what is being asked.  Then I am
happy to submit an INFRA ticket.

Mike

On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  wrote:

> I just found out that since we are a podling, we should route all our Infra
> tickets through one of our mentors and link the dev list discussion in
> JIRA.
>
> Is there a mentor that is willing to help us navigate this process to get
> the PR merged?
>
> Thanks,
> Carin
>
> On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  wrote:
>
> > Marco - Thanks for the "dry run" idea. It will give everyone a clear idea
> > of the process and what the expected results will look like.
> >
> > - I took my fork of the repo and synced my master branch.
> > - @iblis17 made a copy of the branch of the Julia import PR and submitted
> > it to my repo
> > - I merged it with the "Merge" option through the web interface.
> >
> > Here is a gif of the process of merging:
> > http://g.recordit.co/DzBcFtnjmV.gif
> > Here is the result of the repo:
> > https://github.com/gigasquid/incubator-mxnet
> >
> > Please everyone take a look and validate that this looks ok.
> >
> > If there are no objections, Marco - could you please take the lead in
> > requesting the actions from INFRA?
> >
> > It will be great to *finally* get this PR in  :)
> >
> > Thanks,
> > Carin
> >
> > 
> >
> >
> >
> > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> wrote:
> >
> >> Sorry, here is the image: https://imgur.com/V5wd2XB
> >>
> >> And here is the github document on the 3 different merge options for the
> >> web UI button:
> >> https://help.github.com/articles/about-pull-request-merges/
> >>
> >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> >>  wrote:
> >>
> >> > Could you upload the picture somewhere please? HTML is being stripped
> >> out
> >> > on email lists.
> >> >
> >> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018,
> 03:44:
> >> >
> >> > > There is an option in the repo settings menu to disable or enable
> >> > > merge-commit for PR, see a screenshot below (from a different github
> >> > > project):
> >> > >
> >> > > [image: image.png]
> >> > >
> >> > > My guess is that this is disabled for the reason to avoid creating
> >> > > non-linear history for standard PRs (as oppose to technical
> problem).
> >> But
> >> > > this is only my guess, it would be great if someone could confirm.
> >> > >
> >> > > Best,
> >> > > Chiyuan
> >> > >
> >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> >> > wrote:
> >> > >
> >> > >> I believe so, but if someone wants to confirm it would be great.
> >> > >> Unfortunately, I just came down with a cold/flu so I will be out of
> >> > >> communication for a bit
> >> > >>
> >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> >> > >>  wrote:
> >> > >>
> >> > >> > Are we sure that this is due to lacking permissions and not
> >> because of
> >> > >> some
> >> > >> > technical limitation? If we are certain, we can ask out mentors
> to
> >> > >> create a
> >> > >> > ticket with Apache Infra to make that switch.
> >> > >> >
> >> > >> > -Marco
> >> > >> >
> >> > >> > Carin Meier  schrieb am Sa., 29. Sep.
> 2018,
> >> > >> 01:17:
> >> > >> >
> >> > >> > > I made a test regular merge commit into a copy of master. It
> >> seemed
> >> > >> to go
> >> > >> > > fine. Here is a listing of what it will look like for everyone.
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >> > >> > >
> >> > >> > > Although, I would be happy to push the merge button. I think
> the
> >> > most
> >> > >> > > important thing is to get the PR merged, so whatever way is the
> >> best
> >> > >> to
> >> > >> > > make that happen, let's do it.
> >> > >> > >
> >> > >> > > So - Does the regular merge seem like a good option?
> >> > >> > > If so, what is the best way to make that happen?
> >> > >> > >
> >> > >> > >
> >> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang <
> plus...@gmail.com
> >> >
> >> > >> wrote:
> >> > >> > >
> >> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the
> >> github
> >> > >> > > interface
> >> > >> > > > was disabled for a reason. But as Pedro said, maybe it is
> good
> >> to
> >> > >> > > > temporarily enable it for this PR and merge using that.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >- It should be technically easier than rebasing due to the
> >> > >> > > >git-subtree-import issue we are currently having
> >> > >> > > >- It also avoid stacking a huge commit history on *top* of
> >> > >> current
> >> > >> > > >history
> >> > >> > > >- The downside is probably the history of the project is
> not
> >> > >> linear
> >> > >> > > >anymore, but I think this is actually what we would like
> to
> >> > have
> >> > >> for
> >> > >> > > > this
> >> > >> > > >particular case, be

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Thank you Mike!

On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:

> Hi Carin,
>
> I will take a look at this tonight.  I am not tracking everything, so I
> want to go back and make sure I understand what is being asked.  Then I am
> happy to submit an INFRA ticket.
>
> Mike
>
> On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  wrote:
>
> > I just found out that since we are a podling, we should route all our
> Infra
> > tickets through one of our mentors and link the dev list discussion in
> > JIRA.
> >
> > Is there a mentor that is willing to help us navigate this process to get
> > the PR merged?
> >
> > Thanks,
> > Carin
> >
> > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  wrote:
> >
> > > Marco - Thanks for the "dry run" idea. It will give everyone a clear
> idea
> > > of the process and what the expected results will look like.
> > >
> > > - I took my fork of the repo and synced my master branch.
> > > - @iblis17 made a copy of the branch of the Julia import PR and
> submitted
> > > it to my repo
> > > - I merged it with the "Merge" option through the web interface.
> > >
> > > Here is a gif of the process of merging:
> > > http://g.recordit.co/DzBcFtnjmV.gif
> > > Here is the result of the repo:
> > > https://github.com/gigasquid/incubator-mxnet
> > >
> > > Please everyone take a look and validate that this looks ok.
> > >
> > > If there are no objections, Marco - could you please take the lead in
> > > requesting the actions from INFRA?
> > >
> > > It will be great to *finally* get this PR in  :)
> > >
> > > Thanks,
> > > Carin
> > >
> > > 
> > >
> > >
> > >
> > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> > wrote:
> > >
> > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > >>
> > >> And here is the github document on the 3 different merge options for
> the
> > >> web UI button:
> > >> https://help.github.com/articles/about-pull-request-merges/
> > >>
> > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > >>  wrote:
> > >>
> > >> > Could you upload the picture somewhere please? HTML is being
> stripped
> > >> out
> > >> > on email lists.
> > >> >
> > >> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018,
> > 03:44:
> > >> >
> > >> > > There is an option in the repo settings menu to disable or enable
> > >> > > merge-commit for PR, see a screenshot below (from a different
> github
> > >> > > project):
> > >> > >
> > >> > > [image: image.png]
> > >> > >
> > >> > > My guess is that this is disabled for the reason to avoid creating
> > >> > > non-linear history for standard PRs (as oppose to technical
> > problem).
> > >> But
> > >> > > this is only my guess, it would be great if someone could confirm.
> > >> > >
> > >> > > Best,
> > >> > > Chiyuan
> > >> > >
> > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  >
> > >> > wrote:
> > >> > >
> > >> > >> I believe so, but if someone wants to confirm it would be great.
> > >> > >> Unfortunately, I just came down with a cold/flu so I will be out
> of
> > >> > >> communication for a bit
> > >> > >>
> > >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > >> > >>  wrote:
> > >> > >>
> > >> > >> > Are we sure that this is due to lacking permissions and not
> > >> because of
> > >> > >> some
> > >> > >> > technical limitation? If we are certain, we can ask out mentors
> > to
> > >> > >> create a
> > >> > >> > ticket with Apache Infra to make that switch.
> > >> > >> >
> > >> > >> > -Marco
> > >> > >> >
> > >> > >> > Carin Meier  schrieb am Sa., 29. Sep.
> > 2018,
> > >> > >> 01:17:
> > >> > >> >
> > >> > >> > > I made a test regular merge commit into a copy of master. It
> > >> seemed
> > >> > >> to go
> > >> > >> > > fine. Here is a listing of what it will look like for
> everyone.
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > >> > >> > >
> > >> > >> > > Although, I would be happy to push the merge button. I think
> > the
> > >> > most
> > >> > >> > > important thing is to get the PR merged, so whatever way is
> the
> > >> best
> > >> > >> to
> > >> > >> > > make that happen, let's do it.
> > >> > >> > >
> > >> > >> > > So - Does the regular merge seem like a good option?
> > >> > >> > > If so, what is the best way to make that happen?
> > >> > >> > >
> > >> > >> > >
> > >> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang <
> > plus...@gmail.com
> > >> >
> > >> > >> wrote:
> > >> > >> > >
> > >> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the
> > >> github
> > >> > >> > > interface
> > >> > >> > > > was disabled for a reason. But as Pedro said, maybe it is
> > good
> > >> to
> > >> > >> > > > temporarily enable it for this PR and merge using that.
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >- It should be technically easier than rebasing due to
> the
> > >> > >> > > >git-subtree-import issue we are currently having
> > 

Re: Which merge option to use on the Import Julia binding PR?

[Michael Wall]

Just now looking at this.  The button is disabled for merge commit as you
have mentioned.  Before I go to INFRA, is the command line an option?  Do
you see "or view command line instructions" beside the green squash and
merge button?

On Thu, Oct 4, 2018 at 9:09 AM Carin Meier  wrote:

> Thank you Mike!
>
> On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:
>
> > Hi Carin,
> >
> > I will take a look at this tonight.  I am not tracking everything, so I
> > want to go back and make sure I understand what is being asked.  Then I
> am
> > happy to submit an INFRA ticket.
> >
> > Mike
> >
> > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  wrote:
> >
> > > I just found out that since we are a podling, we should route all our
> > Infra
> > > tickets through one of our mentors and link the dev list discussion in
> > > JIRA.
> > >
> > > Is there a mentor that is willing to help us navigate this process to
> get
> > > the PR merged?
> > >
> > > Thanks,
> > > Carin
> > >
> > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier 
> wrote:
> > >
> > > > Marco - Thanks for the "dry run" idea. It will give everyone a clear
> > idea
> > > > of the process and what the expected results will look like.
> > > >
> > > > - I took my fork of the repo and synced my master branch.
> > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > submitted
> > > > it to my repo
> > > > - I merged it with the "Merge" option through the web interface.
> > > >
> > > > Here is a gif of the process of merging:
> > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > Here is the result of the repo:
> > > > https://github.com/gigasquid/incubator-mxnet
> > > >
> > > > Please everyone take a look and validate that this looks ok.
> > > >
> > > > If there are no objections, Marco - could you please take the lead in
> > > > requesting the actions from INFRA?
> > > >
> > > > It will be great to *finally* get this PR in  :)
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > > >  >
> > > >
> > > >
> > > >
> > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> > > wrote:
> > > >
> > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > >>
> > > >> And here is the github document on the 3 different merge options for
> > the
> > > >> web UI button:
> > > >> https://help.github.com/articles/about-pull-request-merges/
> > > >>
> > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > >>  wrote:
> > > >>
> > > >> > Could you upload the picture somewhere please? HTML is being
> > stripped
> > > >> out
> > > >> > on email lists.
> > > >> >
> > > >> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018,
> > > 03:44:
> > > >> >
> > > >> > > There is an option in the repo settings menu to disable or
> enable
> > > >> > > merge-commit for PR, see a screenshot below (from a different
> > github
> > > >> > > project):
> > > >> > >
> > > >> > > [image: image.png]
> > > >> > >
> > > >> > > My guess is that this is disabled for the reason to avoid
> creating
> > > >> > > non-linear history for standard PRs (as oppose to technical
> > > problem).
> > > >> But
> > > >> > > this is only my guess, it would be great if someone could
> confirm.
> > > >> > >
> > > >> > > Best,
> > > >> > > Chiyuan
> > > >> > >
> > > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier <
> carinme...@gmail.com
> > >
> > > >> > wrote:
> > > >> > >
> > > >> > >> I believe so, but if someone wants to confirm it would be
> great.
> > > >> > >> Unfortunately, I just came down with a cold/flu so I will be
> out
> > of
> > > >> > >> communication for a bit
> > > >> > >>
> > > >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > > >> > >>  wrote:
> > > >> > >>
> > > >> > >> > Are we sure that this is due to lacking permissions and not
> > > >> because of
> > > >> > >> some
> > > >> > >> > technical limitation? If we are certain, we can ask out
> mentors
> > > to
> > > >> > >> create a
> > > >> > >> > ticket with Apache Infra to make that switch.
> > > >> > >> >
> > > >> > >> > -Marco
> > > >> > >> >
> > > >> > >> > Carin Meier  schrieb am Sa., 29. Sep.
> > > 2018,
> > > >> > >> 01:17:
> > > >> > >> >
> > > >> > >> > > I made a test regular merge commit into a copy of master.
> It
> > > >> seemed
> > > >> > >> to go
> > > >> > >> > > fine. Here is a listing of what it will look like for
> > everyone.
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > > >> > >> > >
> > > >> > >> > > Although, I would be happy to push the merge button. I
> think
> > > the
> > > >> > most
> > > >> > >> > > important thing is to get the PR merged, so whatever way is
> > the
> > > >> best
> > > >> > >> to
> > > >> > >> > > make that happen, let's do it.
> > > >> > >> > >
> > > >> > >> > > So - Does the regular merge seem like a good option?
> > > >> > >> > > If so, what is the best way to make that happen?
> > > >> > >>

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Micheal,

Thanks for catching up and helping us with this.
I do see the "view command line instructions". I just assumed that master
was a protected branch and I would not be able to push to it.
Honestly, I'm a bit scared if it isn't :)

What do you suggest? Should I try to merge and push to master?

On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:

> Just now looking at this.  The button is disabled for merge commit as you
> have mentioned.  Before I go to INFRA, is the command line an option?  Do
> you see "or view command line instructions" beside the green squash and
> merge button?
>
> On Thu, Oct 4, 2018 at 9:09 AM Carin Meier  wrote:
>
> > Thank you Mike!
> >
> > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:
> >
> > > Hi Carin,
> > >
> > > I will take a look at this tonight.  I am not tracking everything, so I
> > > want to go back and make sure I understand what is being asked.  Then I
> > am
> > > happy to submit an INFRA ticket.
> > >
> > > Mike
> > >
> > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier 
> wrote:
> > >
> > > > I just found out that since we are a podling, we should route all our
> > > Infra
> > > > tickets through one of our mentors and link the dev list discussion
> in
> > > > JIRA.
> > > >
> > > > Is there a mentor that is willing to help us navigate this process to
> > get
> > > > the PR merged?
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier 
> > wrote:
> > > >
> > > > > Marco - Thanks for the "dry run" idea. It will give everyone a
> clear
> > > idea
> > > > > of the process and what the expected results will look like.
> > > > >
> > > > > - I took my fork of the repo and synced my master branch.
> > > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > > submitted
> > > > > it to my repo
> > > > > - I merged it with the "Merge" option through the web interface.
> > > > >
> > > > > Here is a gif of the process of merging:
> > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > Here is the result of the repo:
> > > > > https://github.com/gigasquid/incubator-mxnet
> > > > >
> > > > > Please everyone take a look and validate that this looks ok.
> > > > >
> > > > > If there are no objections, Marco - could you please take the lead
> in
> > > > > requesting the actions from INFRA?
> > > > >
> > > > > It will be great to *finally* get this PR in  :)
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > <
> https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> > > > wrote:
> > > > >
> > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > >>
> > > > >> And here is the github document on the 3 different merge options
> for
> > > the
> > > > >> web UI button:
> > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > >>
> > > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > > >>  wrote:
> > > > >>
> > > > >> > Could you upload the picture somewhere please? HTML is being
> > > stripped
> > > > >> out
> > > > >> > on email lists.
> > > > >> >
> > > > >> > Chiyuan Zhang  schrieb am So., 30. Sep.
> 2018,
> > > > 03:44:
> > > > >> >
> > > > >> > > There is an option in the repo settings menu to disable or
> > enable
> > > > >> > > merge-commit for PR, see a screenshot below (from a different
> > > github
> > > > >> > > project):
> > > > >> > >
> > > > >> > > [image: image.png]
> > > > >> > >
> > > > >> > > My guess is that this is disabled for the reason to avoid
> > creating
> > > > >> > > non-linear history for standard PRs (as oppose to technical
> > > > problem).
> > > > >> But
> > > > >> > > this is only my guess, it would be great if someone could
> > confirm.
> > > > >> > >
> > > > >> > > Best,
> > > > >> > > Chiyuan
> > > > >> > >
> > > > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier <
> > carinme...@gmail.com
> > > >
> > > > >> > wrote:
> > > > >> > >
> > > > >> > >> I believe so, but if someone wants to confirm it would be
> > great.
> > > > >> > >> Unfortunately, I just came down with a cold/flu so I will be
> > out
> > > of
> > > > >> > >> communication for a bit
> > > > >> > >>
> > > > >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > > > >> > >>  wrote:
> > > > >> > >>
> > > > >> > >> > Are we sure that this is due to lacking permissions and not
> > > > >> because of
> > > > >> > >> some
> > > > >> > >> > technical limitation? If we are certain, we can ask out
> > mentors
> > > > to
> > > > >> > >> create a
> > > > >> > >> > ticket with Apache Infra to make that switch.
> > > > >> > >> >
> > > > >> > >> > -Marco
> > > > >> > >> >
> > > > >> > >> > Carin Meier  schrieb am Sa., 29.
> Sep.
> > > > 2018,
> > > > >> > >> 01:17:
> > > > >> > >> >
> > > > >> > >> > > I made a test regular merge commit into a copy of master.
> > It
> > > > >> seemed
> > > > >> > >> to go
> > > > >> > >> > > fine. Here is a listing of what it will look l

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

You won't be able to push to master. The commit will be declined
automatically, so command line is not an option.

-Marco

Carin Meier  schrieb am Fr., 5. Okt. 2018, 01:29:

> Micheal,
>
> Thanks for catching up and helping us with this.
> I do see the "view command line instructions". I just assumed that master
> was a protected branch and I would not be able to push to it.
> Honestly, I'm a bit scared if it isn't :)
>
> What do you suggest? Should I try to merge and push to master?
>
> On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:
>
> > Just now looking at this.  The button is disabled for merge commit as you
> > have mentioned.  Before I go to INFRA, is the command line an option?  Do
> > you see "or view command line instructions" beside the green squash and
> > merge button?
> >
> > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier  wrote:
> >
> > > Thank you Mike!
> > >
> > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:
> > >
> > > > Hi Carin,
> > > >
> > > > I will take a look at this tonight.  I am not tracking everything,
> so I
> > > > want to go back and make sure I understand what is being asked.
> Then I
> > > am
> > > > happy to submit an INFRA ticket.
> > > >
> > > > Mike
> > > >
> > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier 
> > wrote:
> > > >
> > > > > I just found out that since we are a podling, we should route all
> our
> > > > Infra
> > > > > tickets through one of our mentors and link the dev list discussion
> > in
> > > > > JIRA.
> > > > >
> > > > > Is there a mentor that is willing to help us navigate this process
> to
> > > get
> > > > > the PR merged?
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier 
> > > wrote:
> > > > >
> > > > > > Marco - Thanks for the "dry run" idea. It will give everyone a
> > clear
> > > > idea
> > > > > > of the process and what the expected results will look like.
> > > > > >
> > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > > > submitted
> > > > > > it to my repo
> > > > > > - I merged it with the "Merge" option through the web interface.
> > > > > >
> > > > > > Here is a gif of the process of merging:
> > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > Here is the result of the repo:
> > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > >
> > > > > > Please everyone take a look and validate that this looks ok.
> > > > > >
> > > > > > If there are no objections, Marco - could you please take the
> lead
> > in
> > > > > > requesting the actions from INFRA?
> > > > > >
> > > > > > It will be great to *finally* get this PR in  :)
> > > > > >
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > > <
> > https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang <
> plus...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > >>
> > > > > >> And here is the github document on the 3 different merge options
> > for
> > > > the
> > > > > >> web UI button:
> > > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > > >>
> > > > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > > > >>  wrote:
> > > > > >>
> > > > > >> > Could you upload the picture somewhere please? HTML is being
> > > > stripped
> > > > > >> out
> > > > > >> > on email lists.
> > > > > >> >
> > > > > >> > Chiyuan Zhang  schrieb am So., 30. Sep.
> > 2018,
> > > > > 03:44:
> > > > > >> >
> > > > > >> > > There is an option in the repo settings menu to disable or
> > > enable
> > > > > >> > > merge-commit for PR, see a screenshot below (from a
> different
> > > > github
> > > > > >> > > project):
> > > > > >> > >
> > > > > >> > > [image: image.png]
> > > > > >> > >
> > > > > >> > > My guess is that this is disabled for the reason to avoid
> > > creating
> > > > > >> > > non-linear history for standard PRs (as oppose to technical
> > > > > problem).
> > > > > >> But
> > > > > >> > > this is only my guess, it would be great if someone could
> > > confirm.
> > > > > >> > >
> > > > > >> > > Best,
> > > > > >> > > Chiyuan
> > > > > >> > >
> > > > > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier <
> > > carinme...@gmail.com
> > > > >
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > >> I believe so, but if someone wants to confirm it would be
> > > great.
> > > > > >> > >> Unfortunately, I just came down with a cold/flu so I will
> be
> > > out
> > > > of
> > > > > >> > >> communication for a bit
> > > > > >> > >>
> > > > > >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > > > > >> > >>  wrote:
> > > > > >> > >>
> > > > > >> > >> > Are we sure that this is due to lacking permissions and
> not
> > > > > >> because of
> > > > > >> > >> some
> > > > > >> > >> > technical limitation? If we are certai

Re: Which merge option to use on the Import Julia binding PR?

[Michael Wall]

I would try the merge locally and then inspect the result closely to make
sure it looks like what you want.  If it looks good, you could try pushing
to master.  If you can't push, then we know but I "think" protected just
means you can't force push in this case based on
https://issues.apache.org/jira/browse/INFRA-15233 which links to
https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that with
repo that own though.

I did find at least one ticket where a team asked for merge commits to be
enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I think
they intend for it to stay that way.  Is that what the community would want
for the MXNet repo?  Or would you want to enable it for this and disable it
again?


On Thu, Oct 4, 2018 at 7:29 PM Carin Meier  wrote:

> Micheal,
>
> Thanks for catching up and helping us with this.
> I do see the "view command line instructions". I just assumed that master
> was a protected branch and I would not be able to push to it.
> Honestly, I'm a bit scared if it isn't :)
>
> What do you suggest? Should I try to merge and push to master?
>
> On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:
>
> > Just now looking at this.  The button is disabled for merge commit as you
> > have mentioned.  Before I go to INFRA, is the command line an option?  Do
> > you see "or view command line instructions" beside the green squash and
> > merge button?
> >
> > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier  wrote:
> >
> > > Thank you Mike!
> > >
> > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:
> > >
> > > > Hi Carin,
> > > >
> > > > I will take a look at this tonight.  I am not tracking everything,
> so I
> > > > want to go back and make sure I understand what is being asked.
> Then I
> > > am
> > > > happy to submit an INFRA ticket.
> > > >
> > > > Mike
> > > >
> > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier 
> > wrote:
> > > >
> > > > > I just found out that since we are a podling, we should route all
> our
> > > > Infra
> > > > > tickets through one of our mentors and link the dev list discussion
> > in
> > > > > JIRA.
> > > > >
> > > > > Is there a mentor that is willing to help us navigate this process
> to
> > > get
> > > > > the PR merged?
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier 
> > > wrote:
> > > > >
> > > > > > Marco - Thanks for the "dry run" idea. It will give everyone a
> > clear
> > > > idea
> > > > > > of the process and what the expected results will look like.
> > > > > >
> > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > > > submitted
> > > > > > it to my repo
> > > > > > - I merged it with the "Merge" option through the web interface.
> > > > > >
> > > > > > Here is a gif of the process of merging:
> > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > Here is the result of the repo:
> > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > >
> > > > > > Please everyone take a look and validate that this looks ok.
> > > > > >
> > > > > > If there are no objections, Marco - could you please take the
> lead
> > in
> > > > > > requesting the actions from INFRA?
> > > > > >
> > > > > > It will be great to *finally* get this PR in  :)
> > > > > >
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > > <
> > https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang <
> plus...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > >>
> > > > > >> And here is the github document on the 3 different merge options
> > for
> > > > the
> > > > > >> web UI button:
> > > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > > >>
> > > > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > > > >>  wrote:
> > > > > >>
> > > > > >> > Could you upload the picture somewhere please? HTML is being
> > > > stripped
> > > > > >> out
> > > > > >> > on email lists.
> > > > > >> >
> > > > > >> > Chiyuan Zhang  schrieb am So., 30. Sep.
> > 2018,
> > > > > 03:44:
> > > > > >> >
> > > > > >> > > There is an option in the repo settings menu to disable or
> > > enable
> > > > > >> > > merge-commit for PR, see a screenshot below (from a
> different
> > > > github
> > > > > >> > > project):
> > > > > >> > >
> > > > > >> > > [image: image.png]
> > > > > >> > >
> > > > > >> > > My guess is that this is disabled for the reason to avoid
> > > creating
> > > > > >> > > non-linear history for standard PRs (as oppose to technical
> > > > > problem).
> > > > > >> But
> > > > > >> > > this is only my guess, it would be great if someone could
> > > confirm.
> > > > > >> > >
> > > > > >> > > Best,
> > > > > >> > > Chiyuan
> > > > > >> > >
> > > > > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier <
> 

Re: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Micheal,

Thanks. You were right! I could merge.

The PR shows up now as merged
https://github.com/apache/incubator-mxnet/pull/10149
My merge commit is here
https://github.com/apache/incubator-mxnet/commits/master

Thanks again for the help.

- Carin



On Thu, Oct 4, 2018 at 8:09 PM Michael Wall  wrote:

> I would try the merge locally and then inspect the result closely to make
> sure it looks like what you want.  If it looks good, you could try pushing
> to master.  If you can't push, then we know but I "think" protected just
> means you can't force push in this case based on
> https://issues.apache.org/jira/browse/INFRA-15233 which links to
> https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that
> with
> repo that own though.
>
> I did find at least one ticket where a team asked for merge commits to be
> enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I think
> they intend for it to stay that way.  Is that what the community would want
> for the MXNet repo?  Or would you want to enable it for this and disable it
> again?
>
>
> On Thu, Oct 4, 2018 at 7:29 PM Carin Meier  wrote:
>
> > Micheal,
> >
> > Thanks for catching up and helping us with this.
> > I do see the "view command line instructions". I just assumed that master
> > was a protected branch and I would not be able to push to it.
> > Honestly, I'm a bit scared if it isn't :)
> >
> > What do you suggest? Should I try to merge and push to master?
> >
> > On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:
> >
> > > Just now looking at this.  The button is disabled for merge commit as
> you
> > > have mentioned.  Before I go to INFRA, is the command line an option?
> Do
> > > you see "or view command line instructions" beside the green squash and
> > > merge button?
> > >
> > > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier 
> wrote:
> > >
> > > > Thank you Mike!
> > > >
> > > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall 
> wrote:
> > > >
> > > > > Hi Carin,
> > > > >
> > > > > I will take a look at this tonight.  I am not tracking everything,
> > so I
> > > > > want to go back and make sure I understand what is being asked.
> > Then I
> > > > am
> > > > > happy to submit an INFRA ticket.
> > > > >
> > > > > Mike
> > > > >
> > > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier 
> > > wrote:
> > > > >
> > > > > > I just found out that since we are a podling, we should route all
> > our
> > > > > Infra
> > > > > > tickets through one of our mentors and link the dev list
> discussion
> > > in
> > > > > > JIRA.
> > > > > >
> > > > > > Is there a mentor that is willing to help us navigate this
> process
> > to
> > > > get
> > > > > > the PR merged?
> > > > > >
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  >
> > > > wrote:
> > > > > >
> > > > > > > Marco - Thanks for the "dry run" idea. It will give everyone a
> > > clear
> > > > > idea
> > > > > > > of the process and what the expected results will look like.
> > > > > > >
> > > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > > > > submitted
> > > > > > > it to my repo
> > > > > > > - I merged it with the "Merge" option through the web
> interface.
> > > > > > >
> > > > > > > Here is a gif of the process of merging:
> > > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > > Here is the result of the repo:
> > > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > > >
> > > > > > > Please everyone take a look and validate that this looks ok.
> > > > > > >
> > > > > > > If there are no objections, Marco - could you please take the
> > lead
> > > in
> > > > > > > requesting the actions from INFRA?
> > > > > > >
> > > > > > > It will be great to *finally* get this PR in  :)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Carin
> > > > > > >
> > > > > > > <
> > > https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang <
> > plus...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > > >>
> > > > > > >> And here is the github document on the 3 different merge
> options
> > > for
> > > > > the
> > > > > > >> web UI button:
> > > > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > > > >>
> > > > > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > > > > >>  wrote:
> > > > > > >>
> > > > > > >> > Could you upload the picture somewhere please? HTML is being
> > > > > stripped
> > > > > > >> out
> > > > > > >> > on email lists.
> > > > > > >> >
> > > > > > >> > Chiyuan Zhang  schrieb am So., 30. Sep.
> > > 2018,
> > > > > > 03:44:
> > > > > > >> >
> > > > > > >> > > There is an option in the repo settings menu to disable or
> > > > enable
> > > > > > >> > > merge-commit for PR, see a scre

Re: Which merge option to use on the Import Julia binding PR?

[Marco de Abreu]

Oh nice, great catch Michael and Carin! I just learned something new,
thanks :)

I guess we're all set then, right? Thanks a lot, everyone!

-Marco

Carin Meier  schrieb am Fr., 5. Okt. 2018, 02:47:

> Micheal,
>
> Thanks. You were right! I could merge.
>
> The PR shows up now as merged
> https://github.com/apache/incubator-mxnet/pull/10149
> My merge commit is here
> https://github.com/apache/incubator-mxnet/commits/master
>
> Thanks again for the help.
>
> - Carin
>
>
>
> On Thu, Oct 4, 2018 at 8:09 PM Michael Wall  wrote:
>
> > I would try the merge locally and then inspect the result closely to make
> > sure it looks like what you want.  If it looks good, you could try
> pushing
> > to master.  If you can't push, then we know but I "think" protected just
> > means you can't force push in this case based on
> > https://issues.apache.org/jira/browse/INFRA-15233 which links to
> > https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that
> > with
> > repo that own though.
> >
> > I did find at least one ticket where a team asked for merge commits to be
> > enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I think
> > they intend for it to stay that way.  Is that what the community would
> want
> > for the MXNet repo?  Or would you want to enable it for this and disable
> it
> > again?
> >
> >
> > On Thu, Oct 4, 2018 at 7:29 PM Carin Meier  wrote:
> >
> > > Micheal,
> > >
> > > Thanks for catching up and helping us with this.
> > > I do see the "view command line instructions". I just assumed that
> master
> > > was a protected branch and I would not be able to push to it.
> > > Honestly, I'm a bit scared if it isn't :)
> > >
> > > What do you suggest? Should I try to merge and push to master?
> > >
> > > On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:
> > >
> > > > Just now looking at this.  The button is disabled for merge commit as
> > you
> > > > have mentioned.  Before I go to INFRA, is the command line an option?
> > Do
> > > > you see "or view command line instructions" beside the green squash
> and
> > > > merge button?
> > > >
> > > > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier 
> > wrote:
> > > >
> > > > > Thank you Mike!
> > > > >
> > > > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall 
> > wrote:
> > > > >
> > > > > > Hi Carin,
> > > > > >
> > > > > > I will take a look at this tonight.  I am not tracking
> everything,
> > > so I
> > > > > > want to go back and make sure I understand what is being asked.
> > > Then I
> > > > > am
> > > > > > happy to submit an INFRA ticket.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  >
> > > > wrote:
> > > > > >
> > > > > > > I just found out that since we are a podling, we should route
> all
> > > our
> > > > > > Infra
> > > > > > > tickets through one of our mentors and link the dev list
> > discussion
> > > > in
> > > > > > > JIRA.
> > > > > > >
> > > > > > > Is there a mentor that is willing to help us navigate this
> > process
> > > to
> > > > > get
> > > > > > > the PR merged?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Carin
> > > > > > >
> > > > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier <
> carinme...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Marco - Thanks for the "dry run" idea. It will give everyone
> a
> > > > clear
> > > > > > idea
> > > > > > > > of the process and what the expected results will look like.
> > > > > > > >
> > > > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > > > - @iblis17 made a copy of the branch of the Julia import PR
> and
> > > > > > submitted
> > > > > > > > it to my repo
> > > > > > > > - I merged it with the "Merge" option through the web
> > interface.
> > > > > > > >
> > > > > > > > Here is a gif of the process of merging:
> > > > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > > > Here is the result of the repo:
> > > > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > > > >
> > > > > > > > Please everyone take a look and validate that this looks ok.
> > > > > > > >
> > > > > > > > If there are no objections, Marco - could you please take the
> > > lead
> > > > in
> > > > > > > > requesting the actions from INFRA?
> > > > > > > >
> > > > > > > > It will be great to *finally* get this PR in  :)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Carin
> > > > > > > >
> > > > > > > > <
> > > > https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang <
> > > plus...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > > > >>
> > > > > > > >> And here is the github document on the 3 different merge
> > options
> > > > for
> > > > > > the
> > > > > > > >> web UI button:
> > > > > > > >> https://help.github.com/articles/about-pull-request-merges/
> > >

Re: Which merge option to use on the Import Julia binding PR?

[Michael Wall]

Great, glad it worked.  I learned something too.

On Thu, Oct 4, 2018, 22:09 Marco de Abreu
 wrote:

> Oh nice, great catch Michael and Carin! I just learned something new,
> thanks :)
>
> I guess we're all set then, right? Thanks a lot, everyone!
>
> -Marco
>
> Carin Meier  schrieb am Fr., 5. Okt. 2018, 02:47:
>
> > Micheal,
> >
> > Thanks. You were right! I could merge.
> >
> > The PR shows up now as merged
> > https://github.com/apache/incubator-mxnet/pull/10149
> > My merge commit is here
> > https://github.com/apache/incubator-mxnet/commits/master
> >
> > Thanks again for the help.
> >
> > - Carin
> >
> >
> >
> > On Thu, Oct 4, 2018 at 8:09 PM Michael Wall  wrote:
> >
> > > I would try the merge locally and then inspect the result closely to
> make
> > > sure it looks like what you want.  If it looks good, you could try
> > pushing
> > > to master.  If you can't push, then we know but I "think" protected
> just
> > > means you can't force push in this case based on
> > > https://issues.apache.org/jira/browse/INFRA-15233 which links to
> > > https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that
> > > with
> > > repo that own though.
> > >
> > > I did find at least one ticket where a team asked for merge commits to
> be
> > > enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I
> think
> > > they intend for it to stay that way.  Is that what the community would
> > want
> > > for the MXNet repo?  Or would you want to enable it for this and
> disable
> > it
> > > again?
> > >
> > >
> > > On Thu, Oct 4, 2018 at 7:29 PM Carin Meier 
> wrote:
> > >
> > > > Micheal,
> > > >
> > > > Thanks for catching up and helping us with this.
> > > > I do see the "view command line instructions". I just assumed that
> > master
> > > > was a protected branch and I would not be able to push to it.
> > > > Honestly, I'm a bit scared if it isn't :)
> > > >
> > > > What do you suggest? Should I try to merge and push to master?
> > > >
> > > > On Thu, Oct 4, 2018 at 7:19 PM Michael Wall 
> wrote:
> > > >
> > > > > Just now looking at this.  The button is disabled for merge commit
> as
> > > you
> > > > > have mentioned.  Before I go to INFRA, is the command line an
> option?
> > > Do
> > > > > you see "or view command line instructions" beside the green squash
> > and
> > > > > merge button?
> > > > >
> > > > > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier 
> > > wrote:
> > > > >
> > > > > > Thank you Mike!
> > > > > >
> > > > > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall 
> > > wrote:
> > > > > >
> > > > > > > Hi Carin,
> > > > > > >
> > > > > > > I will take a look at this tonight.  I am not tracking
> > everything,
> > > > so I
> > > > > > > want to go back and make sure I understand what is being asked.
> > > > Then I
> > > > > > am
> > > > > > > happy to submit an INFRA ticket.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier <
> carinme...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > I just found out that since we are a podling, we should route
> > all
> > > > our
> > > > > > > Infra
> > > > > > > > tickets through one of our mentors and link the dev list
> > > discussion
> > > > > in
> > > > > > > > JIRA.
> > > > > > > >
> > > > > > > > Is there a mentor that is willing to help us navigate this
> > > process
> > > > to
> > > > > > get
> > > > > > > > the PR merged?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Carin
> > > > > > > >
> > > > > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier <
> > carinme...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Marco - Thanks for the "dry run" idea. It will give
> everyone
> > a
> > > > > clear
> > > > > > > idea
> > > > > > > > > of the process and what the expected results will look
> like.
> > > > > > > > >
> > > > > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > > > > - @iblis17 made a copy of the branch of the Julia import PR
> > and
> > > > > > > submitted
> > > > > > > > > it to my repo
> > > > > > > > > - I merged it with the "Merge" option through the web
> > > interface.
> > > > > > > > >
> > > > > > > > > Here is a gif of the process of merging:
> > > > > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > > > > Here is the result of the repo:
> > > > > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > > > > >
> > > > > > > > > Please everyone take a look and validate that this looks
> ok.
> > > > > > > > >
> > > > > > > > > If there are no objections, Marco - could you please take
> the
> > > > lead
> > > > > in
> > > > > > > > > requesting the actions from INFRA?
> > > > > > > > >
> > > > > > > > > It will be great to *finally* get this PR in  :)
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Carin
> > > > > > > > >
> > > > > > > > > <
> > > > >
> https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > 

Re: Which merge option to use on the Import Julia binding PR?

[Pedro Larroy]

Thanks for the efforts, looks like you guys achieved a good solution,
congratulations for the merge to everyone involved.

Pedro.



On Thu, Oct 4, 2018 at 5:47 PM Carin Meier  wrote:

> Micheal,
>
> Thanks. You were right! I could merge.
>
> The PR shows up now as merged
> https://github.com/apache/incubator-mxnet/pull/10149
> My merge commit is here
> https://github.com/apache/incubator-mxnet/commits/master
>
> Thanks again for the help.
>
> - Carin
>
>
>
> On Thu, Oct 4, 2018 at 8:09 PM Michael Wall  wrote:
>
> > I would try the merge locally and then inspect the result closely to make
> > sure it looks like what you want.  If it looks good, you could try
> pushing
> > to master.  If you can't push, then we know but I "think" protected just
> > means you can't force push in this case based on
> > https://issues.apache.org/jira/browse/INFRA-15233 which links to
> > https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that
> > with
> > repo that own though.
> >
> > I did find at least one ticket where a team asked for merge commits to be
> > enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I think
> > they intend for it to stay that way.  Is that what the community would
> want
> > for the MXNet repo?  Or would you want to enable it for this and disable
> it
> > again?
> >
> >
> > On Thu, Oct 4, 2018 at 7:29 PM Carin Meier  wrote:
> >
> > > Micheal,
> > >
> > > Thanks for catching up and helping us with this.
> > > I do see the "view command line instructions". I just assumed that
> master
> > > was a protected branch and I would not be able to push to it.
> > > Honestly, I'm a bit scared if it isn't :)
> > >
> > > What do you suggest? Should I try to merge and push to master?
> > >
> > > On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:
> > >
> > > > Just now looking at this.  The button is disabled for merge commit as
> > you
> > > > have mentioned.  Before I go to INFRA, is the command line an option?
> > Do
> > > > you see "or view command line instructions" beside the green squash
> and
> > > > merge button?
> > > >
> > > > On Thu, Oct 4, 2018 at 9:09 AM Carin Meier 
> > wrote:
> > > >
> > > > > Thank you Mike!
> > > > >
> > > > > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall 
> > wrote:
> > > > >
> > > > > > Hi Carin,
> > > > > >
> > > > > > I will take a look at this tonight.  I am not tracking
> everything,
> > > so I
> > > > > > want to go back and make sure I understand what is being asked.
> > > Then I
> > > > > am
> > > > > > happy to submit an INFRA ticket.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  >
> > > > wrote:
> > > > > >
> > > > > > > I just found out that since we are a podling, we should route
> all
> > > our
> > > > > > Infra
> > > > > > > tickets through one of our mentors and link the dev list
> > discussion
> > > > in
> > > > > > > JIRA.
> > > > > > >
> > > > > > > Is there a mentor that is willing to help us navigate this
> > process
> > > to
> > > > > get
> > > > > > > the PR merged?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Carin
> > > > > > >
> > > > > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier <
> carinme...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Marco - Thanks for the "dry run" idea. It will give everyone
> a
> > > > clear
> > > > > > idea
> > > > > > > > of the process and what the expected results will look like.
> > > > > > > >
> > > > > > > > - I took my fork of the repo and synced my master branch.
> > > > > > > > - @iblis17 made a copy of the branch of the Julia import PR
> and
> > > > > > submitted
> > > > > > > > it to my repo
> > > > > > > > - I merged it with the "Merge" option through the web
> > interface.
> > > > > > > >
> > > > > > > > Here is a gif of the process of merging:
> > > > > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > > > > Here is the result of the repo:
> > > > > > > > https://github.com/gigasquid/incubator-mxnet
> > > > > > > >
> > > > > > > > Please everyone take a look and validate that this looks ok.
> > > > > > > >
> > > > > > > > If there are no objections, Marco - could you please take the
> > > lead
> > > > in
> > > > > > > > requesting the actions from INFRA?
> > > > > > > >
> > > > > > > > It will be great to *finally* get this PR in  :)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Carin
> > > > > > > >
> > > > > > > > <
> > > > https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang <
> > > plus...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > > > >>
> > > > > > > >> And here is the github document on the 3 different merge
> > options
> > > > for
> > > > > > the
> > > > > > > >> web UI button:
> > > > > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > > > > >>
> >