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

FindBug Fixes... New LayoutEditorTests #4594

Merged
merged 5 commits into from Dec 20, 2017

Conversation

Projects
3 participants
@geowar1
Contributor

geowar1 commented Dec 20, 2017

This is a "do over" for #4553, #4554, #4578 and #4563; They were showing 306 files changed instead of the correct 14. (Why "git blame" when you can "blame git"? ;-)

@bobjacobsen

This comment has been minimized.

Member

bobjacobsen commented Dec 20, 2017

(responding to the "Gerrrrrr GIT! (Didn't pick up some of the changes… why?!?" commit comment) It would probably be good to figure out what in your workflow is causing these problems. They're not common: lots of people don't experience those kinds of things. Perhaps there's some setting or configuration detail that's making git misbehave for you, or some changed sequence of operations that would keep problems from recurring, or something like that.

When git fails to "pick up some of the changes", what had you been doing just before?

@geowar1

This comment has been minimized.

Contributor

geowar1 commented Dec 20, 2017

My pre-LayoutEditor-development workflow would do this occasionally: I'd do a commit and then go to create a PR and GitHub would say I'd changed (many) more files than I'd changed. Sometimes I could revert the commit and then re-commit and everything would be fine. Other times I'd have to "git reset --hard HEAD^" and re-diff my change back in and then commit. Post-LayoutEditor it's been almost every time. AFAICT the fly in the ointment is doing an "update from master branch" (in GitHub desktop). I learned (the hard way) to NEVER do that with uncommitted changes.

@geowar1

This comment has been minimized.

Contributor

geowar1 commented Dec 20, 2017

This time I had to "git reset --hard HEAD^" about 20 times (after each time I'd create a new branch (no commits!) and then try to create a PR… if it said I still had file changes I'd loop again until I got a branch with no changes. THEN I diff'ed my changes back in and created this PR.

@geowar1

This comment has been minimized.

Contributor

geowar1 commented Dec 20, 2017

I suspect that the reason git didn't pick up some of the changes I made was because I hadn't "saved" them to disk (the NetBeans editor was still open).

@bobjacobsen

This comment has been minimized.

Member

bobjacobsen commented Dec 20, 2017

This time I had to "git reset --hard HEAD^" about 20 times (after each time I'd create a new branch (no commits!) and then try to create a PR… if it said I still had file changes I'd loop again until I got a branch with no changes. THEN I diff'ed my changes back in and created this PR.

This really shouldn't be happening. Perhaps I'm missing something, but I can't see how repeating git reset --hard HEAD^should ever do anything different from the 1st time it's done. Let me look into this a bit...

@pabender

This comment has been minimized.

Member

pabender commented Dec 20, 2017

I'm ok with this as it is now. Should I go ahead and merge?

@geowar1

This comment has been minimized.

Contributor

geowar1 commented Dec 20, 2017

Yes, please. And thanks for the review and your patience while I got it straightened out.

@pabender pabender merged commit 96a2d57 into JMRI:LayoutEditor-development Dec 20, 2017

4 checks passed

WIP ready for review
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls First build on LayoutEditor-development at 39.724%
Details

@geowar1 geowar1 deleted the geowar1:LayoutEditor-Rewrite-drawing-code-and-add-decorations branch Dec 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment