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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html