From: Heiko Voigt <hvoigt@hvoigt.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>,
Jeremy Morton <admin@game-point.net>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Reference a submodule branch instead of a commit
Date: Wed, 5 Oct 2016 16:14:39 +0200 [thread overview]
Message-ID: <20161005141439.GD30930@book.hvoigt.net> (raw)
In-Reply-To: <xmqqlgy4szuu.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 04, 2016 at 12:01:13PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Stefan Beller <sbeller@google.com> writes:
> >
> >> I wonder if we could make that convenient for users by not tracking
> >> the submodule,
> >> i.e.
> >> * we have the information in the .gitmodules file
> >> * the path itself is in the .gitignore
> >> * no tree entry
> >>
> >> Then you can update to the remote latest branch, without Git reporting
> >> a dirty submodule locally, in fact it reports nothing for the submodule.
> >>
> >> It sounds like a hack, but maybe it's worth looking into that when
> >> people want to see that workflow.
> >
> > It IS a hack.
> >
> > But if you do not touch .git<anything> file and instead say "clone
> > this other project at that path yourself" in README, that would
> > probably be sufficient.
>
> eh,... hit send too early.
>
> It IS a hack, but having this information in .git<something> would
> mean that it can be forced to be in machine readable form, unlike a
> mention in README. I do not know if the .gitmodules/.gitignore
> combination is a sensible thing to use, but it does smell like a
> potentially useful hack.
IIRC the tree entries are the reference for submodules in the code. We
are iterating over the tree entries in many places so that change does
not seem so easy to me.
But you are right maybe we should stop arguing against this workflow and
just let people use it until they find out whats wrong with it ;)
I have another tip for Jeremy:
git config submodule.<name>.ignore all
and you will not see any changes to the submodule. Put that into your
.gitmodules and you do not see any changes to the submodules anymore.
So now the only thing missing for complete convenience is a config
option for the --remote option in 'git submodule update'.
Jeremy, does the ignore option combined with --remote what you want?
Cheers Heiko
next prev parent reply other threads:[~2016-10-05 14:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-03 18:14 Reference a submodule branch instead of a commit Jeremy Morton
2016-10-03 19:00 ` Junio C Hamano
2016-10-04 11:36 ` Heiko Voigt
2016-10-04 17:07 ` Stefan Beller
2016-10-04 17:31 ` Junio C Hamano
2016-10-04 19:01 ` Junio C Hamano
2016-10-05 14:14 ` Heiko Voigt [this message]
2016-10-05 16:13 ` Junio C Hamano
2016-10-05 18:21 ` Heiko Voigt
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=20161005141439.GD30930@book.hvoigt.net \
--to=hvoigt@hvoigt.net \
--cc=admin@game-point.net \
--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).