Request about FEMS Backports

[Sn0w3y]

HI @stefan.feilmeier ,

as the backports are growing over time, I wanted to kindly ask whether it would be possible to split them into smaller, more focused chunks.

From our side, maintaining upstream updates against our local changes becomes increasingly difficult, as we carry quite a few project-specific adaptations that would not really make sense to upstream.

What does the Community think about it?

This is of course just a suggestion, and we fully understand if this does not fit your current workflow.

Thanks a lot and best regards

[stefan.feilmeier]

Hi @Sn0w3y ,

I understand the problem and I am open to improve that situation. As long as it does not slow down the OpenEMS project. FENECON is still the main contributor - and I generally prefer pushing new features upstream ASAP to push the project forward.

I tried to improve the situation by cherry-picking our Commits and referencing them in the pull request - compare FEMS Backports 2026-01-15 by sfeilmeier · Pull Request #3518 · OpenEMS/openems · GitHub to FEMS Backports 2025-10-08 by sfeilmeier · Pull Request #3353 · OpenEMS/openems · GitHub as an example. I use a script to semi-automate that process.

Regards,
Stefan

[Sn0w3y]

Hi Stefan,

it would be great to split the Backports up! I guess this would not slow down, right?

I always Cherry-Picked in the Past - still i often face the Problem that in a increasing ammount of Files it comes to Merge Conflicts which would be easier to resolve if not as much Code would have been changed at once

Thanks again for your consideration!

Is it possible to see the Script or to get it from you?

Greets!

[sjjh]

Not having any own personal stakes in this discussion (and aiming to keep our instance 100% upstream), I do remember, that during the last Hackathon some people from voltfang were stating the same. As far as I understood, they would also prefer to have backports as single commits instead of one big chunk as it would make it easier for them to merge it into their private repo.

I don’t know if making it easier for other people maintaining their private repos, would lead to more contributions from their end.
(In case the discussion gets more complex, discussing it on a hackathon or a general assembly might be a way to proceed.)

[stefan.feilmeier]

@Sn0w3y

Is it possible to see the Script or to get it from you?

Sure

The purpose of the script is simply to quickly cherry-pick commits from our internal fork and cleanup the commit message (with separate cleanup-commit-pipe.sh i.e. replacing authors with their github IDs).

#!/bin/bash

CURRENT_HASH=${1:0:10}

if [[ $CURRENT_HASH ]]; then
	echo "# Starting Cherry Picking for..."
	git show $CURRENT_HASH --no-patch --oneline
	echo ""

	git cherry-pick --no-commit $CURRENT_HASH

	git show $CURRENT_HASH --no-patch --pretty=format:"%B" | ../cleanup-commit-pipe.sh

	code --wait /tmp/commit-message .

	git commit -F /tmp/commit-message

	echo ""
	echo "# Finished Cherry Pick"
	echo ""

else
	CURRENT_HASH=$(git log origin/develop --oneline | grep -m1 "FEMS Backports" | cut -d' ' -f1)
fi

echo "# Remaining Commits"
NO_OF_COMMITS=$(git log fems/develop --oneline | grep -n -m1 $CURRENT_HASH | cut -d':' -f1)
git log fems/develop --oneline | head -n$NO_OF_COMMITS

echo ""
echo "# Suggested next Cherry Pick"
git log fems/develop --oneline | head -n$(($NO_OF_COMMITS-1)) | tail -n1

I also use a script to write the Pull Request description text for the backport

#!/bin/bash

FILE=`mktemp`
HASHES=`git rev-list develop^..HEAD`
GITHUB_URL="https://github.com/OpenEMS/openems/commit"

get_message() {
	local hash="$1"
	git log -1 --pretty=%s "$hash"
}

log_message() {
	local hash="$1"
	MESSAGE=$(get_message "$hash")
	echo "  * ${MESSAGE} [Commit]($GITHUB_URL/$HASH)" >> $FILE
}

add() {
	local name="$1"
	local remaining_hashes=""
	echo "* ${name}" >> $FILE
	for HASH in $HASHES; do
		MESSAGE=$(get_message "$HASH")
		if [[ "$MESSAGE" == *"[${name}]"* ]]; then
			log_message "$HASH"
		else
			remaining_hashes="${remaining_hashes} ${HASH}"
		fi
	done
	echo "" >> $FILE
	HASHES="$remaining_hashes"
}

add "Backend"
add "UI"
add "Edge"

# Remaining entries
echo "* Common" >> $FILE
for HASH in $HASHES; do
	log_message "$HASH"
done

code $FILE

---

This discussion is related to

Discussion: Split the openems/openems Repository by Technology

Thank you for replying. Would it not be possible to merge only subdirectories, e.g. with git sparse checkouts. I also think this one time, but it seems git merge is the process for all directory tree so it cannot devide by subdirectory by sparse-checkout. // If I can ignore/ovewrite git history, There are many way of pulling upstream changes. But it will be difficult to trace changes.

I understand that it can be complicated to stay synchronized with upstream. I think we should try to improve the tools, scripts, etc. to simplify these processes for everybody.