Re: [PATCH v4 2/5] git-submodule summary: show commit summary

From: Ping Yin <pkufranky@gmail.com>
Date: Mar 11, 2008, 09:37 UTC
Message-ID: <46dff0320803110237t6fcd6675t48949423e14f64a5@mail.gmail.com>
In-Reply-To: <7vod9ld8iu.fsf@gitster.siamese.dyndns.org>

On Tue, Mar 11, 2008 at 3:28 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> Ping Yin <pkufranky@gmail.com> writes:
>
>  > This patch does the hard work to show submodule commit summary.
>  > ...
>
>  I've spent considerable amount of time cleaning up your commit log
>  messages for the entire series from the last round when I queued them to
>  'pu', but you seem to have discarded all of them.  As I do not have time
>  to waste doing clean-ups only to have others to discard, and I do not have
>  infinite amount of time, I won't be replacing them with this series
>  tonight.
>

Sorry about this. This is my first big patch series and I have little experience about submiting patches again and again. So i don't even see your pu series except the documentation one you have mentioned in the email (I thought other ones didn't change).

I'll resend my patches finally merging you commit log.

Show 20 quoted lines

>
>  > Signed-off-by: Ping Yin <pkufranky@gmail.com>
>
>  And you did not describe anything about the improvements from the previous
>  round anywhere.  interdiff shows that this part is somewhat different:
>
>
>  > +             then
>  > +                     case "$mod_dst" in
>  > +                             160000)
>  > +                             sha1_dst=$(GIT_DIR="$name/.git" git rev-parse HEAD)
>  > +                             ;;
>  > +                             100644)
>  > +                             sha1_dst=$(git hash-object $name)
>  > +                             ;;
>  > +                     esac
>
>  Earlier, you were ignoring the one that is not checked out anymore, but
>  now you blindly assume "rev-parse HEAD" to give you a usable sha1_dst.
>  Why?

The path will not reach here for ignored submodules. Only user-cared modules will get into the "$modules" variables (see "# Get modified modules cared by user" part).

>
>  If a path that previously was a module is changed to a symlink, what
>  happens?
>

-- 
Ping Yin