Update Webpack to use npm, timeline.
Closed this issue · 7 comments
Hi I'm just updating all of the labels of each step in the tutorial to have our new Webpack npm usage.
I'm currently up to step 5 so 5 more to go! As I've been going along I've also been adjusting the readme to amend any little typos 😄
If you could take all of these amended readme's and put them into complete-tutorial.org that would be great.
Hopefully we can merge the amends I've made without too many issues!!
Thanks Vince
Hey,
Thanks a lot for all your time and efforts.
I have merged all your pull requests manually (by fetching them to my machine and merging them with git). Git didn't identify 2 of them, so I closed them.
If you check the logs, I rebased your changes so that all the git tags would serve their purpose properly while keeping the history clean. But I got little stupid and pulled your changes after first rebase which caused little diversions in the history (still better than branches though). It's not harmful, but the history don't look that straight anymore.
The purpose of git tags is to serve as "Chapters", so a reader can checkout to the tag, and see the instructions and code upto that step only.
If you're going to make more changes, make sure you pull these changes and branch on the new git history.
Hi, yeah cool I was unable to make changes to the history for some reason!!!
I knew you wanted to keep the tags and I was trying to merge them into that but all it would allow me to do is create new branch!!! I'll try work out how to adjust at that specific tag and commit that instead!!
Sorry for the confusion, not played around with using fit in this way before.
I'll get the rest of the commits sorted today so like that you have a working history then I'll try to fix and create new typos hahaha!!
Don't worry about maintaining the history, it's simple but it can get confusing, and it'll probably make it very hard for me to review things (because it creates a whole new history from that point). Make all the changes you want to any step, and then create a pull request for each step (as you did earlier).
When I started this tutorial, using git tags seemed to be a perfect choice, but turns out it is not perfect by itself. It need some automation, or perhaps I should opt for a different strategy in future.
Rebasing is simpler, but if you do it and I want to make the changes in your changes before merging them, I'll have to go through the entire process again. So it's better if you simply create the pull requests for each step (like you did), and I do the merging and rebasing (like I did). Otherwise it'll just be double-work.
For reference, this is how you can change the past:
Say you want to change tag number 5, and then insert new commits in history
- You first create a separate branch based on tag 5, and make new changes on it and create new commit(s)
- Now to insert these commits in git history (before tag no. 6), you rebase the master branch on the branch you created:
git rebase your-new-branch master - This will most likely cause some conflicts which you resolve, then add the resolved file with
git add my-new-file, and dogit rebase --continue. What this is doing is that it is replaying the future commits on the new commits you wanna insert. This can cause conflicts sometimes, but fortunately git is very smart in doing this - At the end, although you achieve the goal of "insert commits in past", but you change the flow of time. The future is no longer same, all the commits after your new ones are actually new commits. This mean you need to delete old tags (all tags after tag no. 5) and re-assign them to new commits (this is the most annoying part)
It's pretty simple process, but can be little confusing. Plus as you can see it will create a whole new git history, so besides increasing the number of commits (we can get rid of old commits though), it'll make it harder for me to review, and I'll have to redo the whole process anyway if I want to change something in your changes.
So this is how you can rewrite your past, but don't do it.
haha ah cool yeah I imagined that the way I did it would be the easiest in terms of putting it into the master version! But thanks a lot for the instructions it's good to know how to do it properly. Git is really good and yet sometimes a little difficult!!
I was thinking that maybe if I get the time I would do a little screencast on this tutorial as it's a really nice tutorial and could give others a chance learn it from another format.Obviously that's if you don't mind.
I did talk on RxJS recently too youtube video but the sound wasn't the best at the beginning part and when it did improve you couldn't really hear people's questions haha
I would do a little screencast on this tutorial
Please go ahead, by all means. I thought of making screencast videos once, but sound of my voice was too awkward for me to actually do it. It's so damn weird to listen to my own voice.
I managed to get halfway in doing this then I went in the wrong direction so I plan on trying again some time soon!! we will have a screen cast tutorial!! as this is a great repo to get people inspired with RxJS
Looking forward for your screencast 😊