----- Original Message ----- 
  From: Barry Moore 
  To: git-users@googlegroups.com 
  Sent: Saturday, February 07, 2015 2:27 AM
  Subject: [git-users] Can I make `git merge` always conflict on file changes?

  Hey All,

  I posted this on stack overflow (see 
 but I thought it would be relevant to ask here too. I copy and paste 

  I am hoping I have a simple question for you, but I can't find an answer 
anywhere (I have been searching for 2 days, maybe I am dumb?). I am trying to 
develop a git workflow to collaboratively edit LaTeX files with my PhD adviser. 
The problem we face is due to the behavior of git merge (because it merges 
automagically). I want git to conflict anytime it sees a file change, even if 
it is an addition, subtraction, or minuscule change, is this possible? This way 
we can both pick and choose changes and continually push to master.

  I am not opposed to using another tool, but I would prefer not to create a 
complicated branching system. I assume branching is unnecessary when 2-3 people 
are working on the same file. Thank you so much for your help!


You need to be cautious about the mental model of the collaborative workflow in 
a distributed VCS. In a distributed system it is "impossible" (because they are 
distinct items) for everyone to work on everyone else's personal 'master' 
branch (you always have a personal copy in your local repo). The common advice 
to use 'git pull' is often a problem because it includes the automerge. 

In the situation you describe(*), it's better to do a fetch, so that you have a 
copy of remote/adviser/master, and then separately do a merge, but using a 
different merge tool such as kdiff3 (open source) or bc3 (commercial but nice) 
at the point that you want to do the mix and match (merge) between the edits. 
The choice of merge tool can be setup in your config file.

In the description above(*) one is never working on, nor pushing to,  the other 
persons 'master'. At this point you have to decide (social convention) how you 
will agree whose merge is 'the best', and then where to store that (*).

(*) You probably have a central server repo (probably --bare), plus two 
personal (local, with working-trees) repos on your local computers. My initial 
description is the direct peer-peer connection without using the central 
server. The social convention issue then happens when you bring the central 
server into play. It is likely you will need distinct names for the 
'agreed_master' and for 'barry_master' and 'adviser_master' to avoid naming 
conflicts on the central server. There are many discussions about the different 
workflow styles e.g. 
http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows (Dictator, 
Lieutenant, first among equals, ...)

It's not the branching system that's hard, it's deciding who's in charge ;-)

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to