search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.63k stars 841 forks source link

NETBEANS-59 - Document split actions #3

Closed Chris2011 closed 6 years ago

Chris2011 commented 6 years ago

Cleaned up code as discussed here: #1

Everything fine now?

matthiasblaesing commented 6 years ago

Chris is a committer, so he can commit himself. @Chris2011 if you need help, feel free to contact me.

junichi11 commented 6 years ago

Sure. Anyway, I wanted to avoid merging it as it is :)

Chris2011 commented 6 years ago

Will try that. Thx.

Chris2011 commented 6 years ago

So now, everyhing should be fine now. I renamed the old branch, made a clean one, updated all branches that is needed, applied the patch, changed the line endings from CRLF to Unix LF. 3 files are new, which are the 3 actions (ClearSplit, SplitDocumentVerticallyAction and SplitDocumentHorizontallyAction). The SplitAction.java file only removes some Bundle messages.

Atm, I don't know why is the SplitAction completely red and green again but finally, it shouldn't matter now. Everything was discussed earlier. Please merge now.

matthiasblaesing commented 6 years ago

Please recheck SplitAction - it now has windows line endings (\r\n), which is also the reason, that it looks so red.

Chris2011 commented 6 years ago

Hm, I closed the file and reopened it, now it is CRLF, will fix it.

Chris2011 commented 6 years ago

It doesn't make sense to change it now to LF and amend the commit, right? Do I have to do it again? I mean applying the patch and fix the line endings?

matthiasblaesing commented 6 years ago

If you change line endings, do an amend commit and then force push that should do it.

Chris2011 commented 6 years ago

Got it.

matthiasblaesing commented 6 years ago

You now lost the commit message :-) - When you amend you need to keep in mind, that you replace the previous commit.

Chris2011 commented 6 years ago

Hm, ok. I thoght they will merged together. The Message too. But this should Not be a Problem now. Now I know it and will make it better next time :).

matthiasblaesing commented 6 years ago

Why wait? An amend commit is possible without any file changes, so you can still fix the commit message. Same procedure s before: Start the amend commit, check/update the message, finish the commit, force push.

Am 15. September 2018 23:26:34 MESZ schrieb Chrizzly notifications@github.com:

Hm, ok. I thoght they will merged together. The Message too. But this should Not be a Problem now. Now I know it and will make it better next time :).

Chris2011 commented 6 years ago

Done.

matthiasblaesing commented 6 years ago

Looks better, though I would not choose this message. I would have worded it:

[NETBEANS-59] Separate actions for document splitting to enable shortcuts

<Context explaining why it was implemented the way it was>

It is a summary what was the desired outcome of this commit, which helps to understand the code changes. If an explanation is required why it was implemented the way it was or context should be provided, the further lines of the message can be used. The context is not always required, but helps to put the understand changes years later.

You can change the message or merge to master as is.

Chris2011 commented 6 years ago

I can understand your point but first, my commit message is exact that, what the commit means. Maybe it is only a wording for sure and I know that, because I do it every day as all of you, But to be clear, the commit message should be as short as possible to explain what the commit makes. Here we only have one commit, but often we have more.

Second, everything else, what is not kind of related to the commit, is written in this ticket: https://issues.apache.org/jira/browse/NETBEANS-59. There is the exact explanation why it was implemented or why I want it or what I want. So If you need further information, look into the ticket.

Thx to all of us with my first apache netbeans PR for the info, help, hints and everything. Next time, I will be more careful. But please don't be that strict to everyone. I think a lot of people can lose motivation. IMHO. Will merge it now.

matthiasblaesing commented 6 years ago

I often use the "Show annotations" functions when working with code bases. Often the commit message holds the information that is necessary to understand why something was done the way it was. I see good commit messages in the same league as good comments: I'm not interested in comments, that just repeat what is obvious, but that give the code some meaning/context (explain the why). In the same sense good commit message give context (summary of the change) and explain why the change was done.

I have yet to see an instance where I took the time to wander through several issue reports, even if they are referenced. Switching to the issue tracker takes time and often issue texts don't help or the real explanation is buried in one of the uncounted number of comments.

Consider the current situation: Oracle could shutdown the bugzilla instance of netbeans right now. If the commit messages are meaningfull and explain the main reasoning, history could be reconstructed from my mercurial clone (or the git conversion of that). The commit history in a DVCS is by definition a good place to give context information.

Don't take this wrong: I appreciate your work and also the stamina to see this through.

I will keep being strict about these things. I have seen code bases, where commits looked like shit and the earlier a contributer learns about good commits, the better for him/her and the project and the commiter.