• Sourcetree Macos 10.13
• Sourcetree Latest Version
• Sourcetree For Mac
• Sourcetree App Download

Sourcetree 3.0 - Major Release 23 October 2018 Note: this release is only compatible with macOS High Sierra 10.13 or higher Note: your 2.x diff color preferences will be upgraded for use with 3.x Changes. Robust support for additional hosting services (SSH, Repos. Sourcetree suffers from multiple remote code execution vulnerabilities related to git submodules and argument injection. MacOS versions 1.0b2 up to 2.7.6 and Windows versions 0.5.1.0 up to 2.6.10 are affected.

Free mac cad software download. tl;dr (see table)

Posts about 10.13 written by Liviu Ionescu (ilg). Apple continuously enhanced the security of recent macOS versions and with High Sierra 10.13 it introduced a new. MacOS (10.13) CLI comes with Xcode, SourceTree for a nice GUI application: Windows (10) SourceTree. Download and install the app: Linux (Ubuntu 16.x, CentOS 7.x) Use your package manager to install git.

Submodules can be a great tool for sharing library code and I like to make use of them when working with Unity. In this article I share my notes on my experiments around git submodules in Unity projects.

The development model I have in mind looks like this: I like to have on or more product project sharing one or more library project and want to able to commit, push and pull in each of them. Also I want to have reproducible connections between the project and the library code. So if I check out an old commit of a product it shall checkout the matching library project commit as well. All this without Unity plugins or the need of none-git work before or after the code change. No Unity packaging. No extra steps when committing.

To use this model one has to solve one issue: Unity (in it’s current state) forces the game creator to put all source-codes and assets into one folder named: Assets. As I had several ways in mind how I could solve this I took the liberty to write down my approaches and share them here.

I’m using Unity 2017.4.11f1, macos 10.13.6 and Sourcetree 3.0.0.

Approach

The test case is made of one product project and one library project. Both are complete Unity projects. In this approach I like to see if I can simply link the library project as a sub-folder into the Assets folder of the product project.

Being lazy I try this without using a remote git-repo.

The initial structure looks like this:

First I want each project to be in it’s own repository. Then I like to inject lib1 as a submodule into proj1:

The result should look something like this:

Setup

To set this up we first create the project structure. Then we need to create the repositories in each folder. I use Sourcetree for this.

For each folder: Matrix jewelry design software, free download mac.

1. Create a repo
2. Create a .gitignore
3. Commit (master branch)

Now we have two repos with one commit in each.

The next step is to link lib1 into the main project. For that I do in Sourcetree this:

1. Open proj1
2. Right-Click on submodules -> Add Submodule
3. Source Path: Navigate to the root folder of lib1
4. Set local relative path (in proj1): Asssets/lib1
5. Say “okay”
6. Two modified files appear in proj1 (they are already staged)
7. We need to commit the changes

Basically that’s it. Now the library project is part of proj1.

Be careful: If you create a submodule in Sourcetree it automatically stages the files for you. You only have to commit them. Never unstage the initial submodule files. I incidentally unstaged them and created an incompatible state and I had to setup everything again.

Testing

Let’s see how this setup works and do some tests.

• Use case: modify a file in lib1 (the lib project itself not in the submodule)
  • Edit lib1_file.txt
  • The change is visible in lib1
  • I commit the change in lib1
  • Let’s see if we can get that into proj1/lib1
  • proj1/lib1 shows one pull request.
  • Pulling brings the change into proj1!
• Use case: modify a file in proj1/lib1
  • Edit lib1_file.txt
  • The change is visible in proj1 (submodule changed)
  • The change is also visible in proj1/lib1, in the submodule.
  • I can commit the change in proj1/lib1, in the submodule.
  • However, I can’t push.
  • Reading the error message it’s because the origin is a bare repository. Bare Repository. Welp. I don’t really get it, but what I get that it is related to the fact that I don’t use a remote origin.

Result

• I got exactly the desired structure.
• I can make changes in the lib1 project.
• I can read all changes in proj1/lib1
• I cannot write changes from proj1/lib1 to lib1 (commit: yes, pull: no)
• For submodules we need an remote-origin

Approach

Create proj1, lib1 and create a remote repository for both of them. Then basically check if we get around the issue of Test 1.

Setup

Generate the following structure:

1. We create both as local repositories
2. We create the counter parts on a remote git
3. We combine the projects by setting up the remote repository
4. Now we add lib1 to proj1, however this time the remote repo
5. We commit the changed module files. DON’T UNSTAGE HERE ;)
6. We commit the changes to the remote as well

That’s it. Now let’s test.

Testing

• Use case 1: modify a file in lib1 (the lib project itself not in the submodule)
  • changed lib1_file.txt in lib1 folder
  • comitted the change
  • pushed the change
  • proj1/lib1 does not show the change. Which is what we want.
  • opening the project proj1/lib1 shows that we can pull a change
  • this changed the proje1/lib1 submodule. This makes sense as our pull changed the commit-pointer we have in proj1.
  • we commit and push that submodule too
  • Now we have the modified file in the origin as well
• Use case 2: modify a file in proj1/lib1
  • changed lib1_file.txt in proj1/lib1 folder
  • The change becomes visible in proj1 lib1 submodule. 3 little dots.
  • We open proj1/lib1. It shows the modified content
  • We commit the changes
  • We push it to the origin.
  • This time it works!
  • Going back to proj1/lib1 we see the submodule has changed
  • We commit that and we are done in proj1.
  • If we check in lib1 we can see the modification in the origin.
• Use case 3: Test in unity
  • Open proj1 in Unity
  • Unity says: You are trying to import an asset which contains a global game manager. This is not allowed.

Results

• Git submodule setup works.
• We can have two repositories, link them together and work in both of them.
• We can modify content in the library and also in the project.
• Both can fetch from each other.
• This supports a structure where we can have one or more projects share some nice generic libraries that we use a lot and update from time to time.
• Unity doesn’t like a complete sub-project in the Assets folder.
• The UnityPackageManager or ProjectSettings cause this to fail. If we had a setup which would ignore those it would work.

Approach

Using submodules we can import an entire library project into another project. However, our library folder is packed with the entire Unity project. In Test 2 I found out Unity doesn’t like that at all.

My next thought was: “maybe we can create a submodule-link that points only to a subfolder of the library”. But from what I read it seems we can’t use a subfolder in git-submodules.

There is another option in git called Subtrees. Maybe they can help? In this test I will check if it is possible to use a linked subtree to only the get Assets content of lib1 into proj1 and still being able to update content for both.

Setup

The result should look like this:

1. We create a new parent project: proj1
2. We set it up as a local git repo
3. We do the initial commit
4. We add the remote lib1 as subtree: rightclick on submodule -> Add/Link Subtree
5. We select the lib1 remote project with the Asset path:https://.git/Assets
6. Squash commit? https://stackoverflow.com/a/35704829. Not now.

Testing

• Doesn’t work? I can’t find any content in the subtree folder
• While reading into this. I realized it’s the wrong tool.

Results

• Bad approach. Subtree’s isn’t the right tool here:
• Subtree is more or less an import and not a link. (details.)
• Too bad :(

Approach

Consider Unity Package manager.

Result

• Hm… reading into all this I’m not really motivated to follow that approach.
• Also I need a solution that works in older Unity versions too (some clients have this requirement).

Approach

In this test I like to follow the approach from prime31. I setup the submodule in proj1. However, I don’t put it into the Assets folder. Instead we use a folder next to Assets. Then we link the content of that directory as a symbolic link into the Assets folder.

Setup

We create two Unity projects.

Then we link the entire lib1 project into a subdirectory and link the content of lib1. Like this:

Sourcetree Macos 10.13

1. Create two Unity projects
2. Create the local git repositories
3. For lib1 we create and push it to an remote-origin
4. We create a submodule folder in proj1
5. We initialize lib1 as submodule in proj1/submodules
6. Now we link the folder of lib1 assets using:

Testing

Sourcetree Latest Version

• Creating link succeeded
• The structure looks as expected
• Using pwd in proj1/Assets/lib1 looks alright
• Open proj1 in Unity works without issues
• Sourcetree shows proj1/Assets/Lib1 as a new folder. Which is fine
• Committing proj1/Assets/Lib1 works without issue
• Now let’s edit a file in lib1, commit and push it
• Let’s see if we can pull the change in proj/lib1
• Open proj1/lib1 in Sourcetree shows that we can pull something
• Pull proj1/lib1
• Checking Sourcetree it works perfectly!
• Checking Unity it works perfectly!
• In Sourcetree I see the changed submodule-link
• In Unity I see the updated file
• Now let’s check if we can modify a file in proj1/Assets/Lib1
• In Sourcetree it shows modified submodule content. Perfect!
• Open proj1/lib1 in Sourcetree shows the modified file. Let’s commit that

Result

• It just works

Final words

Sourcetree For Mac

Using symbolic links we have fully working solution: Git-submodules in Unity with only a little headache. We can work on one or more library from multiple projects.

The only downside is a little extra work every time we add or remove a submodule to update the symbolic link. This introduces some problems when it comes to automatic building. Also it requires us to consider platforms. On Win32 this won’t work with the same commands. Using git-hooks this maybe can be automated.

Sourcetree App Download

In the end it’s an practmatic approach and I like it. Thanks prime31 :)