From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Williams <bmwill@google.com>,
Jonathan Nieder <jrnieder@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 0/5] Some submodule bugfixes and "reattaching detached HEADs"
Date: Mon, 1 May 2017 21:04:32 -0700 [thread overview]
Message-ID: <CAGZ79kb52QDUG0RtTXNEEpMJR1CSMYMrRHTRRvGn0-cF=HnzWw@mail.gmail.com> (raw)
In-Reply-To: <xmqqbmrcf3cn.fsf@gitster.mtv.corp.google.com>
On Mon, May 1, 2017 at 6:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Williams <bmwill@google.com> writes:
>
>> I don't know why submodules were originally designed to be in a
>> detached HEAD state but I much prefer working on branches (as I'm sure
>> many other developers do) so the prospect of this becoming the norm is
>> exciting! :D
>
> The reason is because the superproject already records where the
> HEAD in the submodule should be, when any of its commits is checked
> out. The tip of a branch (which one???)
The one as configured (submodule.NAME.branch
> in a submodule may match
> that commit, in which case there is nothing gained by having you on
> that branch,
Being on a branch has some advantages, e.g. easier pushing, not
worrying about losing commits due to gc, an easier "name" in a literal sense.
> or it may not match that commit, in which case it is
> unclear what should happen.
Yes, I anticipate this to be the main point of discussion.
> Leaving your submodule on the branch
> would mean the state of your tree as a whole does not match what the
> checkout operation in the superproject wanted to create. Resetting
> the branch would mean you may lose the history of the branch.
or telling the user via die(), that there is a mismatch.
(you may want to run git submodule update --remote to fix the situation)
> Thinking of the detached HEAD state as an implicit unnamed branch
> that matches the state the superproject checkout expects was
> conceptually one of the cleanest choices.
Assuming this is the cleanest design, we may want to change the
message of git-status, then.
Unlike the scary detached HEAD message (incl long hint), we may just
want to say
$ git status
In submodule 'foo'
You're detached exactly as the superprojects wants you to be.
Nothing to worry.
> But all of the above concentrates on what should happen immediately
> after you do a checkout in the superproject, and it would be OK for
> a sight-seer. Once you want to work in the submodules to build on
> their histories, not being on a branch does become awkward. For one
> thing, after you are done with the work in your submodule, you would
> want to update the superproject and make a commit that records the
> commit in the submodule, and then you would want to publish both the
> superproject and the submodule because both of them are now
> updated. The commit in the superproject may be on the branch that
> is currently checked out, but we don't know what branch the commit
> in the submoudule should go.
>
> The submodule.<name>.branch configuration may be a good source to
> learn that piece of information,
Glad we agree up to this point.
> but it does not fully solve the
> issue. It is OK for the tip of that branch to be at or behind the
> commit the superproject records, but it is unclear what should
> happen if the local tip of that branch is ahead of the commit in the
> superproject when checkout happens.
right. It is still unclear to me as well. I'll have to think about the
various modes of operation.
> By the way, how does this topic work with the various checkout modes
> that can be specified with submodule.<name>.update?
This series currently does not touch git-submodule, but in principle
we could just run "submodule--helper reattach-HEAD" after any operation
and then see if we can attach a HEAD (likely for "update=checkout",
but in "merge" we may want to fast-forward the branch, and in "rebase"
we might want to reset (noff) to the tip.
I'll think about this more.
Thanks,
Stefan
next prev parent reply other threads:[~2017-05-02 4:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-01 18:00 [PATCH 0/5] Some submodule bugfixes and "reattaching detached HEADs" Stefan Beller
2017-05-01 18:00 ` [PATCH 1/5] submodule_move_head: fix leak of struct child_process Stefan Beller
2017-05-01 18:06 ` Brandon Williams
2017-05-02 3:07 ` Junio C Hamano
2017-05-02 4:20 ` Stefan Beller
2017-05-01 18:00 ` [PATCH 2/5] submodule_move_head: prepare env for child correctly Stefan Beller
2017-05-02 2:04 ` Junio C Hamano
2017-05-02 4:18 ` Stefan Beller
2017-05-01 18:00 ` [PATCH 3/5] submodule: avoid auto-discovery in new working tree manipulator code Stefan Beller
2017-05-01 18:00 ` [RFC PATCH 4/5] submodule--helper: reattach-HEAD Stefan Beller
2017-05-01 18:36 ` Brandon Williams
2017-05-01 19:00 ` Stefan Beller
2017-05-01 18:00 ` [RFC PATCH 5/5] submodule_move_head: reattach submodule HEAD to branch if possible Stefan Beller
2017-05-01 18:24 ` [PATCH 0/5] Some submodule bugfixes and "reattaching detached HEADs" Brandon Williams
2017-05-02 1:35 ` Junio C Hamano
2017-05-02 4:04 ` Stefan Beller [this message]
2017-05-31 22:09 ` Stefan Beller
2017-05-02 19:32 ` [PATCHv2 0/3] Some submodule bugfixes Stefan Beller
2017-05-02 19:32 ` [PATCHv2 1/3] submodule_move_head: reuse child_process structure for futher commands Stefan Beller
2017-05-02 19:32 ` [PATCHv2 2/3] submodule: avoid auto-discovery in new working tree manipulator code Stefan Beller
2017-05-02 19:32 ` [PATCHv2 3/3] submodule: properly recurse for read-tree and checkout Stefan Beller
2017-05-02 19:42 ` [PATCHv2 0/3] Some submodule bugfixes Brandon Williams
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='CAGZ79kb52QDUG0RtTXNEEpMJR1CSMYMrRHTRRvGn0-cF=HnzWw@mail.gmail.com' \
--to=sbeller@google.com \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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).