On Thu, Dec 09, 2010 at 10:27:56PM +0100, Johanna Ploog wrote:
> I've seen and resolved conflicts before, but never ones as complicated
> as this one.
> 
> Commit b03ab3ea introduced a load of spacing fixes [*] in a file I was
> working on.

Whoops, sorry.

> Unfortunately, I had already made three local commits to
> said file which git was unable to merge into master, so I ended up in
> a local branch of my own, with no clue how to get things working
> again.

If you have problems of this kind you are unable to fix, please push it to a
temp branch: git push sf master:my_new_temp_branch, and tell us about this.

Since the commit which caused conflicts had no meritorical changed, it
wouldn't be unacceptable to simply revert it.

> After lots of hair-pulling and gnashing of teeth (read: several
> frustrating attempts to resolve this conflict, each one less
> successful than the last), I finally ended up doing what I would have
> done in svn: somehow by trial and error return to the state before the
> checkout, copy all my modified files elsewhere, skip over any
> troublesome patch during checkout (all three of them) and copy my
> modified files back into the now up-to-date master. This kind of
> brute-force manoeuvre seems kinda at odds with git's general
> behaviour, so there's probably a neat and elegant solution out there.

In most cases, the blocks will be relatively short, but sometimes things may
indeed get convoluted.  In such cases, I noticed that "patch" can often get
better results than git's patching.

Also, this particular problem could be dealt with by "patch -l" which does
exactly what we'd want here.  I'm not sure if --ignore-whitespace in git
itself would do this (literal reading of the docs say no) so you'd have to
use "git diff" then "patch" by hand.

> Thus I ask you git gurus: What would have been the *correct* steps to
> resolve such a conflict?

There might be a better way, indeed.  

-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.

------------------------------------------------------------------------------
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss

Reply via email to