On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
> 2014/1/8 W. Trevor King <wk...@tremily.us>:
> > Note that I've moved away from “submodule.<name>.branch
> > set means attached” towards “we should set per-superproject-branch
> > submodule.<name>.local-branch explicitly” [1].
> Honestly, I'm having an hard time to follow this thread.

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

> Also, you didn't update the patch.

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

> If you were endorsed by someone (Junio, Heiko, ...) for the
> "submodule.<name>.local-branch" feature please show me where.

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 somehow understand the point of the
> "submodule.<name>.local-branch" property, but I can't "see" the the
> workflow. Please, show me some hypothetical scripting example with
> as much complete as possible workflow (creation, developer update,
> mantainers creates feature branch, developer update, developer
> attach to another branch).

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 ;).

> Also, consider I proposed to support the attached HEAD path to
> reduce complexity and support a simpler use case for git
> submodules. I would be disappointed if the complexity is reduced in
> a way and augmented in another.

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

> > On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
> >> # Attach the submodule HEAD to <branch>.
> >> # Also set ".git/config" 'submodule.<module>.branch' to <branch>
> >> $ git submodule head -b <branch> --attach <module>
> > [...]
> > I also prefer 'checkout' to 'head', because 'checkout'
> > already exists in non-submodule Git for switching between local
> > branches.
> I can agree with similarity to other git commands, but 'checkout'
> does not give me the idea of something that writes to ".git/config"
> or ".gitmodules".

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.

> >> # Unset  ".git/config" 'submodule.<module>.branch'
> >> # Also attach or detach the HEAD according to what is in ".gitmodules":
> >> # with Trevor's patch 'submodule.<module>.branch' set means attached,
> >> # unset means detached
> >> $ git submodule head --reset <module>
> >
> > To me this reads “always detach HEAD” (because it unsets
> > submodule.<name>.branch, and submodule.<name>.branch unset means
> > detached).
> I disagree: this would remove only the value in ".git/config". If the
> value is till present in ".gitmodules", as I wrote above, the behavior
> of what is in the index should be respected as for the other
> properties. Also it gives a nice meaning to a switch like --reset :
> return to how it was before.

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

> >> NOTE: feature branch part!
> >>
> >> # Set ".gitmodules" 'submodule.<module>.branch' to <branch>
> >> $ git submodule head -b <branch> --attach --index <module>
> >>
> >> # Unset ".gitmodules" 'submodule.<module>.branch'
> >> $ git submodule head --reset --index <module>
> >> ---------------------------------------------------------------------
> >
> > These are just manipulating .gitmodules.  I think we also need
> > per-superproject-branch configs under the superproject's .git/ for
> > developer overrides.
> I disagree: in my idea the --index switch is a maintainer only command
> to modify the behavior of the developers and touch only indexed files
> (.gitmodules, or create a new submodule branch). It expressly don't
> touch .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

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].


[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

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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to