Re: bug?: stgit creates (unneccessary?) conflicts when pulling

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Mar 3, 2006, 22:07 UTC
Message-ID: <4408BE2A.1060601@gmail.com>
In-Reply-To: <20060303142413.GB16456@diana.vm.bytemark.co.uk>

Karl Hasselström wrote:

Show 11 quoted lines

> On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:
>>I attached another patch that should work properly. It also pushes
>>empty patches on the stack if they were merged upstream (a 'stg
>>clean' is required to remove them). This is useful for the push
>>--undo command if you are not happy with the result.
> 
> It appears to work for me. I still had to fix things up manually when
> pulling the uncommit patch though, since you had made a minor change
> in "uncommit.py":
> 
>   Pushing patch "uncommit"...Error: File "stgit/commands/uncommit.py" added in branches but different

Yes, I made some minor modifications (one of them was the copyright).

> Is there a way to make stgit not fall on its face when faced with this
> situation? Surely it ought to be possible to create a merged file with
> conflict markers? (I realize this is harder when there is no common
> ancestor, but these files are 95% identical!)

I've been thinking about this but it's not straight-forward. I tried using /dev/null as the common ancestor but both diff3 and wiggle put the whole file text in the conflict regions. These tools are not smart enough to compare the conflict regions and reduce them.

Another approach would be to have a script that creates the common ancestor only with the common lines between the two files and pass this file as an argument to diff3. This wouldn't probably be that difficult, maybe some combination of diff and sed and apply the result to one of the files to remove the diff'ed lines.

Catalin