From: Junio C Hamano <gitster@pobox.com>
To: "Ping Yin" <pkufranky@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/5] git-submodule: New subcommand 'summary' (2) - hard work
Date: Sat, 12 Jan 2008 11:21:33 -0800 [thread overview]
Message-ID: <7vzlvasvcy.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <46dff0320801120424v1b780a97x8a4ecfcfe8e52f7@mail.gmail.com> (Ping Yin's message of "Sat, 12 Jan 2008 20:24:09 +0800")
"Ping Yin" <pkufranky@gmail.com> writes:
>> >
>> > I think you would want to read full 40-char sha1_src and
>> > sha1_dst with "while read", and keep that full 40-char in these
>> > variables, and use them when calling rev-parse here.
>>
>> Hmm, precision is really a problem. However, "git diff --raw" will not
>> always give full 40-char sha1, instead it will give sha1 with enough
>> length. So maybe i can use the sha1 from "git diff --raw" ?
>>
> Oh, I'm wrong. It seems 'git diff --raw' will always give full 40-char
> sha1 for submodule entry and abbreviated sha1 for blob entry.
It is not recommended to use "git diff" in scripts when you can
use one of the "git diff-*" plumbing. In this case I think you
would want "git-diff-index". Also see --abbrev option.
You can never determine how many hexdigits are "enough" from the
containing project, as it does not have to have access to the
submodule object store. That's the reason I suggested to read
full object name from diff-index and use it for error reporting
and object retrieval, and shorten it in the UI for normal status
noise.
next prev parent reply other threads:[~2008-01-12 19:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-12 7:37 [PATCH 0/5] submodule summary support Ping Yin
2008-01-12 7:37 ` [PATCH 1/5] git-submodule: New subcommand 'summary' (1) - code framework Ping Yin
2008-01-12 7:37 ` [PATCH 2/5] git-submodule: New subcommand 'summary' (2) - hard work Ping Yin
2008-01-12 7:37 ` [PATCH 3/5] git-submodule: New subcommand 'summary' (3) - limit summary size Ping Yin
2008-01-12 7:37 ` [PATCH 4/5] git-status: submodule summary support Ping Yin
2008-01-12 7:37 ` [PATCH 5/5] git-status: configurable submodule summary size Ping Yin
2008-01-12 8:36 ` [PATCH 3/5] git-submodule: New subcommand 'summary' (3) - limit " Junio C Hamano
2008-01-12 9:51 ` Ping Yin
2008-01-12 19:17 ` Junio C Hamano
2008-01-13 6:38 ` Ping Yin
2008-01-12 8:32 ` [PATCH 2/5] git-submodule: New subcommand 'summary' (2) - hard work Junio C Hamano
2008-01-12 9:48 ` Ping Yin
2008-01-12 12:24 ` Ping Yin
2008-01-12 19:21 ` Junio C Hamano [this message]
2008-01-12 11:12 ` Ping Yin
2008-01-12 19:25 ` Junio C Hamano
2008-01-13 6:28 ` Ping Yin
2008-01-12 8:18 ` [PATCH 1/5] git-submodule: New subcommand 'summary' (1) - code framework Junio C Hamano
2008-01-12 9:09 ` Ping Yin
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=7vzlvasvcy.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pkufranky@gmail.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).