git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Branchaud <marcnarc@xiplink.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: Phil Hord <phil.hord@gmail.com>,
	Leif Gruenwoldt <leifer@gmail.com>,
	"Andreas T.Auer" <andreas.t.auer_gtml_37453@ursus.ath.cx>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [RFC/PATCH] add update to branch support for "floating submodules"
Date: Tue, 13 Dec 2011 17:42:40 -0500	[thread overview]
Message-ID: <4EE7D4E0.5000305@xiplink.com> (raw)
In-Reply-To: <4EE7C15A.3040501@web.de>

On 11-12-13 04:19 PM, Jens Lehmann wrote:
> Am 13.12.2011 16:35, schrieb Marc Branchaud:
>> I'd prefer to have floating be explicitly configured on a per-branch (or
>> per-branch-glob) basis.  So in addition to what Jens described yesterday [1]
>> to configure an individual submodule's floating branch, I suggest there also
>> be a new section in the .gitmodules file for configuring the super-repo's
>> floating branches, e.g.
>>
>> 	[super]
>> 		floaters = refs/heads/master refs/heads/dev*
>>
>> 	[submodule "Sub1"]
>> 		path = foo/bar
>> 		branch = maint
>> 		url = ...
>>
>> 	[submodule "Sub2"]
>> 		path = other/place
>> 		url = ...
> 
> Hmm, but you can have different .gitmodules files in different branches of
> the superproject, no?

Yes.  I'm not sure I see that as a problem though.

> Why not just have the "branch = maint" setting for
> "Sub1" in the master and the dev branches .gitmodules file and drop it in
> the other branches?

Because I think that's an error-prone approach.

If the user creates a topic branch off (an ancestor) of master, git doesn't
know if the user wants floating submodules or not.  If this is a bugfix
topic, the user would have to edit .gitmodules to turn off floating.  But
that modified .gitmodules is too easily committed to the branch, and once it
gets merged back into master suddenly master loses its "floating" feature.

What's more, less-sophisticated users would be wary of editing an "internal"
file like .gitmodules.

Instead I think it's more intuitive for the repository to define which
branches get floating submodules and which don't, and IMO a list of
names/globs is a good way to do that.  The repo's users would need to be
aware of what the magic branch names are, but I think that's easily
communicated in the floating-submodule scenarios I've seen posted.  Git could
also help by telling the user, when a branch is created or it's name is
displayed, whether or not it's got floating submodules.

		M.

  reply	other threads:[~2011-12-13 22:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 17:40 [RFC/PATCH] add update to branch support for "floating submodules" Heiko Voigt
2011-11-09 18:01 ` Junio C Hamano
2011-11-29 22:08   ` Heiko Voigt
2011-12-10  5:50     ` Leif Gruenwoldt
2011-12-10  6:19       ` Jonathan Nieder
2011-12-10  6:30       ` Junio C Hamano
2011-12-10 15:27         ` Leif Gruenwoldt
2011-12-12 15:34           ` Andreas T.Auer
2011-12-12 18:04             ` Leif Gruenwoldt
2011-12-12 18:42               ` Andreas T.Auer
2011-12-12 19:13                 ` Leif Gruenwoldt
2011-12-12 22:31                   ` Jens Lehmann
2011-12-12 22:56                   ` Phil Hord
2011-12-13 15:35                     ` Marc Branchaud
2011-12-13 21:19                       ` Jens Lehmann
2011-12-13 22:42                         ` Marc Branchaud [this message]
2011-12-12 19:36           ` Junio C Hamano
2011-12-13 14:17             ` Phil Hord
2011-12-13 21:09               ` Jens Lehmann
2012-01-30 21:15                 ` Phil Hord
2012-01-31 20:55                   ` Jens Lehmann
2012-01-31 22:50                     ` Phil Hord
2012-02-01 22:37                       ` Jens Lehmann
2012-02-06 17:31                         ` Phil Hord
2012-02-06 21:32                           ` Jens Lehmann
2011-12-13  0:12           ` Brandon Casey
2011-12-10 14:16   ` Gioele Barabucci

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=4EE7D4E0.5000305@xiplink.com \
    --to=marcnarc@xiplink.com \
    --cc=Jens.Lehmann@web.de \
    --cc=andreas.t.auer_gtml_37453@ursus.ath.cx \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leifer@gmail.com \
    --cc=phil.hord@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.
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).