Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update header copyright to 2024 #2771

Merged
merged 2 commits into from
Jan 10, 2024
Merged

Update header copyright to 2024 #2771

merged 2 commits into from
Jan 10, 2024

Conversation

Lestropie
Copy link
Member

Necessary update for successful merging of any new changes to master.

@Lestropie Lestropie requested a review from a team January 9, 2024 00:17
@Lestropie Lestropie self-assigned this Jan 9, 2024
@jdtournier jdtournier enabled auto-merge January 10, 2024 10:03
@jdtournier jdtournier added this pull request to the merge queue Jan 10, 2024
Merged via the queue into master with commit 670e7b0 Jan 10, 2024
@jdtournier jdtournier deleted the update_copyright branch January 10, 2024 10:33
@daljit46
Copy link
Member

Can we merge this into dev too?

@Lestropie
Copy link
Member Author

Can we merge this into dev too?

Normally I'd opt to do this as a regular merge of master into dev. However with cmake & clang-format being on dev now this is a very unclean merge. So I think maybe we'll just redo the copyright update on dev separately, and any fixes on master that need to make their way to dev (which is not all of them) can be individually merged / cherry-picked.

@jdtournier
Copy link
Member

We'll need to do the merge properly at some point anyway, otherwise we simply won't be able to merge back to master when we eventually release. I reckon it's best to do the messy work now, otherwise it'll only get worse over time. Personally, I think we need to do a merge of master back to dev back now.

@Lestropie
Copy link
Member Author

It's possible that for something like update_copyright, running separately on each branch prior to merging might give git merge a bit of a helping hand in terms of reducing the scope of conflicts. I'll have to check the other PRs that have since gone to master to see the scope of those. A naive git merge produced a much larger conflict than what I would have expected, probably due to differences in indentation. Manually cherry-picking each PR onto dev and then accepting local in the merge conflict might be the way to go, to make sure that no desired changes are lost in the merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants