Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread Junio C Hamano
Francesco Pretto cez...@gmail.com writes:

   - In which situations does the developer or maintainer switch between
 your attached/detached mode?

 The developer/maintainer does so optionally and voluntarily and it
 effects only its private working tree.

 This does not answer my question. I would like to find out the reason
 why one would do the switch.

 The developer does it voluntarily, at his responsibility, because he
 may decide to partecipate more actively to the development of the
 submodule and still want to use a simple git submodule update to
 updates his submodules, overriding its configuration as it can be done
 for other properties like, for example, branch.

It is still unclear to me why we need attached/detached mode for
that.  The developer may want to do an exploratory development,
whose result is unknown to deserve to be committed on the specified
branch at the beginning, and choose to build on a detached HEAD,
which is a perfectly normal thing to do.  But the standard way to do
so, whether the developer is working in the top-level superproject
or in a submodule, would be to just do:

cd $there  git checkout HEAD^0

or use whatever commit the state to be detached is at instead of
HEAD in the above example, no?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread Junio C Hamano
Francesco Pretto cez...@gmail.com writes:

 My bottom line:
 - For what I understand, detached HEAD it's a way to say hey, you
 have to stay on this commit. Also don't even think you can push to the
 upstream branch. This sometimes can't be spurious, as in the use case
 I wrote above: access control on the remote repositories should be
 enough. I think maintainers should have the option to make developers
 to clone a repository starting with an attached HEAD on the branch
 suggested in submodule.$name.branch;
 - git submodule update is missing a property to do automatically
 --remote. I think in the use case I wrote it's really handy to have
 a git submodule update to act like this.

The short version I read in the message is that your workflow, in
which partipants want to work on a branch, gets frustrating with the
current system only because the default update/initial cloning
detaches HEAD and will stay in that state until the user gets out of
the detached state manually. Once that initial detachment is fixed,
there is no more major issue, as update will stay on that branch.

Am I reading you correctly?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread Francesco Pretto
2014/1/7 Junio C Hamano gits...@pobox.com:
 Francesco Pretto cez...@gmail.com writes:

 My bottom line:
 - For what I understand, detached HEAD it's a way to say hey, you
 have to stay on this commit. Also don't even think you can push to the
 upstream branch. This sometimes can't be spurious, as in the use case
 I wrote above: access control on the remote repositories should be
 enough. I think maintainers should have the option to make developers
 to clone a repository starting with an attached HEAD on the branch
 suggested in submodule.$name.branch;
 - git submodule update is missing a property to do automatically
 --remote. I think in the use case I wrote it's really handy to have
 a git submodule update to act like this.

 The short version I read in the message is that your workflow, in
 which partipants want to work on a branch, gets frustrating with the
 current system only because the default update/initial cloning
 detaches HEAD and will stay in that state until the user gets out of
 the detached state manually. Once that initial detachment is fixed,
 there is no more major issue, as update will stay on that branch.

 Am I reading you correctly?


Yep, you got it correctly.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread W. Trevor King
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
  +---+
  |  master   | --
 +---++---+| Merges to/from master
 | CEDET | | done only by CEDET developers
 +---+ | 
  +---+|
  |  stable   | --  
  +---+   |
  |
  |
  | Any Emacs developer
  | can push and commit
  | submodule
 +++--+   |
 | Emacs  | -- | lisp/cedet submodule | -
 +++--+

This looks reasonable, and except for the detached-HEAD after the
initial update-clone, I think Git already supports everything you
need.  If you set submodule.cedet.update to 'rebase' (or 'merge') you
can easily integrate your local master changes with cedet/master
(e.g. if a CEDET dev updates cedet/master before the Emacs dev has a
chance to push their fix).  With the non-checkout update mode, you'll
also stay on your checked-out master branch during 'submodule update'
calls.

 AFAICS the main problem with this approach is that one always has to
 think of committing the new SHA1 of the submodule.
 …
 However, as Heiko notes, the history must be preserved to be able to
 go back to earlier revisions, so there must be some kind of commit
 for the submodule when 'stable' changes; maybe that could be
 automated somehow?

If an Emacs dev in the submodule makes the CEDET change, you could use
a post-commit hook (in the CEDET submodule) to also commit the change
to the Emacs superproject).  However, commiting only the submodule
bump may not be what you want.  Maybe there are other superproject
changes that should be committed alongside the submodule bump.  Maybe
there is stuff in the superprojects's staging area that should *not*
be committed alongside the submodule bump.  This ambiguity makes it
tricky for Git to automatically do “the right thing”.

If cedet/master is updated independently by the CEDET devs, there's no
way for the local Emacs repo to know about the change, so it's
impossible to automatically update Emacs (without polling for CEDET
updates or some other transgression ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread Francesco Pretto
2014/1/7 Junio C Hamano gits...@pobox.com:
 Francesco Pretto cez...@gmail.com writes:
 The developer does it voluntarily, at his responsibility, because he
 may decide to partecipate more actively to the development of the
 submodule and still want to use a simple git submodule update to
 updates his submodules, overriding its configuration as it can be done
 for other properties like, for example, branch.

 It is still unclear to me why we need attached/detached mode for
 that.  The developer may want to do an exploratory development,
 whose result is unknown to deserve to be committed on the specified
 branch at the beginning, and choose to build on a detached HEAD,
 which is a perfectly normal thing to do.  But the standard way to do
 so, whether the developer is working in the top-level superproject
 or in a submodule, would be to just do:

 cd $there  git checkout HEAD^0

 or use whatever commit the state to be detached is at instead of
 HEAD in the above example, no?


Because of the overlapping change with the the other patch proposed by
Trevor, and to not generate confusion, I will stop for now pursuing
for an attach|detach command/switch specific for submodules, waiting
for Trevors's patch possible acceptance. After that I will see it
still makes sense or not.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread Heiko Voigt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
 Here's an attempted summary of our desires, and my ideal route
 forward:
 
 * Preferred local submodule branches for each superproject branch.
   * Not currently supported by Git.
   * Requires some sort of per-superproject-branch .git/config.
   * Fall back to the remote-tracking submodule.name.branch?
 
 * Auto checkout of the preferred branch
   * Can do this at clone-update time with my patch.
   * For later submodule branch switches, maybe we want:
 
   git submodule checkout [-b branch] [paths…]
 
 Then if a user blows off their detached HEAD, at least they'll
 feel a bit sheepish afterwards.

Well, for development on a detached HEAD in a submodule we are currently
not very careful anyway. A simple

git submodule update

will already blow away any detached HEAD work. But AFAIK it should
trigger the you are leaving commits from a detached HEAD behind
warning, so there is some safeguard and recovery.

Cheers Heiko
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlLMhPAACgkQjLR3Aoip+rqP6wCeIhtpWLJC3XVO3nu2ViQTbHPg
T5wAoLLEZ256GOOjBxoTKo2/FmfvQGLp
=+bqm
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-07 Thread W. Trevor King
On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote:
 On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
  Here's an attempted summary of our desires, and my ideal route
  forward:
  
  * Preferred local submodule branches for each superproject branch.
* Not currently supported by Git.
* Requires some sort of per-superproject-branch .git/config.
* Fall back to the remote-tracking submodule.name.branch?
  
  * Auto checkout of the preferred branch
* Can do this at clone-update time with my patch.
* For later submodule branch switches, maybe we want:
  
git submodule checkout [-b branch] [paths…]
  
  Then if a user blows off their detached HEAD, at least they'll
  feel a bit sheepish afterwards.
 
 Well, for development on a detached HEAD in a submodule we are currently
 not very careful anyway. A simple
 
   git submodule update
 
 will already blow away any detached HEAD work.

Only if you use the checkout strategy.  With --merge or --rebase,
you'll have the $sha1 (or upstream remote with --remote) integrated
with your detached HEAD work.  You end up with a new detached HEAD
containing the result of the integration (just confirmed with tests
using Git v1.8.3.2).  That seems reasonable to me, so I'm happy with
the integration logic.

 But AFAIK it should trigger the you are leaving commits from a
 detached HEAD behind warning, so there is some safeguard and
 recovery.

I did not see those in testing with Git v1.8.3.2, likely because of
the '-f -q' we pass to 'git checkout' for checkout-mode updates.

Regardless of branch integration issues, I think a
per-superproject-branch preferred submodule branch is important for
'git checkout' to work in the superproject.  If you want:

* submodule branch master for superproject branch master, and
* submodule branch my-feature for superproject branch my-feature,

  $ git checkout my-feature

in the superproject is currently going to leave you with the submodule
on master, which is not convenient ;).  I think we should come up with
a better solution to the superproject checkout problem before adding
in additional complications due to branch integration ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread Heiko Voigt
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
 2014/1/5 Heiko Voigt hvo...@hvoigt.net:
  The following questions directly pop into my mind:
 
   - What means the maintainer does not track the submodules sha1? Does
 that mean the superproject always refers to submodule commits using
 branches?
 
 It means he doesn't need to control other developers commit to be
 checked out so he sets submodule.name.ignore to all. In this way
 he and the developers can work actively in their submodule copy.

So practically speaking: You mean that the value of
submodule.name.ignore is set to all in the master branch of the
superproject? From your other email referring to svn:externals I figure
that.

   - What happens if you want to go back to an earlier revision? Lets say
 a tagged release? How is ensured that you get the correct revision in
 the submodules?
 
 submodule.name.branch is one setting that is not copied in
 .git/config by git submodule init. git submodule update will use
 the setting in .gitmodules if not overridden voluntarily by the
 developer in .git/config. The maintainer can change that setting in
 .gitmodules and commit the change. Modifies will be propagated by
 the next git pull  git submodule update of the developer in the
 superproject.

I do not understand how does that ensure you get the correct submodule
revision when checking out a tagged release? To get a precise revision
the superproject needs to track a sha1 of a submodule commit. I do not
see how that has anything to do with submodule.name.branch?

   - In which situations does the developer or maintainer switch between
 your attached/detached mode?
 
 The developer/maintainer does so optionally and voluntarily and it
 effects only its private working tree.

This does not answer my question. I would like to find out the reason
why one would do the switch.

   - What is the repository branch which is given to the developer by
 the maintainer used for? Who creates this branch and who merges into
 it?
 
 The branch of course must exist prior submodule adding. In this
 use-case it does not really matter who creates it and who merges into
 it. Everyone with the right to merge into it has to work in the
 submodule seamlessly, as it was working on separate clone of the same
 repository used as the submodule.
o
Here is the same. I am searching for a description like:

If the developer works on a feature that needs a submodule change he:
  - creates a submodule branch
  - configures that submodule branch in the superproject:
git config -f .gitmodules submodule.common.branch dev/some-feature
git commit -am TEMP: track submodule common on branch
 - and pushes out his superproject branch

The submodule branch is then posted for review and continued to work on.

Once everyone involved is happy with the submodule change the branch in
there gets merged to master.

Now the branch in the superproject is modified to drop the change in
.gitmodules and the sha1 reference in the superproject is updated to the
current master of the superproject.

The superproject branch is posted for review.

...

Could you describe something like this for your workflow? A complete
change lifecycle when a developer works, as you call it, actively in a
submodule?

   - What are these subsequent merge or rebase update operations? Do
 you mean everyone has submodule.name.update configured to merge or
 rebase?
 
 
 subsequent merge or rebase update operations are just the ones
 after the initial clone/checkout, nothing particular.

To clarify you are talking about issuing git merge or git rebase
commands in the superproject?

Cheers Heiko
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread Heiko Voigt
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
 2014/1/5 Heiko Voigt hvo...@hvoigt.net:
  Could you please extend the description of your use-case so we can
  understand your goal better?
 
 
 Maybe I found better words to explain you my goal: the current git
 submodule use-case threats the submodule as a project independent
 dependency. My use case threats the submodule as part of the
 superproject repository. It could be easier to say that in this way
 submodules would behave very similarly to svn:externals, something
 that is actually missing in git. My goal is obtain this without
 altering git behavior for the existing use case.

I am not so sure. svn:externals was IMO a hack in SVN to bind projects
together. It does not record the revision and so has nothing to do
with version control. If you simply want to always checkout the
development tip of some project you could do something like this:

git submodule foreach 'git fetch  git checkout origin/master'

The demand for this 'missing feature' which we call the 'floating
submodules' model has been around for some time but until now we could
convince people that its not a feature but you are actually loosing
history information.

The workflow could always be changed to allow recording revisions. Which
is why you use git in the first place right? If you discard revisions
for submodules tracking down regression bugs can become a big problem or
completely impossible. Try using git bisect on such a history.

   - In which situations does the developer or maintainer switch between
 your attached/detached mode?
 
 As I told you in the other answer this is voluntary done by the
 developer, as he prefers.

Could you tell me a typical reason?


 I came to the conclusion that the
 --attach|--detach switches for the update command are not that
 useful and can be removed. It's still possible to obtain the switch
 between detached/attached very easily in this way:
 
 # Attach submodule
 $ git config submodule.name.attached true
 $ git submodule update
 
 # Detach submodule
 $ git config submodule.name.attached false
 $ git submodule update
 
 # Unset property in both .gitmodules and .git/config means - do nothing
 $ git config --unset submodule.name.attached
 $ git submodule update
 
 Also my submodule.name.attached property at the moment behaves
 like submodule.name.update: it is copied in .git/config by git
 submodule init. This is probably a mistake: the overridden value
 should be stored in .git/config only at the developer will, so the
 maintainer has still a chance to modify it in .gitmodules and
 propagate the behavior.
 
 I would send an updated patch but at this point I prefer to wait for a
 full review.

Lets first discuss and figure out what is the real missing feature here
and what should be implemented before working further on the code.

Cheers Heiko
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread W. Trevor King
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote:
 If you simply want to always checkout the development tip of some
 project you could do something like this:
 
   git submodule foreach 'git fetch  git checkout origin/master'

Or (respecting submodule.name.branch):

  $ git submodule update --remote

You can even:

  $ git submodule update --remote --recursive

whenever you get an itch to upgrade everything everything in one
sweeping, hard-to-debug move ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-05 Thread Francesco Pretto
(Hmmpth, forgot signoff...)

To whom it may interest, added some CC.

2014/1/5 Francesco Pretto cez...@gmail.com:
 At the current state, the following use-case is not supported very
 well in git:
 - a maintainer adds a submodule, checking out a specific branch of
 the repository. He doesn't track the upstream submodule revision sha1;
 - a developer checkout the repository branch decided by the maintainer.
 Subsequent merge or rebase update operations don't detach the HEAD.

 To ease the above use-case this patch:
 - introduces a submodule.module.attached property that, when set
   to true, ensures that the update operation will result in
   the HEAD attached to a branch;
 - introduces --attach|--dettach switches to the submodule update
   command: they attach/detach the HEAD, overriding
   submodule.module.attached property value;
 - introduces --attached-update switch to the add operation. It:
 * sets submodule.module.attached to true;
 * sets submodule.module.ignore to all.

 Using the '--attach' switch or operating in a repository with
 'submodule.name.attached' set to 'true' during update will:
 - checkout a branch with an attached HEAD if the repository was just
 cloned;
 - perform a fast-forward only merge of changes if it's a 'checkout'
 update operation;
 - reattach the HEAD prior performing a 'merge', 'rebase' or '!command'
 update operation if the HEAD was found detached. Orphaned commits
 will also be merged back in the branch.

 '--attach' or 'submodule.name.attached' set to true also implies '--remote'.

 Using  the '--detach' switch or operating in a repository with
 'submodule.name.attached' set to 'false' during update will:
 - checkout a detached HEAD if the repository was just cloned;
 - detach the HEAD prior performing a 'merge', 'rebase' or '!command'
 update operation if the HEAD was found attached.

 'submodule.name.attached' works similarly to 'submodule.name.update'
 property: git copies the values found in .gitmodules in .git/config when
 performing an init command. update looks for values in .git/config
 only.

 '--attach' and '--detach' switches override an opposite behaviour
 of 'submodule.name.attached' properties.

 The patch is strongly additive and doesn't break any submodule specific
 test. It also adds some tests specific to the added feature.
 ---
  Documentation/git-submodule.txt|  48 +--
  Documentation/gitmodules.txt   |  10 +-
  git-submodule.sh   | 154 +++--
  t/t7410-submodule-attached-head.sh | 268 
 +
  4 files changed, 457 insertions(+), 23 deletions(-)
  create mode 100755 t/t7410-submodule-attached-head.sh

 diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
 index bfef8a0..b97eefb 100644
 --- a/Documentation/git-submodule.txt
 +++ b/Documentation/git-submodule.txt
 @@ -10,13 +10,14 @@ SYNOPSIS
  
  [verse]
  'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
 - [--reference repository] [--depth depth] [--] repository 
 [path]
 + [--reference repository] [--attached-update] [--depth depth]
 + [--] repository [path]
  'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
  'git submodule' [--quiet] init [--] [path...]
  'git submodule' [--quiet] deinit [-f|--force] [--] path...
  'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
 - [-f|--force] [--rebase] [--reference repository] [--depth 
 depth]
 - [--merge] [--recursive] [--] [path...]
 + [-f|--force] [--rebase] [--reference repository] [--attach | 
 --detach]
 + [--depth depth] [--merge] [--recursive] [--] [path...]
  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) 
 n]
   [commit] [--] [path...]
  'git submodule' [--quiet] foreach [--recursive] command
 @@ -107,6 +108,9 @@ is the superproject and submodule repositories will be 
 kept
  together in the same relative location, and only the
  superproject's URL needs to be provided: git-submodule will correctly
  locate the submodule using the relative URL in .gitmodules.
 ++
 +If `--attached-update` is specified, the property `submodule.name.attached`
 +will be set to `true` and `submodule.name.ignore` will be set to `all`.

  status::
 Show the status of the submodules. This will print the SHA-1 of the
 @@ -156,12 +160,15 @@ it contains local modifications.
  update::
 Update the registered submodules, i.e. clone missing submodules and
 checkout the commit specified in the index of the containing 
 repository.
 -   This will make the submodules HEAD be detached unless `--rebase` or
 -   `--merge` is specified or the key `submodule.$name.update` is set to
 -   `rebase`, `merge` or `none`. `none` can be overridden by specifying
 -   `--checkout`. Setting the key `submodule.$name.update` to `!command`
 -   will cause 

Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-05 Thread Francesco Pretto
2014/1/5 Heiko Voigt hvo...@hvoigt.net:

 Could you please extend the description of your use-case so we can
 understand your goal better?


Just in case you missed the first patch iteration[1].

 The following questions directly pop into my mind:

  - What means the maintainer does not track the submodules sha1? Does
that mean the superproject always refers to submodule commits using
branches?

It means he doesn't need to control other developers commit to be
checked out so he sets submodule.name.ignore to all. In this way
he and the developers can work actively in their submodule copy.

  - What happens if you want to go back to an earlier revision? Lets say
a tagged release? How is ensured that you get the correct revision in
the submodules?

submodule.name.branch is one setting that is not copied in
.git/config by git submodule init. git submodule update will use
the setting in .gitmodules if not overridden voluntarily by the
developer in .git/config. The maintainer can change that setting in
.gitmodules and commit the change. Modifies will be propagated by
the next git pull  git submodule update of the developer in the
superproject.

  - In which situations does the developer or maintainer switch between
your attached/detached mode?

The developer/maintainer does so optionally and voluntarily and it
effects only its private working tree.

  - What is the repository branch which is given to the developer by
the maintainer used for? Who creates this branch and who merges into
it?

The branch of course must exist prior submodule adding. In this
use-case it does not really matter who creates it and who merges into
it. Everyone with the right to merge into it has to work in the
submodule seamlessly, as it was working on separate clone of the same
repository used as the submodule.

  - What are these subsequent merge or rebase update operations? Do
you mean everyone has submodule.name.update configured to merge or
rebase?


subsequent merge or rebase update operations are just the ones
after the initial clone/checkout, nothing particular.

Greetings,
Francesco

[1] http://marc.info/?l=gitm=138836829531511w=2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-05 Thread Francesco Pretto
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
 Could you please extend the description of your use-case so we can
 understand your goal better?


Maybe I found better words to explain you my goal: the current git
submodule use-case threats the submodule as a project independent
dependency. My use case threats the submodule as part of the
superproject repository. It could be easier to say that in this way
submodules would behave very similarly to svn:externals, something
that is actually missing in git. My goal is obtain this without
altering git behavior for the existing use case.

  - In which situations does the developer or maintainer switch between
your attached/detached mode?

As I told you in the other answer this is voluntary done by the
developer, as he prefers. I came to the conclusion that the
--attach|--detach switches for the update command are not that
useful and can be removed. It's still possible to obtain the switch
between detached/attached very easily in this way:

# Attach submodule
$ git config submodule.name.attached true
$ git submodule update

# Detach submodule
$ git config submodule.name.attached false
$ git submodule update

# Unset property in both .gitmodules and .git/config means - do nothing
$ git config --unset submodule.name.attached
$ git submodule update

Also my submodule.name.attached property at the moment behaves
like submodule.name.update: it is copied in .git/config by git
submodule init. This is probably a mistake: the overridden value
should be stored in .git/config only at the developer will, so the
maintainer has still a chance to modify it in .gitmodules and
propagate the behavior.

I would send an updated patch but at this point I prefer to wait for a
full review.

Thank you,
Francesco
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html