----- Original Message ----- From: Barry Moore To: [email protected] 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 http://stackoverflow.com/questions/28377725/can-i-make-git-merge-always-conflict-on-file-changes), but I thought it would be relevant to ask here too. I copy and paste underneath: 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! -Barry 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, ...) -- Philip 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
