All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Nigel Magnay <nigel.magnay@gmail.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
	Benjamin Collins <aggieben@gmail.com>,
	Avery Pennarun <apenwarr@gmail.com>, Git ML <git@vger.kernel.org>
Subject: Re: git submodules
Date: Tue, 29 Jul 2008 10:45:30 +0200	[thread overview]
Message-ID: <20080729084530.GD32312@artemis.madism.org> (raw)
In-Reply-To: <320075ff0807290118o62a6fc1eq3e90e32ef7783a17@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

On Tue, Jul 29, 2008 at 08:18:12AM +0000, Nigel Magnay wrote:
> >> I try to keep all my submodules on (no branch) as much as possible.
> >> In a way, I feel like that kind of relieves me of the chore of keeping
> >> mapping superproject branches to submodule branches in my head.
> >
> > At my former day-job we wrote our own "git submodule" in our
> > build system before gitlink was available in the core, let alone
> > git-submodule was a Porcelain command.
> >
> > Many developers who were new to Git found having a sea of 11 Git
> > repositories+working directories in a single build area difficult to
> > manage.  They quickly found the detached HEAD feature in a submodule
> > to be a really handy way to know if they made changes there or not.
> >
> > Most of our developers also modified __git_ps1() in their bash
> > completion to use `git name-rev HEAD` to try and pick up a remote
> > branch name when on a detached HEAD.  This slowed down their bash
> > prompts a little bit, but they found that "origin/foo" hint very
> > valuable to let them know they should start a new branch before
> > making changes.
> >
> > So I'm just echoing what Benjamin said above, only we did it
> > independently, and came to the same conclusion.
> >
> 
> Hm.
> My developers are (mostly) on windows, so "altering PS1" or even
> writing "shell scripts" is way beyond them.

  More importantly, you don't have all your submodule states in your PS1
so this argument is already moot for *nix users as well.

> They want it to "just work" (where their previous experience is SVN
> superprojects with multiple svn:externals). I have a hard time
> justifying the experience that if we're all working on master, then as
> soon as Joe Q developer does 'submodule update' then poof - his heads
> are disconnected.

  Well, maybe it's not as hard, maybe what we lack are just submodule
aware porcelains (I mean we lack those for sure, but maybe it's also
the _only_ thing we miss to have a better user experience, and I begin
to believe it).

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-07-29  8:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-28 16:20 git submodules Pierre Habouzit
2008-07-28 16:23 ` Pierre Habouzit
2008-07-28 20:23 ` Nigel Magnay
2008-07-28 20:55   ` Pierre Habouzit
2008-07-28 20:59     ` Pierre Habouzit
2008-07-28 21:40       ` Avery Pennarun
2008-07-28 22:03         ` Pierre Habouzit
2008-07-28 22:26           ` Jakub Narebski
2008-07-28 22:41             ` Junio C Hamano
2008-08-17 20:13               ` Pierre Habouzit
2008-08-17 22:54                 ` Avery Pennarun
2008-08-17 23:08                 ` Junio C Hamano
2008-08-18  0:46                   ` Pierre Habouzit
2008-07-28 22:32           ` Avery Pennarun
2008-07-28 23:12             ` Pierre Habouzit
2008-07-29  5:51         ` Benjamin Collins
2008-07-29  6:04           ` Shawn O. Pearce
2008-07-29  8:18             ` Nigel Magnay
2008-07-29  8:45               ` Pierre Habouzit [this message]
2008-07-29  8:21           ` Pierre Habouzit
2008-07-29  8:37             ` Pierre Habouzit
2008-07-29  8:51               ` Petr Baudis
2008-07-29 12:15                 ` Johannes Schindelin
2008-07-29 13:07                   ` Pierre Habouzit
2008-07-29 13:15                     ` Johannes Schindelin
2008-07-29 13:19                       ` Pierre Habouzit
2008-07-29 13:31                       ` Nigel Magnay
2008-07-29 14:49                         ` Pierre Habouzit
2008-07-29 14:53                         ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2009-10-17 17:15 Steven Noonan
2009-10-17 17:27 ` Jakub Narebski
2009-10-17 22:30   ` Nanako Shiraishi
2009-10-21 19:38 ` Avery Pennarun
2008-04-28 19:50 Victor Bogado da Silva Lins
2008-04-28 21:01 ` Miklos Vajna
2008-02-05 15:02 HG branches Takashi Iwai
2008-02-06 14:04 ` Jaroslav Kysela
2008-02-06 14:06   ` Jaroslav Kysela
2008-02-06 20:06     ` Rene Herman
2008-02-07 11:37       ` Takashi Iwai
2008-02-07 21:10         ` GIT submodules Rene Herman
2008-02-07 21:24         ` Rene Herman

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=20080729084530.GD32312@artemis.madism.org \
    --to=madcoder@debian.org \
    --cc=aggieben@gmail.com \
    --cc=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nigel.magnay@gmail.com \
    --cc=spearce@spearce.org \
    /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.