From: Junio C Hamano <gitster@pobox.com>
To: "Lars Hjemli" <hjemli@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Fabian Franz" <git@fabian-franz.de>,
git@vger.kernel.org, j.sixt@viscovery.net
Subject: Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule
Date: Thu, 11 Dec 2008 16:59:06 -0800 [thread overview]
Message-ID: <7v8wqmb44l.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <8c5c35580812111631k54657bdcme8f048c77b6765eb@mail.gmail.com> (Lars Hjemli's message of "Fri, 12 Dec 2008 01:31:31 +0100")
"Lars Hjemli" <hjemli@gmail.com> writes:
> On Thu, Dec 11, 2008 at 21:42, Junio C Hamano <gitster@pobox.com> wrote:
>> I wonder if you can just set "assume unchanged" bit for the subproject
>> gitlink in the index to achieve the same goal.
>
> Using assume-unchanged works, in the sense that the modification to
> the submodule is not detected in the containing repo. But running `git
> submodule update` will checkout the sha1 recorded in HEAD, and I
> suspect Fabian wants something like the hypothetical command `git
> submodule update -b [branch]` which could do `(cd sub && git fetch &&
> git reset --hard origin/$branch)`.
Yeah, that would *also* make sense, but I think that is orthogonal issue.
You can update the state of the checkouts of subproject repositories in
any way you want. Doing so however makes "git commit -a" inconvenient to
use without assume-unchanged. The magic 0{40} which Fabian's patch
addresses the same issue in a different way.
Although I would probably detach the head at that point, rather than
resetting whatever branch happens to be checked out:
( cd sub && git fetch && git checkout origin/$branch^0 )
We also need to make sure that whatever we do we should not break
workflows that do not check out submodules that are uninteresting. So
doing the above unconditionally to all the submodules is out. In such a
sparsely populated superproject, "cd sub" would go to an empty directory,
and "git fetch" step would error out.
I did not read Fabian's patch too deeply, and do not remember what checks
it did before running "git pull". Perhaps it pulled unconditionally?
prev parent reply other threads:[~2008-12-12 1:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 15:39 [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule Fabian Franz
2008-12-11 20:42 ` Junio C Hamano
2008-12-12 0:21 ` Fabian Franz
2008-12-12 1:17 ` Junio C Hamano
2008-12-12 0:31 ` Lars Hjemli
2008-12-12 0:59 ` Junio C Hamano [this message]
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=7v8wqmb44l.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@fabian-franz.de \
--cc=git@vger.kernel.org \
--cc=hjemli@gmail.com \
--cc=j.sixt@viscovery.net \
/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).