Re: [PATCH 4/7] git-rebase--interactive.sh: look up subject in add_pick_line
- From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
- Date
- Jul 20, 2012, 15:47 UTC
- Message-ID
- <CAOeW2eHeySzEzj_8BByuz4jrc_CreLtZpTshcYsTxqBrtxyg0g@mail.gmail.com>
- In-Reply-To
- <5009135C.208@viscovery.net>
Thanks for reviewing.
On Fri, Jul 20, 2012 at 1:14 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 11 quoted lines
> 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