Re: Preferred local submodule branches

On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:

I tried to refocus things (with a new subject) in this sub-thread. Hopefully that helps make the discussion more linear ;).

I'm waiting [1] to see how the C-level checkout by Jens and Jonathan progresses [2,3] before writing more code.

As far as I know, no-one else has endorsed this idea (yet :). Heiko has expressed concern [4], but not convincingly enough (yet :) to win me over ;).

I've put this at the bottom of the message to avoid bothering the tl;dr crowd, although they have probably long since tuned us out ;).

Agreed. I think we're all looking for the least-complex solution that covers all (or most) reasonable workflows.

Neither does 'head'. We have precedence in 'git submodule add' for embracing and extending a core git command with additional .gitmodules manipulation. I think it's easier to pick up the submodule jargon when we add submodule-specific side-effects to submodule-specific commands named after their core analogs than it would be if we pick unique names for the submodule-specific commands.

Ah, that makes more sense. I had confused .git/config with “.gitmodules and .git/config”.

Something that just touches the config files is syntactic sugar, so I avoided a more detailed review and moved on to address what I saw as a more fundamental issue (preferred submodule local branches on a per-superproject-branch level).

Here's a detailed workflow for the {my-feature, my-feature, master} example I roughed out before [5].

  # create the subproject
  mkdir subproject &&
  (
    cd subproject &&
    git init &&
    echo 'Hello, world' > README &&
    git add README &&
    git commit -m 'Subproject v1'
  ) &&
  # create the superproject
  mkdir superproject
  (
    cd superproject &&
    git init &&
    git submodule add ../subproject submod &&
    git config -f .gitmodules submodule.submod.update merge &&
    git commit -am 'Superproject v1' &&
    ( # 'submodule update' doesn't look in .gitmodules (yet [6]) for a
      # default update mode.  Copy submodule.submod.update over to
      # .git/config
      git submodule init
    )
  ) &&
  # start a feature branch on the superproject
  (
    cd superproject &&
    #git checkout -b my-feature --recurse-submodules &&
    ( # 'git submodule checkout --recurse-submodules' doesn't exist yet, so...
      git checkout -b my-feature &&
      git config -f .gitmodules submodule.submod.local-branch my-feature &&
      cd submod &&
      git checkout -b my-feature
    ) &&
    (
      cd submod &&
      echo 'Add the subproject side of this feature' > my-feature &&
      git add my-feature &&
      git commit -m 'Add my feature to the subproject'
    ) &&
    echo 'Add the superproject side of this feature' > my-feature &&
    git add my-feature &&
    git commit -m 'Add the feature to the superproject'
  ) &&
  # meanwhile, the subproject has been advancing
  (
    cd subproject &&
    echo 'Goodbye, world' >> README &&
    git commit -am 'Subproject v2'
  ) &&
  # we need to get that critical advance into the superproject quick!
  (
    cd superproject &&
    # update the master branch
    #git checkout --recurse-submodules master
    ( # 'git checkout --recurse-submodules' doesn't exist yet [2,3].
      # Even with that patch, 'git checkout' won't respect
      # submodule.<name>.local-branch without further work.
      git checkout master &&
      cd submod &&
      git checkout master  # don't pull in our my-feature work
    )
    git submodule update --remote &&
    git commit -am 'Catch submod up with Subproject v2' &&
    # update the my-feature branch
    git checkout my-feature
    ( # 'git checkout' doesn't mess with submodules
      cd submod &&
      git checkout my-feature
    )
    git submodule update --remote &&
    git commit -am 'Catch submod up with Subproject v2' &&
    # what does the history look like?
    (
      cd submod &&
      git --no-pager log --graph --date-order --oneline --decorate --all
      # *   3a22cef (HEAD, my-feature) Merge commit 'd53958b18277ce5bd6c734e9597a69bb878b31e1' into my-feature
      # |\  
      # * | 8322dcc Add my feature to the subproject
      # | * d53958b (origin/master, origin/HEAD, master) Subproject v2
      # |/  
      # * 9813010 Subproject v1
    ) &&
    git ls-tree master submod &&
    # 160000 commit d53958b18277ce5bd6c734e9597a69bb878b31e1  submod
    git ls-tree my-feature submod
    # 160000 commit 3a22cef30db57f1b89251f3e434fa0bd0f1b99a2  submod
  )
  git --version
  # git version 1.8.3.2

The currently-ugly bits could be fixed with:

* 'git submodule update' falling back on .gitmodules for
  submodule.<name>.update [6].
* 'git submodule checkout -b my-feature --recurse-submodules' should
  checkout the submodule.<name>.local-branch configured for the
  super-project's my-feature branch (but only if that wouldn't destroy
  some current submodule information).  This would build on work in
  Jens and Jonathans' branch [2,3].

Cheers, Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/240127 [2]: http://article.gmane.org/gmane.comp.version-control.git/240117 [3]: http://thread.gmane.org/gmane.comp.version-control.git/239695 [4]: http://article.gmane.org/gmane.comp.version-control.git/240178 [5]: http://article.gmane.org/gmane.comp.version-control.git/240190 [6]: http://article.gmane.org/gmane.comp.version-control.git/239246