From: Karl Hasselström Date: Fri, 03 Mar 2006 14:24:13 GMT Subject: Re: bug?: stgit creates (unneccessary?) conflicts when pulling Message-ID: <20060303142413.GB16456@diana.vm.bytemark.co.uk> In-Reply-To: On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote: > On 27/02/06, Catalin Marinas 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