On Wed, Aug 05, 2020 at 03:37:55PM -0400, Denton Liu wrote:
> Hi Shourya,
>
> On Wed, Aug 05, 2020 at 11:19:18PM +0530, Shourya Shukla wrote:
> > The tests in 't7401-submodule-summary.sh' were written a long time ago
> > and have some violations with respect to our CodingGuidelines such as
> > incorrect spacing in usages of the redirection operator and absence
> > of line feed between statements in case of the '|' (pipe) operator.
>
> I'm not aware of anywhere in CodingGuidelines that says you can't have
> the pipe operator on a single line. I assume you're referring to the
> part that reads
>
> If a command sequence joined with && or || or | spans multiple
> lines, put each command on a separate line and put && and || and
> | operators at the end of each line, rather than the start.
>
> Note that says "If a command sequence [...] spans multiple lines", which
> doesn't apply in our case.
>
> > Update it to match the CodingGuidelines.
> >
> > Mentored-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> > Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx>
> > Signed-off-by: Shourya Shukla <shouryashukla.oo@xxxxxxxxx>
> > ---
> > t/t7401-submodule-summary.sh | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh
> > index 9bc841d085..4439fb7c17 100755
> > --- a/t/t7401-submodule-summary.sh
> > +++ b/t/t7401-submodule-summary.sh
> > @@ -16,12 +16,13 @@ add_file () {
> > owd=$(pwd)
> > cd "$sm"
> > for name; do
> > - echo "$name" > "$name" &&
> > + echo "$name" >"$name" &&
This change is good.
> > git add "$name" &&
> > test_tick &&
> > git commit -m "Add $name"
> > done >/dev/null
> > - git rev-parse --verify HEAD | cut -c1-7
> > + git rev-parse --verify HEAD |
> > + cut -c1-7
>
> For the reason above, I disagree with this change as-is. However, one
> useful thing that you can do here is breaking the pipe up entirely. We
> want to avoid is having a git command in the upstream of a pipe. This is
> because the return code of a pipe comes from the last command executed
> so if the rev-parse fails, its return code is swallowed and we have no
> way of knowing.
>
> You could break the pipe up by storing the output of the rev-parse in an
> intermediate file and then have cut read from that file.
This is a good suggestion (I was preparing to write an email to say the
same thing, but I'm glad that I checked Denton's response before doing
so). Something like:
git rev-parse --verify HEAD >out &&
cut -c1-7 out
would suffice and be in good style.
Thanks,
Taylor
