Red Hat Bugzilla – Bug 1021406
Each time pom.xml is saved, 5-6 unnecessary commits are made
Last modified: 2014-08-06 15:59:05 EDT
Description of problem:
Every time you click File -> Save on the project screen, no matter if you made any changes or not, 6 commits are made in the underlying git repository. The result is a mess in the git log.
First two commits are for .pom.xml - one deleting it, other recreating it. Next two do the same for .kmodule.xml and the last couple deletes and recreates .project.imports.
The most basic improvement is to only have one commit per file, but it still wouldn't help much.
The newly created .pom.xml is committed along with the changes done to the pom.xml, so if we have to commit the other two dot files, it would make sense to do it in that commit too, since the "changes" in those two were brought by the change in pom.xml.
I'd consider this fixed well if these commits and changes to dot files were only done if there actually was some kind of change being saved.
(1) If I actually made some change to the project and (2) if the file now being recreated should end up with a different content.
E.g. right now, if I add a dependency to the project, only pom.xml and .pom.xml are changed, so there is no need to recreate the .kmodule.xml and .project.imports - the new files are exactly the same as the old ones.
Version-Release number of selected component (if applicable):
BPMS 6.0 ER4
Since there are still reports of degradation over time due to the number of commits, this change is important to also help with that.
All the files with changes are now committed with a single commit when save is pressed.
I cannot, with clear conscience, mark this as verified.
Yes, there is only one commit per save. Problems?
1. Each save. Even if no change was made.
2. The commit may include files not relevant to the change. Let me explain...
First I tried to save a project state without making any change. Just for the fun of it. I saw .pom.xml being changed in git. Ok, not the best way, but... So the next thing I did - I actually made a change, I changed the project version. And saved. When I looked into git log, I see a commit with only the change in pom.xml (Yay! Right? No.). So I try the other 2 sections.
Changing kmodule.xml produces commit with this change and a changed .pom.xml. Why .pom.xml? Because in the previous commit I changed pom.xml.
Changing project.imports produces commit with this change and a changed .kmodule.xml. Same reason as above.
So we now have a different kind of mess in the git log.
Alexandre, sorry, but could you take a look? Normally, if we try to save an unmodified file we don't get a commit. IDK with the "batch" operation whether this behaviour remains unchanged? The comment above implies all files in a batch are committed even if unchanged.
Unnecessary dot files were already fixed by these commits (from #1049368):
Couldn't reproduce empty commits nor multiple commits (tested with master and 6.0.x branches).
With CR2, behaviour described in comment 3 is still an issue:
Saving a project state when no change was made produces an empty commit (commit with the provided message but no files).
Next, if I change e.g. artifact ID, only pom.xml is saved/added to the commit (since no file was changed in the previous step).
After that, if I e.g. add a KBase and save, the commit contains 2 changed files - .pom.xml (pom.xml was modified in the previous step) and kmodule.xml.
In the fourth step, I add some import suggestion and save, which gives me a commit with changes done to .kmodule.xml (kmodule.xml was modified in the previous step) and project.imports.
If I make another change in KBases section and save, I get a commit with .project.imports (project.imports was modified in the previous step) and kmodule.xml.
In other words:
If, in step N, I change file X (where X is one of pom.xml, kmodule.xml, project.imports) via the Project editor, in step N+1, the commit will contain also changed file .X. Each step consists of only one change in one of the [pom.xml, kmodule.xml, project.imports] files and saving the modification.
If there was no change to a file in step N, then in step N+1, the commit will contain only the modified file, as expected.
I'll retest with the next available build.
(In reply to Toni Rikkola from comment #2)
> All the files with changes are now committed with a single commit when save
> is pressed.
Commits for this were:
This no longer has a target release of 6.0.0.
Looking at the Git repos after our test runs, this no longer seems to be an issue. VERIFIED with ER2.