From: Marc Branchaud <marcnarc@xiplink.com>
To: Phil Hord <phil.hord@gmail.com>
Cc: 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 10:35:44 -0500 [thread overview]
Message-ID: <4EE770D0.5080702@xiplink.com> (raw)
In-Reply-To: <CABURp0rFOGQ9kAbAn65W3UAHTWbk5prH7spjJnFvL5fqzbFp1w@mail.gmail.com>
On 11-12-12 05:56 PM, Phil Hord wrote:
> On Mon, Dec 12, 2011 at 2:13 PM, Leif Gruenwoldt <leifer@gmail.com> wrote:
>> On Mon, Dec 12, 2011 at 1:42 PM, Andreas T.Auer
>> <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>>
>>> The next question is: Wouldn't you like to have the new stable branch only
>>> pulled in, when the projectX (as the superproject) is currently on that new
>>> development branch (maybe master)?
>>>
>>> But if you checkout that fixed released version 1.2.9.8, wouldn't it be
>>> better that in that case the gitlinked version of the submodule is checked
>>> out instead of some unrelated new version? I mean, when the gitlinks are
>>> tracked with the projectX commits, this should work well.
>>>
>>> And what about a maintenance branch, which is not a fixed version but a
>>> quite stable branch which should only have bugfixes. Shouldn't the auto-pull
>>> be disabled in that case, too?
>>>
>>> I think the "auto-pull" behavior should depend on the currently checked out
>>> branch. So the configuration options should allow the definition of one or
>>> more mappings.
>>
>> Yes. I think you nailed it. The floating behaviour would best be
>> configured per branch.
>
> Yes, I think you nailed it too. I've been thinking the same thing for
> a while now, but I didn't know how to express it completely. Some of
> the discussion on here last week gelled the last bits in my mind.
>
> To wit, I think I would want something like this in my project:
>
> Use gitlinks when the superproject HEAD is one of these:
> refs/heads/maint/*
> refs/heads/svn/* (historic branches)
> refs/tags/*
> <SHA1> (detached)
>
> Float on the rest, using the branch given in .gitmodules (which may be
> * to mean "use the same branch as the superproject".)
>
> But maybe it is foolish of me to keep branches where I really want
> lightweight tags. If so, I could get away with this:
>
> Float if .git/HEAD begins with "refs/heads"
> Else, use the SHA1.
Wouldn't this break creating a bugfix topic branch based on an earlier
revision of the repo? I wouldn't want such a branch to automatically give me
the latest submodules.
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 = ...
This would mean that whenever the super-repo checks out either the "master"
branch or a branch whose name starts with "dev" (assuming recursive checkouts
are on):
* The Sub1 submodule automatically checks out the tip of its
"maint" branch.
* The Sub2 submodule (lacking a "branch" variable) would not float
and would check out the commit recorded in the super-repo.
A super-repo recursive-checkout that doesn't match a floaters pattern would
work in the regular, non-floating way.
M.
[1] http://article.gmane.org/gmane.comp.version-control.git/186969
next prev parent reply other threads:[~2011-12-13 15:36 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 [this message]
2011-12-13 21:19 ` Jens Lehmann
2011-12-13 22:42 ` Marc Branchaud
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=4EE770D0.5080702@xiplink.com \
--to=marcnarc@xiplink.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.