> What's the git equivalent of `hg qrefresh`? What about when there are other commits on top of the current one?
There is no direct equivalent as far as I know (short of using one of the quilt-like tools built on top of git) apart from amend for topmost commits, but it's easy enough to do with rebase —interactive (or rewrite in mercurial).
> In this case I meant that you don't qfinish the patches right away
Then they're not changesets, they're patches.
> You leave them as patches while you submit them to the mailing list.
You can do that just as easily from a local branch.
> You're talking about pushing to a public repository, which is different than patch bombing a mailing list.
I'm not talking about anything.
> It's a bit more complicated, but it does have the nice effect of giving you a "history" of a series of changesets. I don't know how you'd do that with git.
I don't either.
> I agree that you can do those things in git -- I'm only say that it doesn't encourage it
And I disagree with your assertion that mercurial encourages it.
> The existence of the index actually encourages doing it the wrong way: checking in states of code you've never tested.
Not any more than the ability to `qrefresh` only a subset of your working copy.
> No, Mercurial doesn't force you to do it right, but MQ and its qpush/qpop provide an easy way to do it the right way if you want to
And it's almost as easy to do the same thing with git.
Comments
> What's the git equivalent of `hg qrefresh`? What about when there are other commits on top of the current one?
There is no direct equivalent as far as I know (short of using one of the quilt-like tools built on top of git) apart from amend for topmost commits, but it's easy enough to do with rebase —interactive (or rewrite in mercurial).
> In this case I meant that you don't qfinish the patches right away
Then they're not changesets, they're patches.
> You leave them as patches while you submit them to the mailing list.
You can do that just as easily from a local branch.
> You're talking about pushing to a public repository, which is different than patch bombing a mailing list.
I'm not talking about anything.
> It's a bit more complicated, but it does have the nice effect of giving you a "history" of a series of changesets. I don't know how you'd do that with git.
I don't either.
> I agree that you can do those things in git -- I'm only say that it doesn't encourage it
And I disagree with your assertion that mercurial encourages it.
> The existence of the index actually encourages doing it the wrong way: checking in states of code you've never tested.
Not any more than the ability to `qrefresh` only a subset of your working copy.
> No, Mercurial doesn't force you to do it right, but MQ and its qpush/qpop provide an easy way to do it the right way if you want to
And it's almost as easy to do the same thing with git.