All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Johan Herland <johan@herland.net>, git@vger.kernel.org
Subject: Re: RFC: Making submodules "track" branches
Date: Tue, 8 Jun 2010 20:23:49 +0000	[thread overview]
Message-ID: <AANLkTilYHfDrtCAcPPxB1AZnzch2ELTEiIFTW3N5LBEc@mail.gmail.com> (raw)
In-Reply-To: <4C0E9AC7.7080802@xiplink.com>

On Tue, Jun 8, 2010 at 19:32, Marc Branchaud <marcnarc@xiplink.com> wrote:
> On 10-06-08 12:09 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Jun 8, 2010 at 15:34, Marc Branchaud <marcnarc@xiplink.com> wrote:
>>>
>>> So, back to the issue at hand: Sometimes I want static (non-tracking)
>>> submodules, and sometimes I want dynamic (tracking) submodules.  IMO, this
>>> makes Ævar's proposed configuration-based approach impractical.  (Of course,
>>> I'm not looking to replicate svn's externals...)
>>
>> I'm proposing that you be able to configure how you want to handle
>> submodules on a per-submodule basis.
>
> Yes, and that's precisely the problem.  For a given submodule, sometimes it
> should track a branch and sometimes it shouldn't.  Having to edit a
> configuration to change that is impractical.

See below.

>> The exact semantics that I proposed may be impractical for some
>> reason, but the idea is that it'd be opt in. We'd perhaps have
>> multiple approaches (via config) to submodules, instead of the current
>> monolithic scheme.
>
> Opting in or out can't just be a monolithic setting for each submodule.  A
> submodule's branch tracking has to be on or off depending on the circumstances.

I don't really get what the objection is exactly. How should "branch
tracking" be achieved do you think?

Anyway, right now what we track is set in a monolithic fashion by a
combination of a commit pointer in a tree and what's being versioned
in .gitmodules. If you want to change anything that's where you have
to do it.

Why should it be any different when the submodule isn't tracking a
specific commit? I.e. when it's "track the latest version of $thingy,
whatever that is", instead of "track version $version of $thingy".

>> So if you didn't want a svn:externals like "always track trunk"
>> repository you'd just not set your superproject up to treat the
>> submodule like that.
>
> Yes, of course.
>
> I guess what I'm saying is that duplicating svn's externals doesn't seem all
> that useful to me and I'd rather see git do better.  I've no objection if
> folks want to have such a feature, but to me it's not what "submodules
> tracking branches" should be about.

Obviously I have no objection to doing better, but how specifically
should that be done? If the semantics you want are "give me the latest
version of $URL, whatever that is" then the SVN semantics are pretty
good.

  reply	other threads:[~2010-06-08 20:24 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 [this message]
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
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTilYHfDrtCAcPPxB1AZnzch2ELTEiIFTW3N5LBEc@mail.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=marcnarc@xiplink.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.