On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote: >> If a sample of git users would expect "git rebase -i" to let you >> rebase the last few commits, then it doesn't really matter all that >> much what N is. 10 seems a reasonable default as any. > > That's exactly the problem. Most git users aren't going to expect "git > rebase -i" to let you "rebase the last few commits". > > Rebase is mostly used, talked about, and conceptualized in terms of > rebasing onto other _branches_. Actually, I don't think that's true anymore with "rebase -i"; it is probably most convenient way in core git to rewrite the history of a patchset. E.g., a core part of my workflow as a contributor is: $ git checkout -b jk/topic origin $ while true; do hack hack hack; commit commit commit; done $ git rebase -i origin which gives me a list of everything on the topic, ready to be reordered, squashed, or edited as appropriate. -Peff -- 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
