Thanks for reviewing.
On Fri, Jul 20, 2012 at 1:14 AM, Johannes Sixt <j.s...@viscovery.net> wrote:
> Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
>> @@ -814,7 +814,8 @@ add_pick_line () {
>> else
>> comment_out=
>> fi
>> - printf '%s\n' "${comment_out}pick $1 $2" >>"$todo"
>> + line=$(git rev-list -1 --pretty=oneline --abbrev-commit --abbrev=7 $1)
>> + printf '%s\n' "${comment_out}pick $line" >>"$todo"
>
> I don't like this. On Windows, rebase -i is already slow, and these extra
> processes will make it even slower.
I don't like it either :-(.
> Anything that can be done about this? Perhaps the rev-list call can
> generate all of the full SHA1, the short SHA1, and the subject with a
> --pretty format?
After patch 7/7, cherry is used instead of rev-list. Ideally, I would
have liked to teach "git rev-list --cherry-pick" to somehow use a
<limit> just like cherry does, but I couldn't think of a generic way
of doing that (in this case, we want to say something like "range
a..b, but drop commits that are equivalent to any in b..c"). I
actually don't remember if I gave up because I couldn't think of a
sensible way of specifying ranges like that, or if I just ran out of
time (not familiar with the revision-walking code). Now it seems to me
that something like "git rev-list a..b --not-cherry-picks b..c" makes
sense, but maybe it's just too specific and we should just support the
limited (no pun intended) case we need to emulate "git cherry", i.e.
something like "git rev-list --cherry-with-limit=a c...b". Feedback
appreciated.
Martin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
