Karl Hasselström wrote: > On 2006-02-14 10:22:51 -0500, Chuck Lever wrote: > > >>Karl Hasselström wrote: >> >> >>>One thing I would like to see in stgit is the opposite of "stg >>>commit"; instead of converting patches to regular commits, take >>>the topmost regular commits and convert them to patches. >>> >>>For example, "stg uncommit foo bar baz" would -- regardless of any >>>existing patches, applied or not -- convert the top three regular >>>commits, with comments and all, to stgit patches called foo, bar, >>>and baz. These would be already applied, at the bottom of the >>>stack. I imagine all one would have to do is to modify some stgit >>>metadata, so the operation could be really cheap. >>> >>>Of course, "stg uncommit" is allowed to reject any commit with >>>more than one parent, since those can't be represented as stgit >>>patches. >>> >>>This would perhaps not add much power to an all-stgit workflow, >>>but it would be a really convenient way to edit recent git >>>history. Sort of like a more convenient rebase. And a great way to >>>lure new users. :-) >> >>i think you want "stg pick --reverse" ? > > > No, I literally want the opposite of "stg commit", so that the > sequence "stg commit; stg uncommit" has zero net effect. gotcha. well, that would work OK for maintainers, but would be kind of strange for folks who are pulling from such a repository. how would that work? my impression of git is that you don't change stuff that's already committed. you revert changes by applying a new commit that backs out the original changes. i'm speculating, but i suspect that's why there's a "stg pick --reverse" and not a "stg uncommit." - 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.html
This archive was generated by hypermail 2.1.8 : 2006-02-15 07:58:47 EST