Working with subtrees in a second working copy

Suppose we have two developers. One developer added a subtree to the “main” git repository at foo/bar/ path (foo/ is a normal directory and foo/bar/ now is connected as a subtree to a separate “subtree” repository). The second developer pulled changes and got foo/bar/. However at his working copy foo/bar/ is not a subtree to git, it is just a directory in the main repository.

Now the second developer got the task to switch that subtree to a newer tag in the subtree repository. He thinks he can pull from the subtree repository using git subtree pull but than he needs to add a substree first. But git subtree add in his working copy does not work because the directory already exist. In his working copy this directory does not look like a subtree to git.

  • How do I programmatically upload a file to a github repo's Downloads area?
  • Copy a single commit from another branch, with no new commits
  • Using Git or Mercurial, how would you know when you do a clone or a pull, no one is checking in files (pushing it)?
  • How to resolve Git error: “fatal: BUG: get_tempfile_fd() called for inactive object”
  • Cannot Pull b/c “You have unstaged changes”, but status says there are no changes
  • Git diff : compare specific versions of specific file
  • Questions:

    • How can the second developer tell git that foo/bar/ is actually a subtree?
    • How can he checkout a tag for this subtree?

  • Configure git to track only one file extension
  • GIT — push everything to remote server, but with only with one log entry
  • When I am using Git, should I rebase before I merge?
  • Can't commit update-index on Windows
  • Git Revert and then commit but want to keep revision before revert
  • Is the “assume-unchanged” information committed?
  • 2 Solutions collect form web for “Working with subtrees in a second working copy”

    I don’t believe subtree has any built-in method to let the second developer know a subdirectory is actually a git subtree. The best way to indicate that may be with a file in the root of the subtree (which is not ideal I’ll admit).

    The second developer in your example, shouldn’t have to do a git subtree add though. They should only have to do a pull followed by a push (again, they’ll need some other way of knowing where it all came from).

    To update the subtree, the second developer would:
    (NOTE: I’m new to subtree, so take this for what it’s worth)

    1. Make their changes as usual
    2. Commit their changes to the ‘main’ repository
    3. Push their changes to the ‘main’ repository
    4. Do a pull from the subtree: git subtree pull --prefix=bar ../bar.git master
    5. Do a push to get their changes in the subtree: git subtree push --prefix=bar ../bar.git master

    The whole point of subtrees (in contrast to submodules) is that they do not look like repositories and do not need any configuration files. git-subtree encodes all required information for subsequent merges in the initial merge commit, using a “git-subtree-” prefix, so there really is no difference between the two developers’ working copies in your example. Both will equally be able to git subtree pull ....

    If you want to have explicit (i.e. recognizable) sub-repositories that can be easily updated from upstream, use git submodule.

    Git Baby is a git and github fan, let's start git clone.