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
>
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.
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
>
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
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
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
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
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
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
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):
>
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
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
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
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
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
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
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
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
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
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
+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
+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
+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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
