Matthieu Moy <[email protected]> writes:
> David <[email protected]> writes:
>
>> I'm not sure that rebase could predict the new hashes without actually
>> creating
>> the prior commits? So maybe the "short" SHA1 is "too short"?
>
> It's OK to show the short sha1 to the user, but "git rebase" could and
> should expand these to complete sha1 right after the editor is closed. I
> think that's what Yann means.
Yes, any "short" is by definition "too short". I agree that it is
OK to show short one in "rebase -i" instruction sheet, as they are
uniquely generated before the actual replaying of commits begins,
and it is a sensible thing to do to convert them to the full form
before starting to do the real work.
It could be something as simple like this (not tested).
git-rebase--interactive.sh | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..6766b44 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -678,6 +678,23 @@ skip_unnecessary_picks () {
die "Could not skip unnecessary pick commands"
}
+# expand shortened commit object name to the full form
+expand_todo_commit_names () {
+ while read -r command rest
+ do
+ case "$command" in
+ '#'*)
+ ;;
+ *)
+ sha1=$(git rev-parse --verify --quiet ${rest%% *})
+ rest="$sha1 ${rest#* }"
+ ;;
+ esac
+ printf '%s\n' "$command${rest:+ }$rest"
+ done <"$todo" >"$todo.new" &&
+ mv -f "$todo.new" "$todo"
+}
+
# Rearrange the todo list that has both "pick sha1 msg" and
# "pick sha1 fixup!/squash! msg" appears in it so that the latter
# comes immediately after the former, and change "pick" to
@@ -979,6 +996,8 @@ git_sequence_editor "$todo" ||
has_action "$todo" ||
die_abort "Nothing to do"
+expand_todo_commit_names
+
test -d "$rewritten" || test -n "$force_rebase" || skip_unnecessary_picks
output git checkout $onto || die_abort "could not detach HEAD"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
