Hi,

On Tue, Jul 08, 2008, Jakub Narebski wrote:
quoted text
> 1. Splitting a patch
[...]
quoted text
> Currently I don't see easy way to do this with git-sequencer.

I've needed this, too, and I've added this use case in the EXAMPLES
section that will be included in the next patchset.
Basically it is the same as the rebase documentation says:
during a pause (by "edit" or "pause" insn) reset to HEAD^, add only
those parts to the index you want to have in the first patch and commit
and then repeat this.

When I've experienced this need the first time, I thought about how
sequencer could ease that.
A first idea was something like "take only files X, Y, Z from commit ..."
or a --exclude as patch has.
But often splitting a patch is not done file-wise, but hunk-wise or even
line-wise.
So my second idea was to add an option to "pause" that just invokes
the "reset HEAD^". That makes it easy, I think.
How should this option be called?

quoted text
> 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.

Imho the patch generation should be done by git-rebase.

quoted text
> 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>"?

That seems to be useful indeed and reminds me of
"git bisect run <script>".
Perhaps it's also better to call it "run" so that it is a generic
way of running scripts from sequencer and if they fail, sequencer
will pause, if they pass, everything goes on.

What about this?


run [--dir=<path>] [--] <cmd> <args>...::
	Run command `<cmd>` with arguments `<args>`.
	Pause (conflict-like) if exit status is non-zero.
+
If `<path>` is set, sequencer will change directory to `<path>`
before running the command and change back after exit.



Regards,
  Stephan


-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html