-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad Git-LFS reversion test #100
Conversation
The reversion was a success so I decided to take advantage of the commit sensitivity of a pull request and attempt to commit those verb icons again. Everything appears to be working, but I'm still waiting on Travis CI for Mac build results. |
Also: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need 3 commits for uploading two images, please squash it down to a single commit.
@@ -15,6 +15,7 @@ | |||
<MonoGameContentBuilderExe Condition=" '$(OS)' != 'Windows_NT' And Exists ('/opt/monogame-pipeline/MGCB.exe') ">/opt/monogame-pipeline/MGCB.exe</MonoGameContentBuilderExe> | |||
<TargetFrameworkVersion>v4.5.1</TargetFrameworkVersion> | |||
<TargetFrameworkProfile /> | |||
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is completely unrelated to the images, please make a separate PR for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You literally made PR #99 for this purpose but closed it for unknown reasons, please open it again and do it there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure why you're doing this change in the first place, this property seems to be related to .NET 4.5.1, but all our projects is using that version, so why is only this single project getting this property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, I abused our repo with some personal git experimentation. I'll try to not do that in the future. The transition from TFS to Git is much more difficult since I transitioned from Git to TFS 2 years ago.
I thought I explained in the comments why I closed #99. I'll see what I can do about correcting this. Pull requests do not work the way I thought I understood them.
Hero6.DesktopGL uses the .Net 4.5.1 framework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're willing to accept this PR, the drop down has an option to squash and merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't help but feel, that if we're going to add this property, we should add them in other projects as well.
The actual images are working great, but there is some messy execution in accordance with standard git practice so I'll need to be deliberately tedious in my reviews so you get it right. |
If the other projects are using 4.5.1, sure. Eliminating a warning was just a simple excuse for me to practice with git. Desktop was the only one reporting that warning.
On Sat, Feb 25, 2017 at 3:03am, Per Olav Flaten < notifications@github.com [notifications@github.com] > wrote:
@persn commented on this pull request.
In src/Hero6.DesktopGL/Hero6.DesktopGL.csproj [#100 (comment)] :
@@ -15,6 +15,7 @@
<MonoGameContentBuilderExe Condition=" '$(OS)' != 'Windows_NT' And Exists ('/opt/monogame-pipeline/MGCB.exe') ">/opt/monogame-pipeline/MGCB.exe</MonoGameContentBuilderExe>
<TargetFrameworkVersion>v4.5.1</TargetFrameworkVersion>
<TargetFrameworkProfile />
+ <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
I can't help but feel, that if we're going to add this property, we should add them in other projects as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [#100 (comment)] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AF6-kPSIorN_SsdSBPzf1T9GxZARxX12ks5rgAqVgaJpZM4MK9gv] .
|
All the other projects uses 4.5.1 to my knowledge, personally I didn't get any warning off the sort, curious |
Are the other projects using binding redirects in their config files?
On Sat, Feb 25, 2017 at 3:08am, Per Olav Flaten < notifications@github.com [notifications@github.com] > wrote:
All the other projects uses 4.5.1 to my knowledge, personally I didn't get any warning off the sort, curious
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [#100 (comment)] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AF6-kI0dYLlIJy-PNDwzsXEvwU_hJnfGks5rgAu6gaJpZM4MK9gv] .
|
I don't think so, but neither is DesktopGL to my knowledge |
Okay, I've been digging around a little and I'm guessing that DesktopGL needs binding redirects because it contains multiple entry point assemblies to the Eto framework. Things suddenly make more sense now so I don't feel we need to to introduce this property for every other project. Since this PR now has a merge conflict anyways I'm going to suggest that you take the following course of action.
I still want the binding redirects in a separate PR, preferably in the already existing #99 so that we don't clutter our GitHub history further. But that will not be possible until this PR is concluded since you used the same branch name for both PRs. |
I've made the verb icon changes you recommended to this branch. The Mac build appears to not understand 'git lfs' commands; otherwise, everything looks good on this end. Once we finalize this, I'll update and reopen #99 |
I attempted to commit to my v0.1.0 branch with an outstanding pull request. Somehow the second commit was linked to the pull request, which inadvertently caused failure. I suspect this was the result of how we're setting up the git push endpoints in combination with VS2015 git operations. I reverted the changes and performed a 'git lfs pull' it is my hope that this successfully reverted the problem and I'd like to see if a second pull request causes failure.