Until IDEs auto cross-reference JIRA, > > I'm going to lightly touch the lid of Pandora's Box here and walk away > slowly. It drives me *nuts* when I'm git blaming a file to understand the > context of why a change was made (to make sure I continue to respect it!) > and I see "merge 3.11 into trunk" or some other such useless commit > message, then have to dig into the git integration and history, then figure > out which merge commits were real and which were -s ours and silently > changed, etc. > > So about those merge commits... ;) >
The beef I have with this is it's just not that difficult: just look at the parent 2 commit of the merge. ``` git log -n1 <merge-commit>^2 ``` (you can also use `git log --follow .` if you like history without merge commits) > (… also propagate into merge commits and also indicate when a merge > commit makes material changes to the base branch diff) > Beef aside (take it w/ a grain of salt!), this is a good idea. Enforcing it is another matter, and what about all existing history… 🤷🏻♀️ Having different merge strategies in our history would be worse IMHO. > That's not accurate. The ASF requires that any significant contribution > requires a i(CLA), committer or not. > > Is there any guidance in the ASF docs as to what qualifies as > "significant"? This seems like stuff we could document pretty trivially as > a project and maybe link from the PR template. > Nothing qualifies it AFAIK. The Apache License contains the following: "Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions." Good reads: https://lists.apache.org/thread/0mytpqj7too29bj90yz65rggdv7gd35d and https://lists.apache.org/thread/vob27jog5qzrr9m2gz0063log3v6gkc1 In the second, Ted writes "If it is large enough or clever enough to be hard to replicate you should probably ask for a more formal record of agreement to the license."
