Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> And that is very, very much the purpose of the interactive rebase.
>
>> $ git for-each-rev -x "$command" old..new
>>
>> where you can write "sh -c 'git checkout $1 && make test' -" as
>> your $command.
>
> You meant
>
> git rev-list old...new |
> while read rev
> do
> $command || break
> done
>
> ?
Yeah, if I actually felt the lack of "for-each-ref -x" a problem (I
don't), that is what I would have used instead (but with just two
dots ;-).
But you are correct to point out that I didn't consider that
"... and I want to fix right there if it breaks" is a part of the
use case, mainly because the log message said this:
In the later steps of preparing a patch series I do not want to
edit the patches any more, but just make sure the test suite
passes after each patch.
and partly I lack imagination.
If you throw in that extra "I want to fix right there if it breaks"
requirement, it makes perfect sense to make use of the sequencing
machinery we implement for "rebase -i", as the while loop above does
not give you the same sequencing without extra work.
So perhaps the idea of the patch is good with a better explanation.
--
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