search

PortableApps / Launcher

The PortableApps.com Launcher™ allows developers, publishers and even technical end-user to portablize apps in PortableApps.com Format without needing to write any code.
https://portableapps.com/apps/development/portableapps.com_launcher
GNU General Public License v2.0
43 stars 13 forks source link

We're on GitHub now (+ minor doc improvements) #8

Closed 3D1T0R closed 6 years ago

3D1T0R commented 6 years ago

We've moved to Git on Github, so we should probably update the documentation so that it doesn't say to use Mercurial (hg) on SourceForge.

Also, there were a couple of broken links and a few minor issues (missing ), bad grammar, "Most" vs "Many") which I've included fixes for in this PR.

GordCaswell commented 6 years ago

Note: This repository will continue to remain protected, requiring pull requests for merges.

3D1T0R commented 6 years ago

Ow, you squashed my commits. Squashed merges are good for some situations, but I had actually kept those two commits separate on purpose (because I felt it was tidier for the 'move-to-github' commit to be by itself). Oh well, what's done is done. Anyway, for future reference, there are three methods GitHub makes available for merging: With a merge commit (best for "non-linear" commit histories), By squashing (best for simplifying the commit history of either a big feature, or a messy Pull Request into a single commit), or Rebasing (best for fairly simple commit histories which can be made "linear") where each commit in the head branch gets cherry-picked onto the base branch. This particular instance would have best fit a "Fast-forward" merge, where the base branch is 'reset' to the latest commit on the head branch (effectively adding the exact commits from the head branch to the base branch), which GitHub no longer advertises, however a "Rebase" merge (having no need to actually rebase, since the head branch's commits are already based on the latest commit on the base branch) would have done this.

Again, just an FYI for the future.