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.

> +     git rev-list $revisions --reverse --left-right --topo-order |
>       sed -n "s/^>//p" |
> -     while read -r shortsha1 rest
> +     while read -r sha1
>       do
> -             sha1=$(git rev-parse $shortsha1)
>               if test -z "$rebase_root"
...
> -                     add_pick_line $shortsha1 "$rest"
> +                     add_pick_line $sha1
>               fi

This is 'rebase -p' case, and you trade the new processes for some old ones.

> +     git rev-list $revisions --reverse --left-right --topo-order \
> +             --no-merges --cherry-pick |
>       sed -n "s/^>//p" |
> -     while read -r shortsha1 rest
> +     while read -r sha1
>       do
> -             add_pick_line $shortsha1 "$rest"
> +             add_pick_line $sha1
>       done

But in the regulare case, you don't; the processes are really new.

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?

-- Hannes
--
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

Reply via email to