Merge "master-with-treewide-nixfmt" into haskell-updates#395864
Merge "master-with-treewide-nixfmt" into haskell-updates#395864sternenseemann merged 2033 commits intoNixOS:haskell-updatesfrom
Conversation
Co-authored-by: uncenter <[email protected]>
|
Thanks for looking into this. This looks like an adequate solution. The one alternative I see would be to independently reformat all files the haskell-updates branch has changed compared to master/staging in an actual commit and then merge. This could have the upside that the merge commit is smaller. As things stand, it is quite an arduous task reviewing the merge commit 2248aee58984c3378eaa093cfce29fed2f349b9e. From a technical perspective, I'd agree that the merge driver is the better solution. |
Co-authored-by: liyangau <[email protected]>
Co-authored-by: kashw2 <[email protected]>
I actually tried that, but still got plenty of merge conflicts to resolve. Not sure whether I made a mistake there or the approach won't work in principle. |
The only way to "review" the merge commit is by reproducing it and then looking at the diff (aka the manually resolved conflicts). This only confirms that I didn't sneak anything into that commit, though - not whether the merge-driver did alright.
We have a merge conflict now, so I'll need to redo this. How would you like to proceed? Should I push it directly to |
|
If it's okay with you, I'd say update this PR and I'll reproduce the merge commit and merge then? |
|
(Alternatively, solve the merge conflict by merging haskell-updates into this PR.) |
…updates-merge-nixfmt
…t on hackage-packages.nix
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
a1355c8 to
ccdcdd5
Compare
Did that. The latest merge-base was 3b48b2e. Since you fixed |
|
The PR's base branch is set to haskell-updates, but 2030 commits from the master branch are included. Make sure you know the right base branch for your changes, then:
|
sternenseemann
left a comment
There was a problem hiding this comment.
I'm able to create the exact same tree object (f749a0cb63afebb64b9057b4b0b39ba9b89723d3) using the approach outlined in this PR.
|
Thanks for figuring this out! |
#371032 currently has quite some merge conflicts after the treewide nixfmt run in #380990.
I tried to merge the current merge base of master and staging back into haskell-updates, but this isn't easy. The approaches in #395247 are targeting smaller branches and rebases, but not a merge of this size:
Thus, I used a better approach: I wrote a custom git merge driver. This kicks in before the conflicts arise, runs nixfmt on all sides, then merges the files. The result is applied here.
The merge-driver consists of:
.git/config:.gitattributes:merge-driver.sh:This gave me zero merge conflicts, except for a true conflict in the release notes. I am quite confident in the result, but a second pair of eyes would be good.
Additionally, there is the question of how to deal with the auto-generated
hackage-packages.nixfile. I'm not sure whether that was explicitly discussed as part of the treewide formatting effort or just happened to be formatted, too.Here, I took the pragmatic approach and added a
nixfmtcall to the script generating this file. (Can't currently test this, because the regeneration script has broken haskell dependencies on the branch currently.)