restore history for Slider.js

[pixelzoom]

As part of #380, HSlider.js was renamed Slider.js, and a new HSlider.js was created. After committing and pushing, the history is with the new HSlider file, and Slider is being treated as a new file. Everything was done using WebStorm.

[pixelzoom]

@samreid said in #380 (comment):

Normally WebStorm can track history across file renames. However for HSlider.js => Slider.js, it is failing to follow the history:

This is confusing because git log --follow does seem to follow the history. Perhaps --follow works based on contents?

~/github/sun/js$ git log --follow Slider.js
commit fd6daf25e543b73f9a19dce2f53e3bf927b8b476 (HEAD -> master, origin/master, origin/HEAD)
Author: Chris Malley <cmalley@pixelzoom.com>
Date:   Fri Aug 31 15:37:08 2018 -0600

    Slider, HSlider, VSlider hierarchy, https://github.com/phetsims/sun/issues/380
    
    Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

commit e69d4bf1a8d8bcb822e9a47e6b5bbb1fd585d9a0
Author: samreid <reids@colorado.edu>
Date:   Fri Jun 8 12:51:42 2018 -0600

    Replaced '// phet-io modules' with '// iphetio', see https://github.com/phetsims/phet-io/issues/1331

commit 359470fff422ee7efecbefc6d8313150dae1a741
Author: denz1994 <denz1994@gmail.com>
Date:   Tue May 22 09:27:33 2018 -0400

    HSlider labels made so they aren't pickable. Found during https://github.com/phetsims/masses-and-springs/issues/274.

...

I typically find it most useful to be able to use the WebStorm history features when looking back in time, I'm not sure what is different in this case, but I thought I should point it out as soon as possible.

[pixelzoom]

@samreid said in #380 (comment):

In the GitHub diff page showing the diff, it is treating Slider.js as a new file (if I'm reading this correctly):

[pixelzoom]

I'm not sure what happened here. I used WebStorm to rename the file. And for any file that was renamed, I noted it's original name in the JSdoc at the top of the file. What do you suggest?

[pixelzoom]

@samreid said in #380 (comment):

It looks like something went wrong with the rename. Perhaps WebStorm had a git failure during that step. Can that step be re-done so we can easily access the history? Easy access to the history for this file seems particularly important because it crosses a11y and phet-io and is a widely used component.

[pixelzoom]

There was no git failure indicated by WebStorm. Perhaps it got confused because the file was renamed, and then a new file named HSlider was created. I have no idea how to this can be "re-done".

[pixelzoom]

@samreid said in #380 (comment):

Basically, you could try:

1. Revert head to the SHA before your changes
2. Commit the renaming of HSlider.js => Slider.js as one commit (don't push yet)
3. Commit your other changes
4. Push all commits

EDIT: changed would => could
EDIT: changed could => could try

[pixelzoom]

The steps in #389 (comment) do not work. I can't commit to a detached HEAD.

[pixelzoom]

I recall a previous developer meeting where we discussed a similar problem. We couldn't figure out how to move the history, so we instituted a policy of putting a note in the renamed files indicating what the old name was. I did that for all files that were renamed in this case.

@jonathanolson any ideas about how to move the history to Slider.js?

[samreid]

Something like https://stackoverflow.com/questions/4114095/how-to-revert-a-git-repository-to-a-previous-commit

History should only be a problem when moving repos, which we are not doing here.

[pixelzoom]

@samreid When I select Slider.js and press the "Show history" button in the WebStorm toolbar:

Slider.js appears twice in the History menu for the Version Control pane:

Choosing one of these entries shows me the equivalent of git log, the other shows me the equivalent of git log --follow (full history for a renamed file).

Various hits for Google searches "git preserve file history when renaming" (e.g. https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history) also indicate that things are behaving properly from the git command line. That is, you need to git log --follow if you want the full history for a file that has been renamed.

GitHub doesn't show history for renamed/moved files. It's a requested feature, see isaacs/github#900.

So I'm skeptical that "History should only be a problem when moving repos" is an accurate statement.

[pixelzoom]

Very odd... After restarting Webstorm, then selecting Slider.js, then "Show History", I see Slider.js only once in the History menu. And it shows the complete history of the file (git log --follow) since its creation on 9/15/13. So I suspect that Webstorm (and IDEA?) is probably buggy when it comes to history of renamed/moved files. E.g.
https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000133970-Following-GIT-moves-renames-via-version-control-log

[pixelzoom]

According to the documentation for git log, the --follow arg is required "to follow history beyond renames". I tried this for other files that I renamed (e.g. SliderIO.js, SliderThumb.js) and they behave the same as Slider.js. That is, git log shows only the history since rename, git log --follow shows the history beyond renames.

[pixelzoom]

More at https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history. A few statements from that topic:

To lookup the full history, use the following command: git log --follow ./path/to/file

It is possible to rename a file and keep the history intact, although it causes the file to be renamed throughout the entire history of the repository. This is probably only for the obsessive git-log-lovers, and has some serious implications, including these:

The short answer is NO, it is not possible to rename a file in Git and remember the history.

[samreid]

I'd like to get this sorted out sooner rather than later, since subsequent commits on sun (such as eb7cd2b ) could complicate things. However, if I follow the git revert strategy proposed in #389 (comment) and apply the changes in #389 (comment) myself, then it will change @pixelzoom's commits to incorrectly come from me. I could add a note in the commit message that the commits are really from @pixelzoom--I would rather have easy access to the full history with a few commits from the wrong person, than losing the history halfway through. Alternatively, @pixelzoom and I could sort this out by working together, or @pixelzoom could follow the proposed steps alone to get the commits to come from the right person. Maybe I'll check the proposed strategy on my working copy (without pushing anything) to make sure the instructions are right...

[samreid]

I followed these steps:

// Work in a branch, just in case (optional)
(1) git checkout -b slider-history

// // Revert the 3 commits on this repo related to the name change, newest first. Use the default commit message that git generates
(2) git revert 519b915eec459137d1d03b59487890550a4e5137
(3) git revert d3819e5309208f64a17e8a8de112e4b21a60d035
(4) git revert fd6daf25e543b73f9a19dce2f53e3bf927b8b476
(5) Use WebStorm to rename "HSlider.js" to "Slider.js" and commit

Note I haven't pushed anything yet--we can push after we decide how to proceed.

Observe that WebStorm can easily access the full history across the rename:

Step (6) will be to reapply the other changes that were made as part of those 3 commits.

@pixelzoom how would you like to proceed?

[pixelzoom]

Let's work on this together, because the above steps are not working for me. After the reverts, WebStorm tells me that I have nothing to commit. I'm also not seeing history across rename for SliderTrackIO (renamed from HSliderTrackIO). So I'd like to:

(1) Make sure we address all problem files at once.
(2) Identify why this happened, and how to rename in the future.

[pixelzoom]

Webstorm was not following history across rename for Slider.js and SliderTrackIO.js.

@samreid and I collaborated on restoring history over Zoom. We followed the steps in #389 (comment), including creation of a local branch. We renamed files as one commit, then applied all other changes as a second commit. After testing working copy, we then merged the local branch into master, then tested again.

For me, Webstorm is now consistently showing history across renames. And command line (git log and git log --follow) is behaving as expected (unchanged from before we did this).

I still don't understand what Webstorm "Show history" is showing, or why it was so flakey/inconsistent. And I don't understand why Webstorm correctly handled the rename for some files (e.g. SliderTrack.js) but not others (e.g. SliderTrackIO.js). I guess I'll do further renames as a separate commit.

@samreid Is going to spot check things before closing this issue.

[samreid]

WebStorm can now easily access the history of Slider.js, I did not see any other issues, closing.

[samreid]

I found these notes about what the JetBrains history shows:

https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000464604-What-Is-The-Git-History-Showing-

File history in IDEA shows commits for which file was changed from all of the commits parents. So:

1. Single-parent commits that changed the file are shown;
2. Merge-commits where file was changed from both parents are shown.

We also follow file renames.

This is different from the default mode of "git log" command that "Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content)". Also by default renames are not followed.

The closest git command that shows similar result would be git log --follow --full-history --simplify-merges (but this still would leave some of the "empty" merges). There are currently no settings to change that.