On Sat, 5 July 2008, Stephan Beyer wrote: > +git-sequencer(1) > +TODO FILE FORMAT > +edit <commit>:: > +mark <mark>:: > +merge [options] <commit-ish1> <commit-ish2> ... <commit-ishN>:: > +pick [options] <commit>:: > +patch [options] <file>:: > +pause:: > +ref <ref>:: > +reset <commit-ish>:: > +squash [options] <commit>:: > +squash [options] --from <mark>:: A few comments and ideas: 1. Splitting a patch I cannot comment well on git-sequencer, as I have started using StGIT patch management interface instead of git-rebase in times when there were no "git rebase --interactive". Nevertheless working with StGIT is a bit similar to working with interactive rebase... I don't find myself wanting to join two patches into one (to squadh a commit) perhaps because when I want to add something to a commit (to a patch) I simply go to this patch, edit files, and refresh the patch. From time to time however I find myself SPLITTING a patch, for example extracting something added "by the way"/"while at it" into separate commit (like late separate better documenting project_index file format from adding optional description field to project_index file format). Currently I don't see easy way to do this with git-sequencer. 2. Patch based rebase git-rebase by default, and for speed, uses git-format-patch / git-am pipeline (utilizing '--rebasing' option to git-am to avoid changing commit messages, even if they do not follow commit message conventions). If you want for plain "git rebase" to use git-sequencer, it should be easy to support this "engine"; therefore perhaps it would be good to add some equivalent of "git format-patch" to the TODO file format. 3. Checking rebase Usually when you are interacting with upstream by sending patches by email, the last part before sending series of patches is git-rebase on top of current work. It would be nice if there were some way to have "git rebase" (via git-sequencer) to check that all commits (perhaps with some explicitly stated in TODO file exceptions) passes pre-commit hook (checking for whitespaces and conflict markers), and if possibly also either test suite, or relevant parts of test suite. So perhaps extending TODO format by "check <script>" or "check-all <script>"? I'm just not sure if it is worth adding to TOD file format... -- Jakub Narebski Poland -- 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
