On Thursday, 9 August 2012 00:29:20 UTC-7, Peter J Weisberg wrote:
> On Wed, Aug 8, 2012 at 10:53 PM, THUFIR HAWAT
> > 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"(?)
> > 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
> > 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 )
> > 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.
>  http://marc.info/?l=git&m=121637513604413&w=2
> Gehm's Corollary to Clark's Law: Any technology distinguishable from
> magic is insufficiently advanced.
Aha, thanks for explaining about merge, at least now I see why that merge
fails, it's too small. Interesting.
I think that I do want to zap the master branch; git reset --hard origin
will delete everything in origin, or just everything in master on origin?
In this case, I'm using github.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at