git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Seymour <jon.seymour@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: RFD: a submodule-like facility that tracks branches rather than  commits
Date: Mon, 3 May 2010 08:39:42 +1000	[thread overview]
Message-ID: <l2u2cfc40321005021539v573e58a5j15696d81b5e5acd5@mail.gmail.com> (raw)
In-Reply-To: <7veihuuwdj.fsf@alter.siamese.dyndns.org>

On Mon, May 3, 2010 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Has consideration ever been given to a submodule-like facility where
>> the configuration information maintained in the supermodule for the
>> submodule is not a gitlink but is instead the name of a branch (or
>> generally, a symbolic reference within the nested submodule).
>
> I think this comes up from time to time, and there was an even a slightly
> more concrete suggestion to us 0{40} in the tree object to denote such an
> entry.
>
> But once people realize that there is no single canonical authoritative
> repository whose branch heads point at the same commits for everybody in a
> distributed environment, the line of thought to touch gitlink entries gets
> retracted or discarded as a misguided idea.
>

I understand the point about there being no canonical authority,
particularly in a truly distributed environment - any use of branches
would have to imply that users followed some convention when
publishing the entire set.

On the other hand, there is actually precedent for use of convention
like that in the submodule facility - the use of relative paths to
describe the relative locations of submodule repos only really works
if everyone who publishes the supermodule uses the filesystem
structure for the directories containing the super- and sub-module
repos.

> I however don't think it would hurt to enrich .gitmodules with not just
> the repository information but with branch information to help clones
> decide which commit (other than what is recorded in the tree of the
> superproject's commit) on the named remote tracking branch to try out with
> the superproject's commit.
>
>

I can see that this could work. Presumably git submodule sync would be
modified in this case to help switch branches.

Also needed, I think, would be a way to sync the .gitmodule file with
the current submodule branch assignments.

I guess there is no reason why I cannot prototype a facility of this
kind with a local helper script. If I it ends up being useful, I'll
consider posting a patch.

jon.

  parent reply	other threads:[~2010-05-02 22:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-02 11:02 RFD: a submodule-like facility that tracks branches rather than commits Jon Seymour
2010-05-02 16:00 ` Junio C Hamano
2010-05-02 16:04   ` Dmitrijs Ledkovs
2010-05-02 22:39   ` Jon Seymour [this message]
2010-05-03  2:05     ` Junio C Hamano

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=l2u2cfc40321005021539v573e58a5j15696d81b5e5acd5@mail.gmail.com \
    --to=jon.seymour@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).