From: Petr Baudis Date: Thu, 10 Nov 2005 19:43:17 GMT Subject: Re: merge-one-file: use common as base, instead of emptiness. Message-ID: <20051110194317.GV30496@pasky.or.cz> In-Reply-To: <7v64r16ro9.fsf_-_@assigned-by-dhcp.cox.net> Dear diary, on Thu, Nov 10, 2005 at 05:41:10AM CET, I got a letter where Junio C Hamano said that... > Petr Baudis writes: > > > I think having > > > > <<<<< > > file1 > > ===== > > file2 > > >>>>> > > > > is an awful PITA to resolve, especially when the files actually are > > similar. Running some vimdiff (or just diff and possibly applying either > > way) on two separate files is much more convenient. > > You are right. > > How about something like this? This adds a specialized hackery > flag, --no-add, to git-apply, and uses it to compute common base > to be used for 2-file merge, instead of using /dev/null. Wow, astonishingly simple. > -- >8 -- cut here -- >8 -- > Unlike the previous round that merged the path added differently > in each branches using emptiness as the base, compute a common > version and use it as input to 'merge' program. > > This would show the resulting (still conflicting) file left in > the working tree as: > > common file contents... > <<<<<< FILENAME > version from our branch... > ====== > version from their branch... > >>>>>> .merge_file_XXXXXX > more common file contents... > > when both sides added similar contents. But obviously now the trouble is opposite, when the files are completely unrelated, since now you likely get large conflicting areas interleaved with some scarce common lines... And this might get to be a big PITA to resolve as well. That said, I still really like --no-add and it would be heart-wrenching to just coldly dismiss it. It is a great tool, but I would let the user to use it manually. Possibly something like git-twofile-merge foo~1 foo~2 (the name is stupid, obviously) or a button in some GUI tool. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.