#PHP 8.2

Thank you for the contribution

I've checked the issue & the issue occurred due to the variable $ids was not declared.

After applying the patch its working fine.

Hi @smustgrave, @BramDriesen,

One issue, I found is that the user is not getting saved in edit mode, getting the error message 'Email field is required.', Also while saving the new user, user is getting created but Email address is not getting saved. The mail column has the null value in DB for that newly created user.

Thanks
Samit K.

Added follow up 🐛 Make label and category properties for layout plugins Active per #78 🐛 Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts RTBC to make sure label and category keys are set.

Test output looks pretty much identical.

What happened when you reran them?

I don't see how this can cause MySQL errors, but ok :P

Seems all those tests are legit failures. Also left a small comment on the MR.

Ah, I needed push access, that's why I didn't see the replay button. Re-triggered the tests.

I highly doubt all those failing tests are relevant to the changes in the MR. Think we need to re-trigger them, but unsure how.

samit.310@gmail.com → made their first commit to this issue’s fork.

Adding a patch

Automatically closed - issue fixed for 2 weeks with no activity.

I am adding a note to the issue summary about the patch for 10.2.x.

I think you will find that pushing the tag deletion will not work due to rules configured in GitLab.

I vote for merging as-is, even with many commits.

Maybe this can help? In particular, check the comments under the accepted solution.
https://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-gi...

The only thing is, I don't know if there are any restrictions on Drupal's implementation of GitLab that allows force pushing a change (e.g. git push -f origin <tagname>).

There is no way to fix the messy commit history except to delete and re-create the tag. If that is not possible, then the messy history will be there anyway. It might as well be merged so that it can be seen in the GitLab network graph instead of the 7.x-1.11 tag being hidden.

Yeah, I know that ... but how does that help move a tag from a feature branch to the main branch? The code in the main branch HEAD is identical to the tagged code. No patch needed, no patch possible because they're identical. The tag is just on the wrong branch.

You can clone your own copy of Entity API and test out any ideas you have for moving a tag, but my searching and experimentation tells me it can't be done without doing a force delete and recreate of the tag. Which would be "A Bad Idea"™

@TR, the easiest way to squash commits like you want to do is to quite simply do a diff between the branches, this diff can be used to generate a patch. Use that new patch to make one commit whereever you want to make it.

Alternatively, depending on the situation, often times I use the cherry-pick command included in git.

Well I'd rather keep the history clean. And the issue of a misplaced tag has been raised many times by others, with the administrator responding that if there's a release attached to the tag then it can't be fixed.

Tagging a 7.x-1.12 release on the HEAD of the correct branch doesn't seem to have any downside.

If you made a commit on 7.x-1.x that was identical to 7.x-1.11, an administrator could in theory delete and re-create the tag there. I don't know if they would do this, however. If not, merging the tag is probably the best bet even if it adds development commits.

larowlan → closed merge request !6533

Committed to 11.x and backported to 11.0.x, 10.4.x and 10.3.x

A simple merge adds all those junk commits from the feature branch - those were for trial-and-error debugging of GitLabCI, had junk comments, and really shouldn't be put into the main branch commit history.

git merge 7.x-1.11 --squash won't work either.

Any suggestions for how to just move that tag onto the 7.x-1.x branch without messing up the commit history?

You can fix it like this: Go to branch 7.x-1.x and run git merge 7.x-1.11. That will add everything in the tag into the 7.x-1.x branch. No need for another release.

Sorry. I don't think it can be fixed because a release was already made with the tag.

The good news is the7.x-1.11 release contains the correct code. But I think I have to tag a new release 7.x-1.12 on the correct branch to fix the problem. The 7.x-1.12 release will be identical to the 7.x-1.11 release.

This can probably be fixed by merging the tag into the branch.