pinoykeron.blogg.se - Github desktop submodules

#GITHUB DESKTOP SUBMODULES UPDATE#
#GITHUB DESKTOP SUBMODULES UPGRADE#
#GITHUB DESKTOP SUBMODULES FULL#
#GITHUB DESKTOP SUBMODULES CODE#

The full clone of Jira is 677MB, with the working directory being another 320MB, made up of more than 47,000+ commits. The time savings for repos like this can add up and be very noticeable.

#GITHUB DESKTOP SUBMODULES CODE#

For example, we migrated Jira (an 11 year-old code base) to Git. Imagine you accumulated ten or more years of project history in your repository. How do you do it? Just use the –depth option. Git’s shallow clone option allows you to pull down only the latest n commits of the repo’s history. The first solution to a fast clone and saving developer’s and system’s time and disk space is to copy only recent revisions. Some repos have to be kept in tact for legal or regulatory reasons. And you can’t always avoid long histories. Cloning repositories with a very long historyĮven though threshold for a qualifying a repository as “massive” is pretty high, they’re still a pain to clone. The techniques and workarounds for each scenario are different, though sometimes complementary. But there’s a moderately easy – if annoying – fix for that (see below). Sometimes the second type of problem is compounded by the fact that old, deprecated binary artifacts are still stored in the repository.

They include huge binary assets that need to be tracked and paired together with code.

They accumulate a very very long history (the project grows over a very long period of time and the baggage accumulates).

If you think about it there are broadly two major reasons for repositories growing massive: In this post I’ll give you some techniques for dealing with it. But what happens when the repository you want to track is really really big?

Follow me on Twitter for weekly articles and daily tweets on git.Git is a fantastic choice for tracking the evolution of your code base and collaborating efficiently with your peers.

Subscribe to my Medium publishes to get notified when a new Git Weekly issue is published.

Now, add the submodule and commit it: git add shared git commit -m "Rewind the commits" Final Words

This means the two mentioned commits were removed from the submodule (rewind). It will list the commits that were added or removed, e.g.: Submodule shared 43222e8.569d7ce (rewind): < Add venv and pyc files to. To see what changes you made to the submodule, do: git diff -submodule Now that you’re happy with the submodule state/version, you can get back to the original repo: cd. First, find out the hash and checkout to it: git checkout bfa784412503902f1d07edacb2e0e0954e2e221f Get Back and Commit Now let’s assume you want to change the state to a specific commit. To go one commit back, one can checkout HEAD~1: git checkout HEAD~1 3. We’ll cover checkout vs switch in a later post. This command is the same as: git checkout specific-branch

#GITHUB DESKTOP SUBMODULES UPDATE#

Where specific-branch is the name of the branch you want to update your submodule to. To update your submodule to a specific branch or tag, simply switch to that branch or tag: git switch specific-branch Now, all we want to do is to change the state of the submodule repo. no branch or tag points to that specific commit. The “HEAD detached” state basically means that your current state of the submodule “has no name”, i.e. If you have a terminal that shows the branches, it’ll most likely show you a hash instead of a name: ~/the-repo/shared $Īnd the output will be something like: * (HEAD detached at 569d7ce) master Change your directory to this branch: cd shared Let’s assume your submodule is under the path shared. a specific tag on the other repo or a specific branch, or even a specific commit.

#GITHUB DESKTOP SUBMODULES UPGRADE#

Now let’s assume you want to upgrade (or downgrade) your submodule state to a specific version, e.g. git commit -m "Update submodule to use Python 3.9" Updating Submodule to a Specific Version If the submodule is not separately versioned, try to mention why the submodule was updated. It’s also important to have a meaningful commit message for it. To review the commits that were added to the submodule, do: git diff -submoduleĪfter the code was tested against the new submodule version, commit the submodule by staging its path: git add git commit -m "Update submodule to version XXX" To update your submodule to its latest version, do: git submodule update As an upgrade to the latest version of your dependency might break your code, so does an update to the latest version of the submodule.

Submodules are like versioned third-party libraries.