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

On Wed, Jun 9, 2010 at 15:36, Marc Branchaud <marcnarc@xiplink.com> wrote:
> 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.  :(

I think the two concepts are fundimentally at odds with each other,
and that that's completely fine.

Sometimes you're promiscuous enough with your history that you don't
care about being able to go back in time, beyond checking out both
trees as they were at some given time that is. As Johan and others
point out above you could get around that with tags if you wanted
snapshots.

I think we might actually have several different modes of operation:

  * Disconnected head + commit sha1 in the superproject's tree: This
   is what we have now.

  * The same, but make it branch aware. I've scripted this locally
    with the $toplevel patch to git-submodule that started this
    thread. But it could be expanded.

    It would be really neat for example to do:

        # Or some shorter way of doing this, perhaps even with
        # git-pull
        git submodule foreach 'git fetch'

        # Tells you that "submodule xyz which you've pinned to SHA1SUM
        # on the FOOBAR branch is 20 commits behind the upstream
        # FOOBAR branch"
        git status --submodules

    You'd still have to take action to update the module and move the
    SHA1SUM in the parent project, but something like this would make
    cases where you've e.g. included a lot of plugins in your project,
    and would like Git to tell you if they get new updates.

  * Branch-only: What I proposed in this thread. It's certainly not
    for everyone, but there's a lot of cases where you just want a
    quick meta-repository but aren't very interested in 100%
    historical consistency.

  * More? Actually if we're doing multiple strategies I see no reason
    not to e.g. include a foreign scm interface. That would be really
    useful to some projects that are in a SVN -> Git transition:

       [submodule "svn-lib"]
           ;; type defaults to git
           type = svn
           path = src/svn-lib
           url = svn://example.net/path/to/include
           ;; driver-specific attributes
           svn:revision = r54238

  reply	other threads:[~2010-06-09 18:54 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
2010-06-09 18:54           ` Ævar Arnfjörð Bjarmason [this message]
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=AANLkTiknGcteTjrHWM02H2KOMMDPZKHY1w0ZOIswddFn@mail.gmail.com \
    --to=avarab@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.
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).