Re: Bizarre git merge behaviour

From: Jakub Narębski <jnareb@gmail.com>
Date: Nov 20, 2013, 15:34 UTC
Message-ID: <528CD671.7090702@gmail.com>
In-Reply-To: <20131120120326.GD26413@debian.cengia.id.au>

W dniu 2013-11-20 13:03, Matthew Cengia pisze:

Show 10 quoted lines

> On 2013-11-20 08:20, Johannes Sixt wrote:
> [...]
>> Not really. It's impossible to tell what's wrong if you
>
> Hi Hannes,
>
> Thanks for your response, and sorry for providing insufficient
> information; this is a company Git repo (it's also about 200MB), so I've
> got be careful what I post, but I can certainly give more than I've
> shown already.

I think there is some anonymizing tool for git, which replaces data (blobs contents and file names) with artificial names, while preserving history. It was intended to help debug repos with proprietary data... but unfortunately I have not bookmarked it (or lost bookmark).

[...]

Show 5 quoted lines

> I'm truly stumped. It's also worth noting that I've gone through and
> manually resolved this merge one file at a time, and I'm about 90% sure
> I ended up with the correct result, but it'd be nice to have had the
> merge do the right thing in the first place, and I obviously want to
> avoid having to do this again in a few months' time.

Well, there is git-rerere (reuse recorded resolutions) which records file-level (textual) merge resolutions and tries to reapply if appropriate when merging.

Perhaps git-imerge tool would be of help in complicated merges?

-- 
Jakub Narębski