git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Nyman <m.nyman@iki.fi>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Nicola Paolucci <npaolucci@atlassian.com>
Subject: Re: [PATCH] contrib/subtree: add repo url to commit messages
Date: Thu, 3 Mar 2016 13:42:22 +0200	[thread overview]
Message-ID: <20160303114222.GA9814@iki.fi> (raw)
In-Reply-To: <CAPig+cRTz_VYt-2q9y0+COhVCezMs-7Sm-v=jvhUxUSRhiN93g@mail.gmail.com>

On 2016-02-26 14:49-0500, Eric Sunshine wrote:
>On Fri, Feb 26, 2016 at 3:28 AM, Mathias Nyman <m.nyman@iki.fi> wrote:
>> On 2016-02-25 17:23-0500, Eric Sunshine wrote:
>>> On Tue, Feb 23, 2016 at 5:25 AM, Mathias Nyman <mathias.nyman@iki.fi>
>>> wrote:
>>>> -       cat <<-EOF
>>>> -               $commit_message
>>>> -
>>>> -               git-subtree-dir: $dir
>>>> -               git-subtree-mainline: $latest_old
>>>> -               git-subtree-split: $latest_new
>>>> -       EOF
>>>> +       echo $commit_message
>>>> +       echo
>>>> +       echo git-subtree-dir: $dir
>>>> +       echo git-subtree-mainline: $latest_old
>>>> +       echo git-subtree-split: $latest_new
>>>
>>> It's not clear why this code was changed to use a series of echo's in
>>> place of the single cat. Although the net result is the same, this
>>> appears to be mere code churn. If your intention was to make it
>>> similar to how squash_msg() uses a series of echo's, then that might
>>> make sense, however, rejoin_msg() uses the same single 'cat' as
>>> add_msg(), so inconsistency remains. Thus, it's not clear what the
>>> intention is.
>>
>> Using a mixutre of heredoc and echo felt messy. But I'll change it
>> back to heredoc here, and through out the commit aim for near-zero
>> refactoring.
>
>An alternative would be to have a preparatory patch which unifies the
>heredoc vs. echo issue across add_msg(), squash_msg(), rejoin_msg(),
>but I wouldn't insist upon it (that's just more work for you). Leaving
>this bit alone is a reasonable choice.
>
>>>> +       repo="$4" # optional
>>>>         newsub_short=$(git rev-parse --short "$newsub")
>>>> -
>>>> +
>>>
>>>
>>> Okay, this change is removing an unnecessary tab. Perhaps the commit
>>> message can say that the patch fixes a few whitespace inconsistencies
>>> while touching nearby code.
>>
>> Will undo the whitespace fixing.
>
>Oh, I wasn't insisting that you should undo the whitespace fix.
>Typically, you'd make such fixes in a preparatory cleanup patch, but
>since there are only two cases here that you've fixed, it probably
>wouldn't hurt to retain them (if that's all there are in the file).
>The reason I suggested mentioning the whitespace fixes in the commit
>message is to let the reviewer know that they weren't cases of you
>accidentally making unwanted whitespace changes (like inserting tabs
>rather than removing them). As it was, as a reviewer, I had to go
>through extra effort to determine whether you had made a fix or had
>accidentally botched something.
>

Not fixing any whitespace inconsistencies felt like the consistent way to
go in this commit.

Would be great to have some feedback on the core idea of this change,
before spending more time on it. Anyone?

>>>>  cmd_merge()
>>>>  {
>>>> -       revs=$(git rev-parse $default --revs-only "$@") || exit $?
>>>> +       revs=$(git rev-parse $default --revs-only "$1") || exit $?
>>>
>>> Why is this variable still named 'revs' (plural) since you're only
>>> passing in $1 now rather than $@?
>>
>> Because technically the result can still be more then one rev I guess.
>> Consider 'git rev-parse HEAD~1..HEAD', which would return two hashes.
>
>Okay, so I was missing something obvious.

  reply	other threads:[~2016-03-03 11:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 10:25 [PATCH] contrib/subtree: add repo url to commit messages Mathias Nyman
2016-02-25 22:23 ` Eric Sunshine
2016-02-26  8:28   ` Mathias Nyman
2016-02-26 19:49     ` Eric Sunshine
2016-03-03 11:42       ` Mathias Nyman [this message]
2016-05-21 22:52 ` David A. Greene
2016-05-31 12:19   ` Mathias Nyman

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=20160303114222.GA9814@iki.fi \
    --to=m.nyman@iki.fi \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=npaolucci@atlassian.com \
    --cc=sunshine@sunshineco.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).