Bug 1077735 - Squashed commits when saving project files
Summary: Squashed commits when saving project files
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER1
: 6.0.2
Assignee: Alexandre Porcelli
QA Contact: Zuzana Krejčová
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-18 13:54 UTC by Zuzana Krejčová
Modified: 2016-08-01 01:09 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-08-06 19:53:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1021406 0 high CLOSED Each time pom.xml is saved, 5-6 unnecessary commits are made 2021-02-22 00:41:40 UTC

Internal Links: 1021406

Description Zuzana Krejčová 2014-03-18 13:54:11 UTC
Description of problem:
If user saves changes in either kmodule.xml or project.imports (via the Project Editor), the resulting commit is squashed with the previous commit. It seems that changes to pom.xml behave as expected.

Let's say you have 2 commits in your git history - "1: creating the example repository", "2: creating a rule". Now you add some import suggestion to the project and save, commit message is "3: imports". Git history will still contain only 2 commit, this time, it will be the commit "1: creating the example repository" followed by commit with message "3: imports" and changes from both the second and third commit (new rule and change in project.imports file).


Version-Release number of selected component (if applicable):
BPMS 6.0.1 ER2


Steps to Reproduce:
1. Create a project TestProject.
2. Create a DRL file in this project.
3. Clone the repository containing this project and look at it's git history.
4. Open the Project Editor (Tools > Project Editor) and go to Import Suggestions section.
5. Remove the default java.lang.Number import and save - use "NO IMPORT" as the commit message.
6. Pull changes into the cloned repository and check the git history.


Actual results:
In step 3, the last commit has no message and contains the new DRL file only. The commit before that is the "New project [TestProject]" commit.
In step 6, the last commit is "NO IMPORT" and contains the new DRL file and the change in project.imports. The commit before that is the "New project [TestProject]" commit. The commit that was most recent in step 3 got squashed into the "NO IMPORT" commit.


Expected results:
In step 3, the last commit has no message and contains the new DRL file only. The commit before that is the "New project [TestProject]" commit.
In step 6, the last commit is "NO IMPORT" and contains only changes made to the project.imports file. The commit before that is the one creating the new DRL file.

Comment 2 manstis 2014-03-19 13:08:57 UTC
Alexandre,

The problem appears to be if the first file in the batch written with IOService doesn't contain any changes then the batch operation squashes the commits into the prior commit.

For example:-

Write 1 (commit 1) : /path/file1.txt == "hello"
Write 2 (commit 2) : /path/file2.txt == "world"
[start batch]
Write 3 (p/o commit 3) : /path/file1.txt == "hello"
Write 4 (p/o commit 3) : /path/file2.txt == "world!!!!!"
[end batch]

Commit 3 is squashed into commit 2.

If however the first file in the batch contains a change things are OK.

For example:-

Write 1 (commit 1) : /path/file1.txt == "hello"
Write 2 (commit 2) : /path/file2.txt == "world"
[start batch]
Write 3 (p/o commit 3) : /path/file1.txt == "hello!!!!!"
Write 4 (p/o commit 3) : /path/file2.txt == "world!!!!!"
[end batch]

Using the reported scenario, we save pom.xml, kmodule.xml and then project.imports. If I always make sure pom.xml contains a change then the commits are not squashed. If however pom.xml contains no changes the commits for the batch are squashed into the prior commit as reported.

Comment 4 Alexandre Porcelli 2014-03-30 14:28:42 UTC
Thank you Michael for your research and perfect description of the problem. So here is the fix:

(master) http://github.com/uberfire/uberfire/commit/3f80417bb
(0.3.x) http://github.com/uberfire/uberfire/commit/7ce45bc68

Comment 5 Zuzana Krejčová 2014-04-29 12:42:28 UTC
Verified with ER2.


Note You need to log in before you can comment on or make changes to this bug.