Update SSP Shear Strength Symbol

[Nathaniel-Hu]

• contains all changed files related to updating the Shear Strength Symbol from tau to tau^f for SSP
• i.e. Unitals.hs, SSP_SRS.tex, SSP_SRS.html
• to address Issue SSP: fixing scalar vector mismatch #2156 Item 1

[Nathaniel-Hu]

@smiths and @JacquesCarette, I created branch Issue#2156 to store all my changes to address Issue #2156. It is possible for me to use this same branch multiple times for multiple pull requests for multiple changes linked to the same issue, correct?

[bmaclach]

@Nathaniel-Hu You can, but the problem is that you can't have multiple PRs for the same branch open at the same time. If you push more commits to the same branch after opening a PR, those commits will get added to the open PR, which is usually not what we want.

What I usually did instead was create another new branch off of the first one (so in your case, branch off of the Issue#2156 branch). Then you have all of the changes from the first branch, but you can create a separate PR for the new branch. Then you should note in the description for your 2nd PR that it is dependent on the 1st one, so the 1st one should be merged first.

I don't think the Contributor's guide is accurate with regards to this, so you probably want to update that. @smiths or @JacquesCarette may have different thoughts about how best to do this too, so maybe wait for their input as well.

[smiths]

The changes to stable look good to me. Although only a small change to a symbol, it is a meaningful change. This is where Drasil works well, since one small change impacts several files automatically. The benefit is even more pronounced when we are also generating code.

I don't see any problems with the changes to the Haskell code, but we'll wait for @JacquesCarette to review before merging the PR.

[smiths]

@bmaclach, your advice sounds like the right approach to me. Assuming @JacquesCarette agrees, this is something that we should explicitly state in the Contributor's Guide.

[Nathaniel-Hu]

Ok then. Thanks for the insight @bmaclach. :)

[JacquesCarette]

If this closes an issue, please say so specifically. From the discussion above, I won't delete this branch (yet), but ask if you want me to.

[Nathaniel-Hu]

@JacquesCarette, this pull request was meant to be 1 of 4 that would be made in order to close Issue #2156 (as per @smiths requests). I will make sure to include whether the PR closes the issue or not in my next PRs.

As per Brooks' comment, am I good to go and create a new branch off of branch Issue#2156 for my next PR? Also, @bmaclach for my 3rd PR, do I make it based off of the 2nd PR's branch, and then do the same for the 4th PR off of the 3rd PR Branch?

[bmaclach]

@Nathaniel-Hu Assuming each PR requires the changes from the previous PR, yes. That may not be the case though (for example, looking at part 2 of #2156, it seems like it doesn't use the symbol from part 1, so that one may not actually be dependent). If you are not sure, a way that you can check whether two PRs are dependent is to assume that they are dependent (so branch off of the 1st PR's branch for the 2nd PR), then, after committing the changes (but before pushing), run:

git rebase --onto master old-branch-name new-branch-name

where old-branch-name should be replaced with the name of the previous branch, and new-branch-name should be replaced with the name of the current branch. This will attempt to re-structure the branches so that new-branch-name is branched directly off of master, instead of off of old-branch-name. If this succeeds, then the two branches aren't actually dependent, and new-branch-name will now be a branch off of master, which is what you would want in that case. If it fails saying there are conflicts, that means new-branch-name really was dependent on old-branch-name. That means the original structure of the branches was correct, so you can run git rebase --abort to revert back to that structure.

Also, since this PR has been merged now, you should just create a fresh branch from master for the future changes. If you already branched off of Issue#2156 and started to work on part 2, you can run the above git rebase --onto ... command to make it so your new branch is directly off of master (just remember to git pull on master first). Note that this only works if you haven't pushed the new branch to GitHub yet.

Let me know if any of this isn't making sense.

[Nathaniel-Hu]

@bmaclach thanks for the insight. I have rebased a branch before, however I still have mixed feelings about using git rebase (not entirely comfortable with using it again quite yet 😄). I'll just create a fresh branch for my next PR then.

@JacquesCarette, you should be good to delete branch Issue#2156 now, I will just create a new branch for my next PR.