We’ll create a simple project: An HTML page with some styles. Chapter 1 - Module Repository Within a Repository Throughout this article, tilde ~ marks our “projects” directory. Module files are available for each clone, but are not stored within the main project’s repository online. The essence of a Git submodule is that it’s just a directory in our project which points to, well, another git repository.
Git add remote submodule code#
> out the submodule.A Git submodule is a fast and neutral way to re-use code across multiple projects and in different technologies. > *always* uses the remote named "origin" to form the ref used to check
Git add remote submodule update#
> I'd therefore like to propose that "git submodule update -remote" > the equivalent problem that arises if the remote tracking branch *is* > One way this could be fixed is that if turns out to be "HEAD", > branches from the submodule's "origin" remote. > meaning that the second call always looks up the remote tracking > because the first call puts all the submodules into detached HEAD state, > -remote" twice in quick succession would leave us in a different state,
> It also makes very little sense to me that issuing "git submodule update > quite out of date compared to origin/master. > checked out on a tracking branch or not: myfork/master is potentially > change depending on whether I happen to have left one of the submodules > submodule update -remote", I personally normally do so as a shortcut > In practice, that's not actually what I'd want, though. > been created by the "git remote add" command, reflecting that remote's > First observation: a ref called "myfork/HEAD" presumably *could* have > up the name of the remote which is being tracked > people access to the branch during the review process) then it looks > uncommon in pull request workflows because you might grant other > * but if it's a tracking branch (as I used in my workflow above - not > * if its branch is not a tracking branch, "origin" is also used > * if it's in detached HEAD state, is set to "origin" > but in practice, it depends on how the submodule is currently checked > The change in git 2.27.1 is that if no remote tracking branch is stated > used is formed by looking up the submodule's ref "/". > What's going on is that within "git submodule update -remote", the sha1 > fatal: Needed a single revision Unable to find current myfork/HEAD
> Some more time passes, and I want to work on it again. > $ git pull $ git submodule update -remote > implement a new feature in the library, so I start by ensuring both are > ago, so that the master branches between it and my fork have diverged. > remotes, one for pulling in other people's changes, and one for
> upstream repository uses a fork workflow, so the submodule has two > The scenario: I have a repository with a submodule. I'm not sure what the best way to fix things is, so can I > also got me wondering about whether some related functionality is > A recent-ish change in git 2.27.1, introduced in commit f0a96e8d, has It displays more readably in the list archive, and also so thatĪnyone else can choose to quote you from this. I am also reposting your message, adding hard line breaks so that
0 kommentar(er)
