Merge branch 'development' into releases/3.0.7

.github/workflows/ci.yml

@@ -16,17 +16,14 @@ jobs:
       fail-fast: false
       matrix:
         node: [16.13.0]
-        os: [macos-10.15, windows-2019]
+        os: [macos-11, windows-2019]
         arch: [x64, arm64]
         include:
-          - os: macos-10.15
+          - os: macos-11
             friendlyName: macOS
           - os: windows-2019
             friendlyName: Windows
     timeout-minutes: 60
-    env:
-      # Needed for macOS arm64 until hosted macos-11.0 runners become available
-      SDKROOT: /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk
     steps:
       - uses: actions/checkout@v3
         with:

.github/workflows/release-pr.yml

@@ -37,7 +37,7 @@ jobs:
           private_key: ${{ secrets.DESKTOP_RELEASES_APP_PRIVATE_KEY }}
 
       - name: Create Release Pull Request
-        uses: peter-evans/create-pull-request@v4.0.4
+        uses: peter-evans/create-pull-request@v4.1.1
         if: |
           startsWith(github.ref, 'refs/heads/releases/') && !contains(github.ref, 'test')
         with:

app/src/lib/editors/darwin.ts

@@ -132,6 +132,10 @@ const editors: IDarwinExternalEditor[] = [
     name: 'Nova',
     bundleIdentifiers: ['com.panic.Nova'],
   },
+  {
+    name: 'Emacs',
+    bundleIdentifiers: ['org.gnu.Emacs'],
+  },
 ]
 
 async function findApplication(

changelog.json

@@ -4,6 +4,10 @@
       "[Fixed] Do not show login prompt when repositories are fetched - #15163",
       "[Improved] On Apple silicon devices running unoptimized builds, auto-update on first run to an optimized build - #14998"
     ],
+    "3.0.7-beta1": [
+      "[Added] Add Emacs integration for macOS - #15130. Thanks @zipperer!",
+      "[Fixed] Do not show login prompt when repositories are fetched - #15163"
+    ],
     "3.0.6": [
       "[Added] Add Warp terminal integration for macOS - #14329. Thanks @lhvy!",
       "[Added] Add context menu to the Current Branch and Current Repository toolbar - #13148. Thanks @uttiya10!",
@@ -18,7 +22,6 @@
       "[Fixed] Fix commit description with three lines overflowing when it shouldn't - #14791. Thanks @HeCorr!",
       "[Fixed] Fix notifications on Windows 10 builds prior to the Creators Update - #14714",
       "[Fixed] 'Update from default branch` menu item allows quick merge of upstream - #14145. Thanks @uttiya10!",
-      "[Improved] On Apple silicon devices running unoptimized builds, auto-update on first run to an optimized build - #14998",
       "[Improved] Add ability to skip staggered release to ensure the latest version is downloaded - #14883"
     ],
     "3.0.6-beta3": [

docs/learn-more/unreachable-commits.md

@@ -0,0 +1,67 @@
+# Reachable and Unreachable Commits
+
+In Git, every commit will have at least one parent commit except the very first. Additionally, a repository may have any number of branches that begin at any particular commit. Because of this we can create a graph of the history of a commit by following the path from one commit's parent to the another. Given a branch `main`, whose initial commit is `A`, and we add commit `B` and `C`, the resulting graph would be as follows:
+
+```mermaid
+    gitGraph
+       commit id: "A"
+       commit id: "B"
+       commit id: "C"
+```
+
+Since we can follow the graph from `C` to `A`, that means that `A` is **reachable** by or from `C`. This as known as following the ancestral path of `C`.
+
+## Unreachable Commits
+Now, if we create a new branch called `feature-branch` from `C` and commit `D` and `E` and then return to `main` and commit `F`. We would have the resulting graph:
+
+```mermaid
+    gitGraph
+       commit id: "A"
+       commit id: "B"
+       commit id: "C"
+       branch feature-branch
+       checkout feature-branch
+       commit id: "D"
+       commit id: "E"
+       checkout main
+       commit id: "F"
+```
+
+In the above example, `B` is reachable by `F` through the ancestral path of `F`-> `C` -> `B`,  and `B` is reachable by `E` through `E` -> `D` -> `C` -> `B`. However, there is no such path to get to `E` or `D` from `F`. Thus, `E` and `D` are **unreachable** from `F`.
+
+## Git Commands Use the Ancestral Path
+Some Git commands use the ancestral path to determine what to show. One of those is `git diff`, which is used to see the changes between two commits non inclusive of the first commit. If we execute `git diff A..C`, we will receive the set of changes from the commits along the ancestral path from `C` to `A` or `C` -> `B` -> `A`. Thus, we would see changes from `B` and `C`. Likewise, if we executed `git diff B..F`, we will get changes from reachable from `F`; thus, `F` -> `C` -> `B`. But, not changes from `E` and `D` as they are unreachable.
+
+## Merge Commits
+Now, let's say that we merge the `feature-branch` into our `main` branch. Our graph becomes:
+
+```mermaid
+    gitGraph
+       commit id: "A"
+       commit id: "B"
+       commit id: "C"
+       branch feature-branch
+       checkout feature-branch
+       commit id: "D"
+       commit id: "E"
+       checkout main
+       commit id: "F"
+       merge feature-branch tag: "G"
+```
+
+Still `E` and `D` are unreachable by `F`. But, you may think "I merged the `feature-branch` into `main`, so I should be able to see changes from `E` and `D`." This is true if you start at a commit that has them in its ancestral path. That is `G` and it is known as a **merge commit**, and it is special in that it has two parents. The first is `F` as the last commit of the branch being merged into, and `E` as the last commit of the branch being merged. Now, all the commits in this graph are ancestors of `G`. Thus, if we were to execute `git diff B..G`. We will see changes of all ancestral paths of `G` to `B`. Those paths are `G` -> `F` -> `C` -> `B` and `G`-> `E` -> `D` -> `C` -> `B`. Therefore we will see changes from `G`, `F`, `E`, `D`, and `C`.
+
+# GitHub Desktop
+In GitHub Desktop, commits are displayed linearly and in chronological order. Thus, the graph from the previous section `Merge Commits` would look like:
+
+![image](../assets/unreachable-commits-history.png)
+
+In GitHub Desktop, diffing across multiple commits is accomplished through a range selection that results in executing `git diff`, which shows the changes of comparing the first and last commit in the selection (inclusive). Therefore, generating a diff on a branch where merge commits exist may result in unreachable commits being inside a diff selection. The following shows the unreachable commit scenario described above in `Merge Commits`.
+
+![image](../assets/unreachable-commits-demo.gif)
+
+
+
+
+
+

docs/technical/editor-integration.md

@@ -235,6 +235,7 @@ These editors are currently supported:
  - [JetBrains Rider](https://www.jetbrains.com/rider/)
  - [Nova](https://nova.app/)
  - [Aptana Studio](http://www.aptana.com/)
+ - [Emacs](https://www.gnu.org/software/emacs/)
 
 These are defined in a list at the top of the file: