On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote: > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Mar 04 01:25:04 2006
This archive was generated by hypermail 2.1.8 : 2006-03-04 01:25:17 EST