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

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

 



Karl Hasselström wrote:
> 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
-
: 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]