Thread (14 messages) flat view 14 messages, 3 authors, 2016-06-15

Re: [PATCH 4/7] git-rebase--interactive.sh: look up subject in add_pick_line

From: Martin von Zweigbergk <hidden>
Date: 2016-06-15 22:54:17

Thanks for reviewing.

On Fri, Jul 20, 2012 at 1:14 AM, Johannes Sixt [off-list ref] wrote:
Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
quoted
@@ -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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help