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

From: Karl Hasselström <kha@treskal.com>
Date: Mar 3, 2006, 14:24 UTC
Message-ID: <20060303142413.GB16456@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0602281445w7160d915y@mail.gmail.com>

On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:

Show 18 quoted lines

> On 27/02/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
>
> > An idea (untested, I don't even know whether it's feasible) would
> > be to check which patches were merged by reverse-applying them
> > starting with the last. In this situation, all the merged patches
> > should just revert their changes. You only need to do a git-diff
> > between the bottom and the top of the patch and git-apply the
> > output (maybe without even modifying the tree). If this operation
> > succeeds, the patch was integrated and you don't even need to push
> > it.
>
> 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.
>
> I'll try this patch for a bit more before pushing into the
> repository.

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

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!)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle