re: history on merges, there's probably some incantation in idea I haven't yet uncovered to be able to stay in one environment instead of having to jump out to a terminal to dig into something. I'm a bit of a stickler when it comes to optimizing workflow; this may just be a Me Thing.
> Having different merge strategies in our history would be worse IMHO. I disagree pretty strongly here. I think an "all commits are chronologically applied to the branch, no changes are hidden inside merge commits" approach is immediately intuitive; people would only have to know the old strategy when they stumble across merge commits which is explicitly no worse than our status quo. That debatable benefit aside, not doing merge commits would also open up options for us to use PR's for merges and integrate running CI, and blocking on clean CI, pre-merge. Which has some other pretty big benefits. :) On Thu, Aug 18, 2022, at 12:07 PM, Avi Kivity via dev wrote: > > > On 18/08/2022 18.46, Mick Semb Wever wrote: >> >> >>>> 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) >> > > > There's `git merge --log` which provides a short-form log in the merge commit. > > >
