On Wed, Aug 8, 2012 at 10:53 PM, THUFIR HAWAT <hawat.thu...@gmail.com> wrote:
> I get conflicts when trying to merge:  https://gist.github.com/3301009
> What I want to do is to take commit x to branch 4 and put it "ontop"(?) of
> commit y on branch "master."  Is that not a merge?
> What does it matter when there's a conflict, isn't that the very meaning of
> merge, that you are saying, yes, these two things are different, replace
> "this one" with "that one"?

You can use 'git merge -s ours' essentially to mark the other branch
as having been merged into the current branch, without actually
incorporating any of the changes in the other branch.  There is no
corresponding "theirs" strategy.  Ask yourself: why do you want to
discard the changes you made on this branch?  And if you're sure you
*do* want to discard the changes on the current branch, do you really
need to keep the history of your failure?  (Paraphrased from [1])

> When would have a merge *without* conflicts, and why?

If the changes on the other branch didn't affect the same files as the
changes on this branch, or if the changes were far enough apart (in
terms of which lines were affected) that Git can be reasonably sure
there's no overlap.

[1] http://marc.info/?l=git&m=121637513604413&w=2


Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to