Re: Bizarre git merge behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



W dniu 2013-11-20 13:03, Matthew Cengia pisze:
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).

[...]
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



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]