| Message ID | 20190127192740.8678-1-svenvh@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] git-submodule.sh: shorten submodule SHA-1s using rev-parse | expand |
On Sun, Jan 27, 2019 at 2:28 PM Sven van Haastregt <svenvh@gmail.com> wrote: > Until now, `git submodule summary` was always emitting 7-character > SHA-1s that have a higher chance of being ambiguous for larger > repositories. Use `git rev-parse --short` instead, which will > determine suitable short SHA-1 lengths. > > We cannot rely on always successfully invoking `git rev-parse` in the > submodule directory. Keep the old method using `cut` as a fallback. > > Signed-off-by: Sven van Haastregt <svenvh@gmail.com> > --- > diff --git a/git-submodule.sh b/git-submodule.sh > @@ -850,8 +850,16 @@ cmd_summary() { > + # Ensure we have crudely abbreviated SHA-1s as fallback in case > + # rev-parse fails to shorten the SHA-1s. > sha1_abbr_src=$(echo $sha1_src | cut -c1-7) > sha1_abbr_dst=$(echo $sha1_dst | cut -c1-7) > + > + sha1_abbrev=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_src) && > + sha1_abbr_src=$sha1_abbrev > + sha1_abbrev=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_dst) && > + sha1_abbr_dst=$sha1_abbrev This could be made a bit easier to follow by using indentation and || rather than &&. For instance, rewriting the entire block as: # Shorten with hard-coded fallback if rev-parse fails sha1_abbr_src=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_src || echo $sha1_src | cut -c1-7) sha1_abbr_dst=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_dst || echo $sha1_dst | cut -c1-7) In fact, the code is clear enough that the comment isn't even needed. By the way, if git-rev-parse does fail, is it going to produce an error message on stderr that needs to be suppressed?
Eric Sunshine <sunshine@sunshineco.com> writes: > This could be made a bit easier to follow by using indentation and || > rather than &&. For instance, rewriting the entire block as: > > # Shorten with hard-coded fallback if rev-parse fails > sha1_abbr_src=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_src || > echo $sha1_src | cut -c1-7) > sha1_abbr_dst=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_dst || > echo $sha1_dst | cut -c1-7) > > In fact, the code is clear enough that the comment isn't even needed. > > By the way, if git-rev-parse does fail, is it going to produce an > error message on stderr that needs to be suppressed? All good points ;-).
diff --git a/git-submodule.sh b/git-submodule.sh index 5e608f8bad..5bd724e63b 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -850,8 +850,16 @@ cmd_summary() { ;; esac + # Ensure we have crudely abbreviated SHA-1s as fallback in case + # rev-parse fails to shorten the SHA-1s. sha1_abbr_src=$(echo $sha1_src | cut -c1-7) sha1_abbr_dst=$(echo $sha1_dst | cut -c1-7) + + sha1_abbrev=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_src) && + sha1_abbr_src=$sha1_abbrev + sha1_abbrev=$(GIT_DIR="$name/.git" git rev-parse --short $sha1_dst) && + sha1_abbr_dst=$sha1_abbrev + if test $status = T then blob="$(gettext "blob")"
Until now, `git submodule summary` was always emitting 7-character SHA-1s that have a higher chance of being ambiguous for larger repositories. Use `git rev-parse --short` instead, which will determine suitable short SHA-1 lengths. We cannot rely on always successfully invoking `git rev-parse` in the submodule directory. Keep the old method using `cut` as a fallback. Signed-off-by: Sven van Haastregt <svenvh@gmail.com> --- Differences since v1: Keep the old method using `cut` as a fallback. git-submodule.sh | 8 ++++++++ 1 file changed, 8 insertions(+)