- 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
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
