git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Marc Branchaud <marcnarc@xiplink.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Johan Herland" <johan@herland.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org
Subject: Re: RFC: Making submodules "track" branches
Date: Wed, 09 Jun 2010 11:36:47 -0400	[thread overview]
Message-ID: <4C0FB50F.3020403@xiplink.com> (raw)
In-Reply-To: <4C0F3FA9.7000800@web.de>

On 10-06-09 03:15 AM, Jens Lehmann wrote:
> Am 09.06.2010 01:09, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>> Don't record a commit in the first place, following a branch is not bound
>>> to a special commit, so pretending to do that might do more harm than good.
>>> Just putting the 0-hash there might be the solution.
>>
>> Ugh.  Even though I understand that in some scenarios you would want to
>> say "I don't care what commit is used for this submodule---just use the
>> tip of the branch 'fred'", I don't think you want to use 0{40} in the
>> superproject.  I think it would be Ok to add such a note to .gitmodules in
>> the superproject, but I also think we should still record which _exact_
>> commit was used to test and validate such a commit in the superproject
>> when it was made.
> 
> I think we are in violent agreement here.

I too am in this camp.

If a submodule is tracking the tip of a branch, I think it's vital that
checking out the superproject's HEAD@{3 months ago} gives you the submodule
as it was in the superproject 3 months ago.  Back then, it may have been
tracking a different branch.  It may not have been tracking a branch at all.
 It may have been using a completely different repository altogether.

It's hard for me to see the utility of having the submodule reflect the
tip-of-some-branch-as-of-today when I'm looking at 3-month-old code in the
superproject.

AFAICT, Ævar's original proposal does the right thing here, because a
submodule tracking a branch would look dirty in the superproject if the
branch's HEAD doesn't match the commit ID recorded in the superproject.  So
"submodule update" would restore the submodule's state to what the
superproject says it should be.

I don't think I mind dirty branch-tracking submodules, but folks seem to find
it distasteful.  However, I believe all the proposals made so far to address
it break what I call the superproject's "historical consistency."

I wish I could come up with some way to reconcile clean branch-tracking
submodules with historical consistency, but alas my imagination is so far too
limited.  :(

		M.

  reply	other threads:[~2010-06-09 15:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07 23:29 RFC: Making submodules "track" branches Ævar Arnfjörð Bjarmason
2010-06-08  7:12 ` Johan Herland
2010-06-08 15:34   ` Marc Branchaud
2010-06-08 16:09     ` Ævar Arnfjörð Bjarmason
2010-06-08 19:32       ` Marc Branchaud
2010-06-08 20:23         ` Ævar Arnfjörð Bjarmason
2010-06-09 14:36           ` Marc Branchaud
2010-06-08 16:06   ` Jens Lehmann
2010-06-08 21:52     ` Johan Herland
2010-06-09  7:23       ` Jens Lehmann
2010-06-09  8:22         ` Johan Herland
2010-06-09 12:47           ` Steven Michalske
2010-06-09 14:37             ` Johan Herland
2010-06-08 23:09     ` Junio C Hamano
2010-06-08 23:19       ` Ævar Arnfjörð Bjarmason
2010-06-09  7:09         ` Jens Lehmann
2010-06-09  7:15       ` Jens Lehmann
2010-06-09 15:36         ` Marc Branchaud [this message]
2010-06-09 18:54           ` Ævar Arnfjörð Bjarmason
2012-11-20 11:16             ` nottrobin
2012-11-20 12:04               ` W. Trevor King

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=4C0FB50F.3020403@xiplink.com \
    --to=marcnarc@xiplink.com \
    --cc=Jens.Lehmann@web.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.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.
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).