This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 249427 - Merge commit ignores changes after resolving
Summary: Merge commit ignores changes after resolving
Status: RESOLVED FIXED
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Git (show other bugs)
Version: 8.1
Hardware: All All
: P3 normal (vote)
Assignee: Ondrej Vrabec
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-18 11:46 UTC by hifi
Modified: 2015-03-04 03:57 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hifi 2014-12-18 11:46:41 UTC
When you do a merge in NetBeans git where there are conflicts, you initially resolve them by using the simple merge resolver tool. Sometimes it isn't enough and you select "Accept Both" and edit the resolved code after to actually work.

Now, when you commit this merge conflict NetBeans will completely ignore any ("unstaged") changes you did after resolving and does not really tell you that. You can see that "what you have in your editor" doesn't match what the commit window diff tab shows.

Technically it looks like the difference between a normal commit and a merge commit is this:

  git commit <all files> -m <commit message>

And when resolving:

  git commit -m <commit message>

Of course what it *really* means is that normal commit sort of ignores staging (Git -> Add) and you select the files manually in the commit window and merge commit *requires* you to do add them.

Workaround to this issue is doing Git -> Add on the whole source tree before committing a merge to make sure your conflict is properly resolved.

If you fail to do this, the merge commit will only contain the automatic resolver changes and you will have uncommitted modifications in your tree after.

This has caused a lot of confusion and lost modifications when the changes have been forgotten and accidentally removed from local changes. It is of course a process issue if people "lose" code like this without noticing, but the bigger issue I see here is that NetBeans doesn't help you realize what is going to happen except if you go through the commit window diff very carefully (which you should do anyway).

There is really only one sane solution to this in my opinion and that would be doing the equivalent of "git commit -a" always in a merge commit while also allowing new files to be added optionally in the commit window because that is completely valid in some cases if resolving the merge required extensive modifications.

Additionally the "Add" option should be completely removed as the staging area is nowhere visible and is very confusing without any indication of it. You can always select what you are going to commit in the commit window AFAIK so the functionality is completely redundant.

Removing any possibility to use the staging area is much better than having only partial support. I don't see it being very useful in NetBeans anyway because you can do staging and committing in the commit window directly and adding support for partial commits there would again make staging area redundant.
Comment 1 Ondrej Vrabec 2014-12-19 12:24:16 UTC
(In reply to hifi from comment #0)
> There is really only one sane solution to this in my opinion and that would
> be doing the equivalent of "git commit -a" always in a merge commit while
> also allowing new files to be added optionally in the commit window because
> that is completely valid in some cases if resolving the merge required
> extensive modifications.
True, i noticed this unexpected behavior some time ago, too. I agree commit window should add all (previously committed) files before the merge commit. I will see what i can do.
> Additionally the "Add" option should be completely removed as the staging
> area is nowhere visible and is very confusing without any indication of it.
> You can always select what you are going to commit in the commit window
> AFAIK so the functionality is completely redundant.
You're wrong. Staged changes (aka index) can be reviewed both in the commit dialog and the status window (Git -> Show Changes) [1], you just have to switch to HEAD/Index mode.
> Removing any possibility to use the staging area is much better than having
> only partial support. I don't see it being very useful in NetBeans anyway
> because you can do staging and committing in the commit window directly and
> adding support for partial commits there would again make staging area
> redundant.
True, for normal users index is almost hidden in NetBeans, but whoever wants to benefit from it, may do so and use index as if in CLI.

[1] - https://netbeans.org/kb/docs/ide/git.html#viewFileStatus - the part of the article describing status view icons
Comment 2 hifi 2014-12-19 12:37:33 UTC
(In reply to Ondrej Vrabec from comment #1)
> (In reply to hifi from comment #0)
> > Additionally the "Add" option should be completely removed as the staging
> > area is nowhere visible and is very confusing without any indication of it.
> > You can always select what you are going to commit in the commit window
> > AFAIK so the functionality is completely redundant.
> You're wrong. Staged changes (aka index) can be reviewed both in the commit
> dialog and the status window (Git -> Show Changes) [1], you just have to
> switch to HEAD/Index mode.

"..., you just have to switch ...", I would still call this quite hidden since it isn't on your face all the time. :)

> > Removing any possibility to use the staging area is much better than having
> > only partial support. I don't see it being very useful in NetBeans anyway
> > because you can do staging and committing in the commit window directly and
> > adding support for partial commits there would again make staging area
> > redundant.
> True, for normal users index is almost hidden in NetBeans, but whoever wants
> to benefit from it, may do so and use index as if in CLI.

When you can't add partial hunks/lines into the index I find it rather useless when you can do mostly the same thing in the commit window anyway. My use might be limited since I almost never use the index in CLI except when I make partial commits and stage single lines/hunks.

All in all, fixing this inconsistent behavior is more than enough.
Comment 3 Ondrej Vrabec 2015-03-02 15:15:34 UTC
Fix: core-main #9a93fb7e9d08
Changeset: 9a93fb7e9d08
Message:   Showing HEAD vs Working Tree mode by default when committing after a merge.
The commit table now marks all modifications to be committed except for new files.
Comment 4 Quality Engineering 2015-03-04 03:57:12 UTC
Integrated into 'main-silver', will be available in build *201503040001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/9a93fb7e9d08
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Showing HEAD vs Working Tree mode by default when committing after a merge.
The commit table now marks all modifications to be committed except for new files.
Task #249427 - Merge commit ignores changes after resolving