On 2007-04-19 16:30:12 -0700, Junio C Hamano wrote:
> But in practice, after 'git rebase' stops on a conflicting merge, I
> spend many braincycles to come up with a sensible merge and then
> many CPU cycles to run test, and by the time I do the final "git
> diff" to make sure everything look right and "update-index" them, I
> often end up getting confused and find me asking this question: what
> was I doing? Was I resolving the merge because I merged, or was I in
> the middle of a rebase, or was I applying from a mailbox?
This is the main selling point of StGIT, in my opinion. It keeps track
of stuff for you when you rebase, so you won't accidentally forget
things. The extra help isn't needed much when everything goes
smoothly, but as soon as you get a conflict or three in the middle of
rebasing a largish stack, it's invaluable to just be able to say "stg
series" to see which patches have been applied to HEAD, and which are
still floating in limbo.
The usability increase is very palpable; without it, I wouldn't even
attempt many of the rebasings I do, even though they are technically
perfectly possible to do with just git.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: 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