On Thu, 10 May 2007 22:02:53 +0200, Petr Baudis wrote: > > I'm sorry, I couldn't parse this. :-) > I'll try again. I like the git user interface. I like it a lot. (It's got a couple of tiny things that I would do differently if I could start over, but more importantly it has a lot of big things that I wouldn't have even thought of if I had started from scratch.) But with respect to the current topic, there are a couple of features that the git interface is missing compared to something like stg: 1. Amend a commit that's somewhere besides the tip of a branch, (rebuilding every commit that follows) 2. Re-ordering commits that exist on a branch, (again, rebuilding every commit that follows). And what I was trying to say in my confusing paragraph, is that if I look to stg to add one or both pieces of this functionality, then it comes with a lot of baggage. For example, "stg --help" lists about 38 sub-commands. And some of those are wholly unnecessary if already using git, (4 repository commands 6 working-copy commands, for example). While others exist only to allow a notion of "git commits" vs. "stg commits" and translating back and forth between them, (assimilate and uncommit for example). Now, that's not a critique of stg itself. As you say, it can work really well if you use it in a standalone fashion to track some project. I'd just love to see something more minimal, and incorporated into git itself, to address the missing functionality. Right now, "cherry-pick A..B" is all I have to suggest. But maybe later there could be some sort of push/pop addition as well, (except that obviously the name "push" isn't available as a sub-command). -Carl
Attachment:
pgpErf0zFNp0q.pgp
Description: PGP signature
