git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Henigan <tim.henigan@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] contrib: added git-diffall
Date: Tue, 21 Feb 2012 21:02:43 -0500	[thread overview]
Message-ID: <CAFouetiLmK3dXLRkBh+cTNA_OMPS77xo8z95WK5y4tk-o-UUog@mail.gmail.com> (raw)
In-Reply-To: <7vd397g8ic.fsf@alter.siamese.dyndns.org>

Thank you for taking the time to review this patch.  I appreciate it.


On Tue, Feb 21, 2012 at 4:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tim Henigan <tim.henigan@gmail.com> writes:

>> +#!/bin/bash -e
>
> Does this have to be bash-only (iow, infested with bash-isms beyond
> repair), or is you wrote this merely from inertia?

There is no specific reason it must be bash.  I changed from
"#!/bin/sh" to "#!/bin/bash -e" due to a bug report from a user on
Ubuntu [1].  The user reported that:

    "If you use /bin/sh on ubuntu you get the dash shell instead of bash shell.
    This causes git_merge_tool_path to fail. The error isn't trapped,
so it exits
    without displaying anything and without cleaning up."

Given that all the other scripts distributed with git use /bin/sh, I
will change this script to match.


> The following is only after a cursory scanning, so there may be other
> things that needs fixing, but anyway:
>
>  - Don't use "which" in scripts.  Its output is not machine parseable, and
>   exit code is not reliable, across platforms.  It is only meant for
>   consumption by human who can read English (or natural language in the
>   current locale).

I used "which" in two places.  Both were added to support problems
with missing standard tools on certain platforms (missing mktemp on
msysgit and missing option from tar on Mac [2]).  Is there some other
standard way to detect the platform or if certain utils are present?

>> +                             if test -z "$paths"
>> +                             then
>> +                                     paths=$1
>> +                             else
>> +                                     paths="$paths $1"
>> +                             fi
>
> Just a style tip; if you are going to let shell $IFS split this list
> anyway, it is customary to write the above as
>
>        paths="$paths$1 "

Nice...I will change to use this format.


>> +             git diff --name-only "$left"..."$right" -- $paths > "$tmp"/filelist
>
>        git diff ... -- $paths >"$tmp/filelist"
... <snip>
>        mkdir -p "$tmp/$left_dir" "$tmp/$right_dir"

Will change all instances.


>> +             if test -n "$compare_staged"
>> +             then
>> +                     ls_list=$(git ls-tree HEAD $name)
>> +                     if test -n "$ls_list"
>> +                     then
>> +                             mkdir -p "$tmp"/"$left_dir"/"$(dirname "$name")"
>> +                             git show HEAD:"$name" > "$tmp"/"$left_dir"/"$name"
>> +                             fi
>> +                     else
>> +                             mkdir -p "$tmp"/"$left_dir"/"$(dirname "$name")"
>> +                             git show :"$name" > "$tmp"/"$left_dir"/"$name"
>> +             fi
>
> That's misleadingly indented.  First I thought "in what case would we want
> to switch the LHS between HEAD:$path and :$path when doing diff --cached?"
> but the overindented four lines starting from the funny "fi" is about non
> cached case.

That is embarrassing.  I will fix it.

<snip>

>> +             find "$tmp/$right_dir" -type f|while read file; do
>> +                     cp "$file" "$git_top_dir/${file#$tmp/$right_dir/}"
>> +             done
>
> Why is this loop written in such a dense way?  Everything else (except for
> that misindented part) were almost to our CodingStyle and was fairly easy
> to read, though.

I missed this in my style cleanup.  I will fix it.


>> +     fi
>> +
>> +     # Remove the tmp directory
>> +     rm -rf "$tmp"
>> +}
>> +
>> +trap cleanup EXIT
>
> Does this even trigger?  This is not Perl that parses and runs set-up code
> before executing everything else, so I suspect this last line amounts to
> the same thing as writing just
>
>        cleanup
>
> without trap nor signal names.

The cleanup triggers on all the platforms I have tested (Ubuntu,
msysgit, Mac).  I could change it, but for me it has "just worked".


> If you are to set up temporary files or directories that you want to clean
> up, a good discipline is to follow this order:
>
>  - define variable(s) to hold the temporary locations, e.g.
>    tmpdir=$(mktemp ...)
>
>  - set the trap before starting to use these temporary locations, e.g.
>    trap 'rm -rf "$tmpdir' 0 1 2 3 15
>
>  - and then start populating tmpdir and do whatever you want to do.

I will review the changes needed for this before submitting v2 of my patch.

[1]: https://github.com/thenigan/git-diffall/pull/9
[2]: https://github.com/thenigan/git-diffall/pull/2#issuecomment-498472

  reply	other threads:[~2012-02-22  2:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21  0:59 [PATCH] contrib: added git-diffall Tim Henigan
2012-02-21 21:51 ` Junio C Hamano
2012-02-22  2:02   ` Tim Henigan [this message]
2012-02-22  2:41     ` Junio C Hamano
2012-02-22  9:15       ` David Aguilar
2012-02-22 20:14         ` Tim Henigan
2012-02-22 21:06           ` Junio C Hamano
2012-02-22 10:05 ` Stefano Lattarini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFouetiLmK3dXLRkBh+cTNA_OMPS77xo8z95WK5y4tk-o-UUog@mail.gmail.com \
    --to=tim.henigan@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).