From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>, git@vger.kernel.org
Subject: Re: [PATCH] submodule: spell out API of submodule_move_head
Date: Mon, 9 Oct 2017 17:55:20 -0700 [thread overview]
Message-ID: <20171010005520.GN19555@aiede.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqmv4zrfye.fsf@gitster.mtv.corp.google.com>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Junio C Hamano wrote:
>>> This is not a new issue (the removed comment did not mention this at
>>> all), but is it correct to say that updates to "index and work tree"
>>> was as if we did "git -C $path checkout new" (and of course, HEAD in
>>> the $path submodule must be at 'old')?
>>
>> I don't understand the question. This comment doesn't say it's like
>> "git checkout" --- are you saying it should?
>
> No, I am pointing out that this comment does not say what it's like
> clearly enough. s/is it correct/am I correct/ would have been less
> prone to get misunderstood, I guess.
No problem. I think a word or two about how it's like read-tree
in the docstring could be an improvement.
> If it behaves like two-tree "read-tree -m -u", I'd say that the best
> explanation an average developer would understand is that the update
> done to "index and work tree" is like using 'git checkout' to switch
> to the branch whose tip is 'new'.
If it says it's like "git checkout", then I fear that can just lead to
more confusion, since "git checkout" does a number of things (e.g.
updating the HEAD symref) that this function does not do.
It could say that it's like "git reset --keep", I suppose.
[...]
>>> What should happen if 'old' does not match reality (i.e. old is NULL
>>> but HEAD does point at some commit, old and HEAD are different,
>>> etc.)? Should the call be aborted?
>>
>> No.
>
> ... and that is because?
>
> When does it make sense to do a two-tree "read-tree -m -u" giving
> the 'old' that is very different from the real 'old' tree-ish that
> corresponds to where your index started at?
Because that is not the purpose of the function.
The caller is responsible for setting 'old' appropriately. A word or
two in that direction would not be a terrible thing.
All that said, I want this function to go away completely. :)
Documenting how it currently behaves is just a good way to understand
what is happening when doing so.
Thanks,
Jonathan
next prev parent reply other threads:[~2017-10-10 0:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 22:06 [PATCH] submodule: spell out API of submodule_move_head Stefan Beller
2017-10-09 22:22 ` Jonathan Nieder
2017-10-10 0:16 ` Junio C Hamano
2017-10-10 0:27 ` Jonathan Nieder
2017-10-10 0:42 ` Junio C Hamano
2017-10-10 0:55 ` Jonathan Nieder [this message]
2017-10-10 1:06 ` Junio C Hamano
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=20171010005520.GN19555@aiede.mtv.corp.google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sbeller@google.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).