search

aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
488 stars 180 forks source link

Plugin overwrites git submodule references #348

Closed marcelopaulon closed 1 year ago

marcelopaulon commented 2 years ago

To reproduce the problem:

  1. Create project A (maven project) which has the gitflow maven plugin and imports the git submodule Asub. Asub can contain anything, just text files for example. Project A must have a main branch and a develop branch.
  2. Open a new release branch in A using the gitflow plugin.
  3. Add a new commit to Asub (and push it).
  4. Update the reference in project A's release branch to point to the most recent commit in Asub.
  5. Close the release branch in project A.

Expected behavior: both main and develop point to the latest commit in Asub.

Actual behavior: main points to the latest commit but develop does not (gitflow plugin's "Update develop version back to pre-merge state" commit overwrote the reference back to what it was in the develop branch before closing the release branch.

This seems to happen because the plugin is not performing git submodule update after checkout, and when it commits it uses the -a option which adds all changes (including the dirty submodule reference, which points to the old commit in Asub).

So, I've opened a PR to add the option of always performing a git submodule update before the plugin commits any changes.

aleksandr-m commented 2 years ago

@marcelopaulon Cannot reproduce. Updating develop back to pre-merge state changes only pom.xml, how it could affect git submodule?

Can you include exact commands that you execute, step by step?

juanplopes commented 2 years ago

@aleksandr-m The problem happens because of git quirk when dealing with submodules. Performing a git checkout to a different branch, where a submodule points to a distinct commit hash than the original branch leaves the working copy in a dirty state. In such a way that a subsequent git commit -a may commit an unintended change to the submodule reference. The solution is to perform a git submodule update before the commit.

This problem occurs when you update the xmls and perform a git commit -a to update develop/release back to pre-merge stage. This can be partially mitigated using git config submodule.recurse true, but the problem persists in the case of hotfixes, because submodule.recurse does not work with git merge (that has the same behavior).

aleksandr-m commented 1 year ago

1.19.0 is released.

The plugin looks for the .gitmodules file and if it exists the git submodule update command will be executed before each Git commit. This is needed to avoid leaving working copy in dirty state which can happen when switching between branches. To explicitly control whether Git submodules will be updated before commit the updateGitSubmodules parameter can be used. Setting it to true will enable Git submodules update and false will disable it even if .gitmodules file exists. The default value is not set, meaning the plugin tries to automatically determine if update is needed.

juanplopes commented 1 year ago

Thank you! 💜