1

I am not sure whether this is a Git or IntelliJ problem we are facing. Assuming the following using Git integration in IntelliJ:

  1. User A changes a text file and commits and pushes this change to branch branch1

  2. User B changes the same text file but in a different line and commits to branch1

  3. User B fetches the remote repository and merges the remote branch1 into the local branch1

Current Behavior: It merges wihout any conflicts (since different lines?)

Wanted Behavior: Conflict Resolution Window popups up and User must decide whether to apply all none conflicting changes.

But why you might want this behvaior?: Sometimes we had troubles with markup or js files, where one developer changed something at the top (e.g. removed an unused function) and a another developer was relying on this. One must have very costly ui tests if you want to get informed about those breaks. Especially if it is just markup (e.g. jsf tags, params)

fischermatte
  • 3,327
  • 4
  • 42
  • 52
  • but User And User B are changing the same lines? Because, not exist conflict, if was changed different lines. – enrique-carbonell Jul 04 '14 at 02:49
  • I know, in case of different lines it is not a conflict. But isn't there a possibility to handle it like a conflict and force manual merging? Sometimes we had troubles with markup or js files, where one developer changed something at the top (e.g. removed an unused function) and a another developer was relying on this. one must have very costly ui tests if you want to get informed about those breaks. especially if it is just markup (e.g. jsf tags, params). – fischermatte Jul 04 '14 at 07:20
  • to avoid your problem, i suggest: testing for each source code and maintain a review life cycle to ensure that all was right – enrique-carbonell Jul 04 '14 at 12:34
  • Possible duplicate of http://stackoverflow.com/questions/5074452/git-how-to-force-merge-conflict-and-manual-merge-on-selected-file – flup Jul 08 '14 at 09:58

2 Answers2

3

I am not sure if this is what you want, but you could use the --no-commit option of the git merge command to pretend the merge failed even when there are no conflicts. From the manual:

With --no-commit perform the merge but pretend the merge failed
and do not autocommit, to give the user a chance to inspect and
further tweak the merge result before committing.

Then, you can inspect the changes with git diff with --cached option to inspect the results of the merge; and use git checkout with options --ours and --theirs to accept or refuse the changes introduced by the merge.

joanpau
  • 568
  • 5
  • 14
  • thx for this. I am not very famliar with git, more or less I just use the tooling povided by intellij. it is possible to set the `--no-commit` flag when pulling/merging. as a result i see the changes and can inspect them as you said. but this is the same as doing a diff with the remote branch before merging (?). So in both ways - one has to go through all the files manually and try to find potential conflicts. – fischermatte Jul 09 '14 at 13:00
1

That seems a strange behavior you want. With your last edit I get why you want, but I think you want to use a tool to solve problems which do not concern the tool itself.

I do not have a direct answer, and I do not even think there is an option to force merge review. However, you may develop a merge process in which you asked your coworker to make a diff before the merge. So basically:

  1. do the changes on your local machine
  2. git diff REMOTE/BRANCH -- files
  3. ask the developer to review the changes
  4. if everything went as hoped, commit and push the changes. Otherwise, undo the unwanted changes, and repeat from 2.

As you can see, the process becomes really clumsy and slow and it remains error-prone (if I delete a line, I typically know what I am deleting and if no test gets broken I may be asked to review the deletion hundreds of times and still keep it).

So far, this is the only help I am able to suggest you, if you find any way to achieve your goal in a more direct way, please comment this answer, or provide your own solution, I am always glad to learn something new!

ThanksForAllTheFish
  • 7,101
  • 5
  • 35
  • 54