I agree that there's no need for the pull-request formalism while you're working incrementally on a branch. The time to issue a PR is when you want review from others before merging.
When working on a development branch like the 3.0 subset support, there _is_ an argument for taking branches off that, working on them, and asking for review before merging them back into that development line. This would give you a good place to squash based on functional units, which I'm sure VLSI would demand as easier to review. Commit messages: There is best practice, and there is common practice. I tend to write most of them on the command line with -m, so mine have tended to be one long string which is simultaneously too much and too little information. I clean that up when I issue the PR and/or when I Squash, since the squash will drop most of the intermediate progress notes anyway. I'm willing to try to prettify my -m messages, but the most likely outcome would be my making them more terse, which may not be a net gaiin. Style rules are great. But style rules are guidelines, not always applicable and not always worth applying. Never let the ideal drive out the good enough. Reasonable request, unreasonable as demand, really not worth fighting over if it gets in the way of development or makes people grumpy. -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail! ________________________________ From: vlsi (via GitHub) <g...@apache.org> Sent: Monday, October 23, 2023 7:50:43 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: [PR] committing enhancements to xs:dateTime data type's implementation, and adding few new working test cases for xs:dateTime data type's arithmetic. also modifying the NOTICE.txt file, mentioning details of few implementation dependencies for this... vlsi commented on PR #108: URL: https://github.com/apache/xalan-java/pull/108#issuecomment-1775023049 > helps to have a XalanJ process already setup as of now for non-committers to be able to make their codebase contributions to XalanJ Committers already have an infrastructure: they can commit to a branch directly. If you commit directly, it is less actions for everybody: * less commits: no "merge" commits in history * less notification noise for everybody: no "pr created and immediately closed" notifications * less work for committers: they can just commit code instead of "commit code + create PR + merge PR" >Definitely not, please. Could you please clarify why you deviate from the Git recommendation then? https://git-scm.com/docs/git-commit#_discussion > Git commit man page: It’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a **blank line** and then a more thorough description. > mukulga: Shortening the PR title, of a complicated code change, and not mentioning needed details on PR title, shall make it difficult for users to start reviewing the code changes of the PR Please read `git-commit#_discussion` carefully. I do not suggest removing details. I suggest using "subject" and "body" better: put the most important bits into **subject**, and put details in **body**. They should be separated by a blank line as per Git conventions. It is not something I invented. It is a generic Git recommendation. Do you think you could format commit messages into the subject line and the body? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
