1. 20 Nov, 2015 1 commit
    • Mike Crowe's avatar
      push: add recurseSubmodules config option · b33a15b0
      Mike Crowe authored
      The --recurse-submodules command line parameter has existed for some
      time but it has no config file equivalent.
      
      Following the style of the corresponding parameter for git fetch, let's
      invent push.recurseSubmodules to provide a default for this
      parameter. This also requires the addition of --recurse-submodules=no to
      allow the configuration to be overridden on the command line when
      required.
      
      The most straightforward way to implement this appears to be to make
      push use code in submodule-config in a similar way to fetch.
      Signed-off-by: Mike Crowe's avatarMike Crowe <mac@mcrowe.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      b33a15b0
  2. 19 Aug, 2015 3 commits
    • Heiko Voigt's avatar
      submodule: allow erroneous values for the fetchRecurseSubmodules option · 027771fc
      Heiko Voigt authored
      We should not die when reading the submodule config cache since the
      user might not be able to get out of that situation when the
      configuration is part of the history.
      
      We should handle this condition later when the value is about to be
      used.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      027771fc
    • Heiko Voigt's avatar
      submodule: use new config API for worktree configurations · 851e18c3
      Heiko Voigt authored
      We remove the extracted functions and directly parse into and read out
      of the cache. This allows us to have one unified way of accessing
      submodule configuration values specific to single submodules. Regardless
      whether we need to access a configuration from history or from the
      worktree.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      851e18c3
    • Heiko Voigt's avatar
      submodule: implement a config API for lookup of .gitmodules values · 959b5455
      Heiko Voigt authored
      In a superproject some commands need to interact with submodules. They
      need to query values from the .gitmodules file either from the worktree
      of from certain revisions. At the moment this is quite hard since a
      caller would need to read the .gitmodules file from the history and then
      parse the values. We want to provide an API for this so we have one
      place to get values from .gitmodules from any revision (including the
      worktree).
      
      The API is realized as a cache which allows us to lazily read
      .gitmodules configurations by commit into a runtime cache which can then
      be used to easily lookup values from it. Currently only the values for
      path or name are stored but it can be extended for any value needed.
      
      It is expected that .gitmodules files do not change often between
      commits. Thats why we lookup the .gitmodules sha1 from a commit and then
      either lookup an already parsed configuration or parse and cache an
      unknown one for each sha1. The cache is lazily build on demand for each
      requested commit.
      
      This cache can be used for all purposes which need knowledge about
      submodule configurations. Example use cases are:
      
       * Recursive submodule checkout needs to lookup a submodule name from
         its path when a submodule first appears. This needs be done before
         this configuration exists in the worktree.
      
       * The implementation of submodule support for 'git archive' needs to
         lookup the submodule name to generate the archive when given a
         revision that is not checked out.
      
       * 'git fetch' when given the --recurse-submodules=on-demand option (or
         configuration) needs to lookup submodule names by path from the
         database rather than reading from the worktree. For new submodule it
         needs to lookup the name from its path to allow cloning new
         submodules into the .git folder so they can be checked out without
         any network interaction when the user does a checkout of that
         revision.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      959b5455
  3. 06 Aug, 2013 2 commits
    • Jens Lehmann's avatar
      rm: delete .gitmodules entry of submodules removed from the work tree · 95c16418
      Jens Lehmann authored
      Currently using "git rm" on a submodule removes the submodule's work tree
      from that of the superproject and the gitlink from the index. But the
      submodule's section in .gitmodules is left untouched, which is a leftover
      of the now removed submodule and might irritate users (as opposed to the
      setting in .git/config, this must stay as a reminder that the user showed
      interest in this submodule so it will be repopulated later when an older
      commit is checked out).
      
      Let "git rm" help the user by not only removing the submodule from the
      work tree but by also removing the "submodule.<submodule name>" section
      from the .gitmodules file and stage both. This doesn't happen when the
      "--cached" option is used, as it would modify the work tree. This also
      silently does nothing when no .gitmodules file is found and only issues a
      warning when it doesn't have a section for this submodule. This is because
      the user might just use plain gitlinks without the .gitmodules file or has
      already removed the section by hand before issuing the "git rm" command
      (in which case the warning reminds him that rm would have done that for
      him). Only when .gitmodules is found and contains merge conflicts the rm
      command will fail and tell the user to resolve the conflict before trying
      again.
      
      Also extend the man page to inform the user about this new feature. While
      at it promote the submodule sub-section to a chapter as it made not much
      sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM".
      
      In t7610 three uses of "git rm submod" had to be replaced with "git rm
      --cached submod" because that test expects .gitmodules and the work tree
      to stay untouched. Also in t7400 the tests for the remaining settings in
      the .gitmodules file had to be changed to assert that these settings are
      missing.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      95c16418
    • Jens Lehmann's avatar
      mv: update the path entry in .gitmodules for moved submodules · 0656781f
      Jens Lehmann authored
      Currently using "git mv" on a submodule moves the submodule's work tree in
      that of the superproject. But the submodule's path setting in .gitmodules
      is left untouched, which is now inconsistent with the work tree and makes
      git commands that rely on the proper path -> name mapping (like status and
      diff) behave strangely.
      
      Let "git mv" help here by not only moving the submodule's work tree but
      also updating the "submodule.<submodule name>.path" setting from the
      .gitmodules file and stage both. This doesn't happen when no .gitmodules
      file is found and only issues a warning when it doesn't have a section for
      this submodule. This is because the user might just use plain gitlinks
      without the .gitmodules file or has already updated the path setting by
      hand before issuing the "git mv" command (in which case the warning
      reminds him that mv would have done that for him). Only when .gitmodules
      is found and contains merge conflicts the mv command will fail and tell
      the user to resolve the conflict before trying again.
      
      Also extend the man page to inform the user about this new feature.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0656781f
  4. 30 Jul, 2013 2 commits
    • Jens Lehmann's avatar
      submodule.c: add .gitmodules staging helper functions · 5fee9952
      Jens Lehmann authored
      Add the new is_staging_gitmodules_ok() and stage_updated_gitmodules()
      functions to submodule.c. The first makes it possible for call sites to
      see if the .gitmodules file did contain any unstaged modifications they
      would accidentally stage in addition to those they intend to stage
      themselves. The second function stages all modifications to the
      .gitmodules file, both will be used by subsequent patches for the mv
      and rm commands.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5fee9952
    • Jens Lehmann's avatar
      mv: move submodules using a gitfile · a88c915d
      Jens Lehmann authored
      When moving a submodule which uses a gitfile to point to the git directory
      stored in .git/modules/<name> of the superproject two changes must be made
      to make the submodule work: the .git file and the core.worktree setting
      must be adjusted to point from work tree to git directory and back.
      
      Achieve that by remembering which submodule uses a gitfile by storing the
      result of read_gitfile() of each submodule. If that is not NULL the new
      function connect_work_tree_and_git_dir() is called after renaming the
      submodule's work tree which updates the two settings to the new values.
      
      Extend the man page to inform the user about that feature (and while at it
      change the description to not talk about a script anymore, as mv is a
      builtin for quite some time now).
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a88c915d
  5. 05 Apr, 2013 1 commit
  6. 19 Nov, 2012 1 commit
  7. 29 Sep, 2012 1 commit
    • Jens Lehmann's avatar
      submodule: teach rm to remove submodules unless they contain a git directory · 293ab15e
      Jens Lehmann authored
      Currently using "git rm" on a submodule - populated or not - fails with
      this error:
      
      	fatal: git rm: '<submodule path>': Is a directory
      
      This made sense in the past as there was no way to remove a submodule
      without possibly removing unpushed parts of the submodule's history
      contained in its .git directory too, so erroring out here protected the
      user from possible loss of data.
      
      But submodules cloned with a recent git version do not contain the .git
      directory anymore, they use a gitfile to point to their git directory
      which is safely stored inside the superproject's .git directory. The work
      tree of these submodules can safely be removed without losing history, so
      let's teach git to do so.
      
      Using rm on an unpopulated submodule now removes the empty directory from
      the work tree and the gitlink from the index. If the submodule's directory
      is missing from the work tree, it will still be removed from the index.
      
      Using rm on a populated submodule using a gitfile will apply the usual
      checks for work tree modification adapted to submodules (unless forced).
      For a submodule that means that the HEAD is the same as recorded in the
      index, no tracked files are modified and no untracked files that aren't
      ignored are present in the submodules work tree (ignored files are deemed
      expendable and won't stop a submodule's work tree from being removed).
      That logic has to be applied in all nested submodules too.
      
      Using rm on a submodule which has its .git directory inside the work trees
      top level directory will just error out like it did before to protect the
      repository, even when forced. In the future git could either provide a
      message informing the user to convert the submodule to use a gitfile or
      even attempt to do the conversion itself, but that is not part of this
      change.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      293ab15e
  8. 03 Sep, 2012 1 commit
    • Jens Lehmann's avatar
      submodule: use argv_array instead of hand-building arrays · 50d89ad6
      Jens Lehmann authored
      fetch_populated_submodules() allocates the full argv array it uses to
      recurse into the submodules from the number of given options plus the six
      argv values it is going to add. It then initializes it with those values
      which won't change during the iteration and copies the given options into
      it. Inside the loop the two argv values different for each submodule get
      replaced with those currently valid.
      
      However, this technique is brittle and error-prone (as the comment to
      explain the magic number 6 indicates), so let's replace it with an
      argv_array. Instead of replacing the argv values, push them to the
      argv_array just before the run_command() call (including the option
      separating them) and pop them from the argv_array right after that.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      50d89ad6
  9. 10 Apr, 2012 1 commit
  10. 30 Mar, 2012 2 commits
  11. 13 Oct, 2011 1 commit
    • Brad King's avatar
      submodule: Search for merges only at end of recursive merge · 80988783
      Brad King authored
      The submodule merge search is not useful during virtual merges because
      the results cannot be used automatically.  Furthermore any suggestions
      made by the search may apply to commits different than HEAD:sub and
      MERGE_HEAD:sub, thus confusing the user.  Skip searching for submodule
      merges during a virtual merge such as that between B and C while merging
      the heads of:
      
          B---BC
         / \ /
        A   X
         \ / \
          C---CB
      
      Run the search only when the recursion level is zero (!o->call_depth).
      This fixes known breakage tested in t7405-submodule-merge.
      Signed-off-by: Brad King's avatarBrad King <brad.king@kitware.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      80988783
  12. 21 Aug, 2011 1 commit
  13. 09 Mar, 2011 2 commits
    • Jens Lehmann's avatar
      fetch/pull: Add the 'on-demand' value to the --recurse-submodules option · 8f0700dd
      Jens Lehmann authored
      Until now the --recurse-submodules option could only be used to either
      fetch all populated submodules recursively or to disable recursion
      completely. As fetch and pull now by default just fetch those submodules
      for which new commits have been fetched in the superproject, a command
      line option to enforce that behavior is needed to be able to override
      configuration settings.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8f0700dd
    • Jens Lehmann's avatar
      fetch/pull: recurse into submodules when necessary · 88a21979
      Jens Lehmann authored
      To be able to access all commits of populated submodules referenced by the
      superproject it is sufficient to only then let "git fetch" recurse into a
      submodule when the new commits fetched in the superproject record new
      commits for it. Having these commits present is extremely useful when
      using the "--submodule" option to "git diff" (which is what "git gui" and
      "gitk" do since 1.6.6), as all submodule commits needed for creating a
      descriptive output can be accessed. Also merging submodule commits (added
      in 1.7.3) depends on the submodule commits in question being present to
      work. Last but not least this enables disconnected operation when using
      submodules, as all commits necessary for a successful "git submodule
      update -N" will have been fetched automatically. So we choose this mode as
      the default for fetch and pull.
      
      Before a new or changed ref from upstream is updated in update_local_ref()
      "git rev-list <new-sha1> --not --branches --remotes" is used to determine
      all newly fetched commits. These are then walked and diffed against their
      parent(s) to see if a submodule has been changed. If that is the case, its
      path is stored to be fetched after the superproject fetch is completed.
      
      Using the "--recurse-submodules" or the "--no-recurse-submodules" option
      disables the examination of the fetched refs because the result will be
      ignored anyway.
      
      There is currently no infrastructure for storing deleted and new
      submodules in the .git directory of the superproject. That's why fetch and
      pull for now only fetch submodules that are already checked out and are
      not renamed.
      
      In t7403 the "--no-recurse-submodules" argument had to be added to "git
      pull" to avoid failure because of the moved upstream submodule repo.
      
      Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
      Thanks-to: Heiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      88a21979
  14. 12 Nov, 2010 2 commits
    • Jens Lehmann's avatar
      Add the 'fetch.recurseSubmodules' config setting · be254a0e
      Jens Lehmann authored
      This new boolean option can be used to override the default for "git
      fetch" and "git pull", which is to not recurse into populated submodules
      and fetch all new commits there too.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      be254a0e
    • Jens Lehmann's avatar
      fetch/pull: Add the --recurse-submodules option · 7dce19d3
      Jens Lehmann authored
      Until now you had to call "git submodule update" (without -N|--no-fetch
      option) or something like "git submodule foreach git fetch" to fetch
      new commits in populated submodules from their remote.
      
      This could lead to "(commits not present)" messages in the output of
      "git diff --submodule" (which is used by "git gui" and "gitk") after
      fetching or pulling new commits in the superproject and is an obstacle for
      implementing recursive checkout of submodules. Also "git submodule
      update" cannot fetch changes when disconnected, so it was very easy to
      forget to fetch the submodule changes before disconnecting only to
      discover later that they are needed.
      
      This patch adds the "--recurse-submodules" option to recursively fetch
      each populated submodule from the url configured in the .git/config of the
      submodule at the end of each "git fetch" or during "git pull" in the
      superproject. The submodule paths are taken from the index.
      
      The hidden option "--submodule-prefix" is added to "git fetch" to be able
      to print out the full paths of nested submodules.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7dce19d3
  15. 09 Aug, 2010 2 commits
    • Jens Lehmann's avatar
      Submodules: Use "ignore" settings from .gitmodules too for diff and status · 302ad7a9
      Jens Lehmann authored
      The .gitmodules file is parsed for "submodule.<name>.ignore" entries
      before looking for them in .git/config. Thus settings found in .git/config
      will override those from .gitmodules, thereby allowing the local developer
      to ignore settings given by the remote side while also letting upstream
      set defaults for those users who don't have special needs.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      302ad7a9
    • Jens Lehmann's avatar
      Submodules: Add the new "ignore" config option for diff and status · aee9c7d6
      Jens Lehmann authored
      The new "ignore" config option controls the default behavior for "git
      status" and the diff family. It specifies under what circumstances they
      consider submodules as modified and can be set separately for each
      submodule.
      
      The command line option "--ignore-submodules=" has been extended to accept
      the new parameter "none" for both status and diff.
      
      Users that chose submodules to get rid of long work tree scanning times
      might want to set the "dirty" option for those submodules. This brings
      back the pre 1.7.0 behavior, where submodule work trees were never
      scanned for modifications. By using "--ignore-submodules=none" on the
      command line the status and diff commands can be told to do a full scan.
      
      This option can be set to the following values (which have the same name
      and meaning as for the "--ignore-submodules" option of status and diff):
      
      "all": All changes to the submodule will be ignored.
      
      "dirty": Only differences of the commit recorded in the superproject and
      	the submodules HEAD will be considered modifications, all changes
      	to the work tree of the submodule will be ignored. When using this
      	value, the submodule will not be scanned for work tree changes at
      	all, leading to a performance benefit on large submodules.
      
      "untracked": Only untracked files in the submodules work tree are ignored,
      	a changed HEAD and/or modified files in the submodule will mark it
      	as modified.
      
      "none" (which is the default): Either untracked or modified files in a
      	submodules work tree or a difference between the subdmodules HEAD
      	and the commit recorded in the superproject will make it show up
      	as changed. This value is added as a new parameter for the
      	"--ignore-submodules" option of the diff family and "git status"
      	so the user can override the settings in the configuration.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aee9c7d6
  16. 07 Jul, 2010 1 commit
    • Heiko Voigt's avatar
      Implement automatic fast-forward merge for submodules · 68d03e4a
      Heiko Voigt authored
      This implements a simple merge strategy for submodule hashes. We check
      whether one side of the merge candidates is already contained in the
      other and then merge automatically.
      
      If both sides contain changes we search for a merge in the submodule.
      In case a single one exists we check that out and suggest it as the
      merge resolution. A list of candidates is returned when we find multiple
      merges that contain both sides of the changes.
      
      This is useful for a workflow in which the developers can publish topic
      branches in submodules and a separate maintainer merges them. In case
      the developers always wait until their branch gets merged before tracking
      them in the superproject all merges of branches that contain submodule
      changes will be resolved automatically. If developers choose to track
      their feature branch the maintainer might get a conflict but git will
      search the submodule for a merge and suggest it/them as a resolution.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      68d03e4a
  17. 25 Jun, 2010 1 commit
    • Jens Lehmann's avatar
      Add the option "--ignore-submodules" to "git status" · 46a958b3
      Jens Lehmann authored
      In some use cases it is not desirable that "git status" considers
      submodules that only contain untracked content as dirty. This may happen
      e.g. when the submodule is not under the developers control and not all
      build generated files have been added to .gitignore by the upstream
      developers. Using the "untracked" parameter for the "--ignore-submodules"
      option disables checking for untracked content and lets git diff report
      them as changed only when they have new commits or modified content.
      
      Sometimes it is not wanted to have submodules show up as changed when they
      just contain changes to their work tree (this was the behavior before
      1.7.0). An example for that are scripts which just want to check for
      submodule commits while ignoring any changes to the work tree. Also users
      having large submodules known not to change might want to use this option,
      as the - sometimes substantial - time it takes to scan the submodule work
      tree(s) is saved when using the "dirty" parameter.
      
      And if you want to ignore any changes to submodules, you can now do that
      by using this option without parameters or with "all" (when the config
      option status.submodulesummary is set, using "all" will also suppress the
      output of the submodule summary).
      
      A new function handle_ignore_submodules_arg() is introduced to parse this
      option new to "git status" in a single location, as "git diff" already
      knew it.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      46a958b3
  18. 14 Mar, 2010 1 commit
  19. 05 Mar, 2010 1 commit
    • Jens Lehmann's avatar
      git diff --submodule: Show detailed dirty status of submodules · c7e1a736
      Jens Lehmann authored
      When encountering a dirty submodule while doing "git diff --submodule"
      print an extra line for new untracked content and another for modified
      but already tracked content. And if the HEAD of the submodule is equal
      to the ref diffed against in the superproject, drop the output which
      would just show the same SHA1s and no commit message headlines.
      
      To achieve that, the dirty_submodule bitfield is expanded to two bits.
      The output of "git status" inside the submodule is parsed to set the
      according bits.
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c7e1a736
  20. 25 Jan, 2010 1 commit
  21. 17 Jan, 2010 1 commit
  22. 20 Oct, 2009 1 commit