All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eran Tromer <git2eran@tromer.org>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: skimo@liacs.nl, VMiklos <vmiklos@frugalware.org>, git@vger.kernel.org
Subject: Re: question about git-submodule
Date: Fri, 03 Aug 2007 19:01:38 -0400	[thread overview]
Message-ID: <46B3B3D2.6030000@tromer.org> (raw)
In-Reply-To: <20070715104712.GF2568@steel.home>

On 2007-07-15 06:47, Alex Riesen wrote:
> Sven Verdoolaege, Sun, Jul 15, 2007 10:39:59 +0200:
>> On Fri, Jul 13, 2007 at 11:46:30PM +0200, VMiklos wrote:
>>> i mean, first i thought that after configuring a submodule under libfoo,
>>> then a git pull will update libfoo's repo under libfoo, too. or
>>> something like that.
>> Unless I've missed something, it doesn't.
>> Some of use would like git to do just that (at least Alex Riesen,
>> Martin Waitz and myself have sent in patches to that effect),
>> but we haven't been able to convince Junio yet.
> 
> Count me out. Junio convinced me instead and having tried the
> subprojects I find it really convenient: I can choose when and what
> should be updated and I can see what _can_ be updated, iff I decide
> to. Subprojects defined in such a loosely way are more flexible then
> having git-pull fetch subprojects by default. Sometimes I even want be
> _sure_ the subprojects are completely untouched (I have some critical
> parts in them).

All of the above also applies to normal files, not just submodules. So
by this logic, maybe "git pull" and "git checkout" should by default
update just the index, and require a manual "git file update" to update
the files in the working tree?

Leaving the working tree (including submodules) in an inconsistent state
right after a pull or checkout is a very strange thing to do. It means,
for example, that even simple switching between branches doesn't work in
a superproject. Consider this example (tested on next aac97aacbccd):

--------------------------------------------------
Create the subproject repo:

$ mkdir sub-to-be
$ cd sub-to-be
$ git init
$ echo AAA > foo
$ git add foo
$ git commit -m sub
$ cd ..

Create the superproject repo and clone subproject into it:

$ mkdir super
$ cd super
$ git init
$ git submodule add ../sub-to-be sub
$ git commit -m super

Update the submodule:

$ cd sub
$ echo BBB > foo
$ git add foo
$ git commit -m sub
$ cd ..

Update the supermodule:

$ git add sub
$ git commit -m super

Try to switch between versions, and fail miserably:

$ git checkout -b old HEAD^
M       sub
Switched to a new branch "old"
$ git checkout master
fatal: Entry 'sub' not uptodate. Cannot merge.
--------------------------------------------------

BTW, is there any easy way to create a submodule directly inside the
supermodule's working tree, instead of cloning it as in the above example?

  Eran

  parent reply	other threads:[~2007-08-03 23:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-13 21:46 question about git-submodule VMiklos
2007-07-15  8:39 ` Sven Verdoolaege
2007-07-15 10:47   ` Alex Riesen
2007-07-15 10:54     ` VMiklos
2007-07-15 13:50       ` Alex Riesen
2007-07-15 13:54         ` VMiklos
2007-07-15 14:02           ` Sven Verdoolaege
2007-07-15 14:26             ` VMiklos
2007-07-15 14:48               ` Sven Verdoolaege
2007-07-15 15:05                 ` VMiklos
2007-07-15 15:21                   ` Sven Verdoolaege
2007-07-15 15:40                     ` VMiklos
2007-07-15 21:45                       ` Sven Verdoolaege
2007-07-15 22:29                         ` VMiklos
2007-07-16 10:39                           ` Sven Verdoolaege
2007-07-16 11:07                             ` VMiklos
2007-07-15 11:51     ` Sven Verdoolaege
2007-07-15 13:42       ` Alex Riesen
2007-07-15 13:52         ` Sven Verdoolaege
2007-08-03 23:01     ` Eran Tromer [this message]
2007-08-05 14:59       ` Sven Verdoolaege
2007-08-06 17:23         ` Eran Tromer

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=46B3B3D2.6030000@tromer.org \
    --to=git2eran@tromer.org \
    --cc=git@vger.kernel.org \
    --cc=raa.lkml@gmail.com \
    --cc=skimo@liacs.nl \
    --cc=vmiklos@frugalware.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.