Take notethis commit is from 1 month ago and not identical to the master branch.
Take note this README.md on "v1.4.0" branch does NOT have a "Support" section at the bottom of it.
Expected behaviour
User git clones master branch and it is identical to the v1.4.0 release (again as we see it is not since there are differences in the two README.md files)
OR user downloads v1.4.0.tar.gz, unextracts files, needs help but no support section listed in that README.md.
Why this is important: So the README.md is the same, so it is clear which one I can edit to include the necessary pre-req for SDL compilation as this is missing from the current documentation.
@duke no confusion on this issue, so a better explaination is required
Steps to reproduce issue:
1. Navigate to https://git.hush.is/hush/SilentDragonLite
1. **Take note** this README.md on master branch has a "Support" section at the bottom of it.
1. See that the master branch is on a [commit](https://git.hush.is/hush/SilentDragonLite/commit/31a607a88f8fefe921e036567cb3a2153d590f38) from 2 months ago.
1. Click on releases
1. Click on [v1.4.0 tag](https://git.hush.is/hush/SilentDragonLite/src/tag/v1.4.0)
1. **Take note** [this commit](https://git.hush.is/hush/SilentDragonLite/commit/341450c8c81849578a7823370dc28b574b269997) is from 1 month ago and not identical to the master branch.
1. **Take note** this README.md on "v1.4.0" branch does NOT have a "Support" section at the bottom of it.
Expected behaviour
1. User git clones master branch and it is identical to the v1.4.0 release (again as we see it is not since there are differences in the two README.md files)
1. OR user downloads v1.4.0.tar.gz, unextracts files, needs help but no support section listed in that README.md.
**Why this is important: So the README.md is the same, so it is clear which one I can edit to include the necessary pre-req for SDL compilation as this is missing from the current documentation.**
@jahway603 this seems to come from not understanding how Git works. Let me explain.
A tag is a pointer to a SHA commit hash. Once it's created, Git will complain loudly
if a tag changes, by default, once a tag points one place, Git will not change your local tags because a remote changed the tag. A tag is just a variable name, and what the tag points to is the data inside the variable.
You seem to want to automate all the work I do to produce releases, and don't understand that the master branch, dev branch, duke branch and danger branches are constantly moving and NEVER are promised to equal any tag. If you want any given specific tag, checkout that tag via git checkout v1.4.0
I suggest you update the docs to checkout a specific tag, otherwise people will get whatever is on the branch they check out.
@jahway603 this seems to come from not understanding how Git works. Let me explain.
A `tag` is a pointer to a SHA commit hash. Once it's created, Git will complain loudly
if a tag changes, by default, once a tag points one place, Git will not change your local tags because a remote changed the tag. A tag is just a variable name, and what the tag points to is the data inside the variable.
You seem to want to automate all the work I do to produce releases, and don't understand that the master branch, dev branch, duke branch and danger branches are constantly moving and NEVER are promised to equal any tag. If you want any given specific tag, checkout that tag via `git checkout v1.4.0`
I suggest you update the docs to checkout a specific tag, otherwise people will get whatever is on the branch they check out.
@jahway603 this is how you check where a tag points. My v.1.4.0 tag points to master, does yours? Make sure you have merged origin/dev into your local dev to see things correctly. If you did a "git pull" on master, your local dev and origin/dev will be different.
```
$ git rev-parse v1.4.0
341450c8c81849578a7823370dc28b574b269997
$ git rev-parse master
341450c8c81849578a7823370dc28b574b269997
```
@jahway603 this is how you check where a tag points. My v.1.4.0 tag points to master, does yours? Make sure you have merged origin/dev into your local dev to see things correctly. If you did a "git pull" on master, your local dev and origin/dev will be different.
Please merge dev into master to reflect the latest release 1.4.0 code.
@jahway603 I think you are confused
@duke no confusion on this issue, so a better explaination is required
Steps to reproduce issue:
Expected behaviour
Why this is important: So the README.md is the same, so it is clear which one I can edit to include the necessary pre-req for SDL compilation as this is missing from the current documentation.
@jahway603 this seems to come from not understanding how Git works. Let me explain.
A
tagis a pointer to a SHA commit hash. Once it's created, Git will complain loudlyif a tag changes, by default, once a tag points one place, Git will not change your local tags because a remote changed the tag. A tag is just a variable name, and what the tag points to is the data inside the variable.
You seem to want to automate all the work I do to produce releases, and don't understand that the master branch, dev branch, duke branch and danger branches are constantly moving and NEVER are promised to equal any tag. If you want any given specific tag, checkout that tag via
git checkout v1.4.0I suggest you update the docs to checkout a specific tag, otherwise people will get whatever is on the branch they check out.
@jahway603 this is how you check where a tag points. My v.1.4.0 tag points to master, does yours? Make sure you have merged origin/dev into your local dev to see things correctly. If you did a "git pull" on master, your local dev and origin/dev will be different.
This is now not an issue with the latest 1.5.0 release.