From: Stefan Beller <sbeller@google.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 5/5] submodule: submodule_move_head omits old argument in forced case
Date: Tue, 19 Dec 2017 14:54:53 -0800 [thread overview]
Message-ID: <CAGZ79kake8k2dM=NPwNoqB5Vkxy+k67PACz01-aXx6-njcisgQ@mail.gmail.com> (raw)
In-Reply-To: <20171219224431.GG240141@aiede.mtv.corp.google.com>
On Tue, Dec 19, 2017 at 2:44 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> I had trouble understanding what this fixes, so I'll try nitpicking a
> bit as a sideways way to address that.
>
> Stefan Beller wrote:
>
>> With the previous patch applied (fix of the same() function),
>
> This tripped me up a bit. Usually commits assume that all previous
> patches have already been applied, since that allows the maintainer to
> apply the early part of a series on one day and the later part another
> day without losing too much context.
>
> I think this intends to say something like
>
> Now that we allow recursing into an unchanged submodule (see
> "unpack-trees: Fix same() for submodules", 2017-12-19), it is
> possible for ...
yup
>
>> the
>> function `submodule_move_head` may be invoked with the same argument
>> for the `old` and `new` state of a submodule, for example when you
>> run `reset --hard --recurse-submodules` in the superproject that has no
>> change in the gitlink entry, but only worktree related change in the
>> submodule. The read-tree call in the submodule is not amused about
>> the duplicate argument.
>
> What is the symptom of read-tree being unamused? Is that a sign that
> these patches are out of order (i.e. that we should prepare to handle an
> unchanged submodule first, and then adjust the caller to pass in
> unchanged submodules)?
>
>> It turns out that we can omit the duplicate old argument in all forced
>> cases anyway, so let's do that.
>
> What is the end-user visibile effect of such a change? E.g. what
> becomes possible to a user that wasn't possible before?
>
> Among the commands you mentioned before:
>
> checkout -f
> I think I would expect this not to touch a submodule that
> hasn't changed, since that would be consistent with its
> behavior on files that haven't changed.
>
> reset --hard
> Nice! Yes, recursing into unchanged submodules is a big part
> of the psychological comfort of being able to say "you can
> always use reset --hard <commit> to get back to a known
> state".
I may have a different understanding of git commands than you do,
but a plain "checkout -f" with no further arguments is the same as
a hard reset IMHO, and could be used interchangeably?
Rehashing the "What is a submodule?" discussion, I would claim
that when its worktree is changed, we'd want checkout to restore
the submodules worktree back, so I disagree with your assessment
of checkout -f.
> read-tree -u --reset
> This is essentially the plumbing equivalent of reset --hard,
> so it makes sense for them to be consistent. Ok.
>
> Based on the checkout -f case, if I've understood correctly then patch
> 4/5 goes too far on it (but I could easily be convinced otherwise).
Without 4/5 we cannot implement hard reset recursing into submodules
as it is functionally the same as forced checkout except when we
differentiate them
on a higher layer?
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>> submodule.c | 4 +++-
>> t/lib-submodule-update.sh | 2 +-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/submodule.c b/submodule.c
>> index fa25888783..db0f7ac51e 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1653,7 +1653,9 @@ int submodule_move_head(const char *path,
>> else
>> argv_array_push(&cp.args, "-m");
>>
>> - argv_array_push(&cp.args, old ? old : EMPTY_TREE_SHA1_HEX);
>> + if (!(flags & SUBMODULE_MOVE_HEAD_FORCE))
>> + argv_array_push(&cp.args, old ? old : EMPTY_TREE_SHA1_HEX);
>
> Interesting. What is the effect when old != new?
when the force flag is set we mostly pass in old="HEAD", which is
technically correct,
but not a sha1. (I assume you want to know what happens when two unequal sha1s
are given; for that it will perform a 2 way merge instead of a complete reset)
Thanks,
Stefan
next prev parent reply other threads:[~2017-12-19 22:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 22:26 [PATCH 0/5] Fix --recurse-submodules for submodule worktree changes Stefan Beller
2017-12-19 22:26 ` [PATCH 1/5] t/lib-submodule-update.sh: clarify test Stefan Beller
2017-12-19 22:26 ` [PATCH 2/5] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules Stefan Beller
2017-12-22 19:34 ` Junio C Hamano
2017-12-27 19:27 ` Stefan Beller
2017-12-19 22:26 ` [PATCH 3/5] t/lib-submodule-update.sh: add new test for submodule internal change Stefan Beller
2017-12-19 22:31 ` Jonathan Nieder
2017-12-19 22:35 ` Stefan Beller
2017-12-19 22:26 ` [PATCH 4/5] unpack-trees: Fix same() for submodules Stefan Beller
2017-12-19 22:26 ` [PATCH 5/5] submodule: submodule_move_head omits old argument in forced case Stefan Beller
2017-12-19 22:44 ` Jonathan Nieder
2017-12-19 22:54 ` Stefan Beller [this message]
2017-12-19 23:15 ` Jonathan Nieder
2017-12-20 0:01 ` Jonathan Nieder
2017-12-20 19:36 ` Stefan Beller
2017-12-20 19:38 ` Stefan Beller
2017-12-27 22:57 ` [PATCHv2 0/5] Fix --recurse-submodules for submodule worktree changes Stefan Beller
2017-12-27 22:57 ` [PATCHv2 1/5] t/helper/test-lazy-name-hash: fix compilation Stefan Beller
2017-12-27 22:57 ` [PATCHv2 2/5] t/lib-submodule-update.sh: clarify test Stefan Beller
2017-12-27 22:57 ` [PATCHv2 3/5] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules Stefan Beller
2017-12-27 22:57 ` [PATCHv2 4/5] unpack-trees: oneway_merge to update submodules Stefan Beller
2018-01-02 19:43 ` Junio C Hamano
2018-01-02 23:04 ` Stefan Beller
2018-01-03 1:12 ` [PATCHv3 0/5] Fix --recurse-submodules for submodule worktree changes Stefan Beller
2018-01-03 1:12 ` [PATCH 1/5] t/helper/test-lazy-name-hash: fix compilation Stefan Beller
2018-01-03 1:12 ` [PATCH 2/5] t/lib-submodule-update.sh: clarify test Stefan Beller
2018-01-03 1:12 ` [PATCH 3/5] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules Stefan Beller
2018-01-03 1:12 ` [PATCH 4/5] unpack-trees: oneway_merge to update submodules Stefan Beller
2018-01-03 1:12 ` [PATCH 5/5] submodule: submodule_move_head omits old argument in forced case Stefan Beller
2018-01-03 20:49 ` [PATCHv3 0/5] Fix --recurse-submodules for submodule worktree changes Junio C Hamano
2018-01-03 21:16 ` Stefan Beller
2018-01-05 20:03 ` [PATCHv4 0/4] " Stefan Beller
2018-01-05 20:03 ` [PATCHv4 1/4] t/lib-submodule-update.sh: clarify test Stefan Beller
2018-01-05 20:03 ` [PATCHv4 2/4] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules Stefan Beller
2018-01-05 20:03 ` [PATCHv4 3/4] unpack-trees: oneway_merge to update submodules Stefan Beller
2018-01-05 20:03 ` [PATCHv4 4/4] submodule: submodule_move_head omits old argument in forced case Stefan Beller
2018-01-09 22:45 ` [PATCHv4 0/4] Fix --recurse-submodules for submodule worktree changes Junio C Hamano
2017-12-27 22:57 ` [PATCHv2 5/5] submodule: submodule_move_head omits old argument in forced case Stefan Beller
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGZ79kake8k2dM=NPwNoqB5Vkxy+k67PACz01-aXx6-njcisgQ@mail.gmail.com' \
--to=sbeller@google.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).