Mid-week update of Week 2 as an intern at Enthought, India
I've been formally assigned to work on the new Data Import Tool add-on to Canopy. I used to think that it is similar to the data-toolbox in Matlab or R but having tried out the Canopy add-on, I can say that it is very different. Well, I don't know if I can get into the details as to how it's different from the others so I'll postpone that for another time. Otherwise, it's been a steep learning curve and it's a bit hard to climb at times. I guess i'll just have to keep climbing up even if i roll back down a bit.
Enough meta stuff. Let me now tell you about two interesting things I learnt about git.
I wish someone had told me about "$ git stash". Say I have a working code. Say I am making corrections/improvements to the working code. Now say that my prof calls me up and asks me to run some data through the working code, without the changes. Now, because I don't want to throw away the changes I'm making, I can *stash* them away using git. Git will create save all the changes in a *location* and remove them from your working directory. Eventually, when youre done working and want to apply the changes back to the directory, all you need to do is "$ git stash apply". That link explains it better than I do, I'm sure, but I had to try.
I also learnt how to branch repositories and how to submit pull requests having made changes/additions/corrections. So, there are two ways. Note that my workflow is based around code hosted on GitHub. The first would be fork the repository into your account, work on it, update it and then submit a pull request having made the changes. Note that the changed code is residing in a clone of the original repository on your account. The second would be to create a branch of the repository, work on the branch, push to the branch and then submit a pull request. In this case, the code resides in a branch of the original repository. The first half of this article explains branching that I was talking about. Don't use merge if you want people to review your pull request/the changes you've made to the code.
I think I'll stop here for now. There are a bunch of other things that I learnt but am not able to put together into something concrete. I'll leave that for the next time. Until then ...
Enough meta stuff. Let me now tell you about two interesting things I learnt about git.
I wish someone had told me about "$ git stash". Say I have a working code. Say I am making corrections/improvements to the working code. Now say that my prof calls me up and asks me to run some data through the working code, without the changes. Now, because I don't want to throw away the changes I'm making, I can *stash* them away using git. Git will create save all the changes in a *location* and remove them from your working directory. Eventually, when youre done working and want to apply the changes back to the directory, all you need to do is "$ git stash apply". That link explains it better than I do, I'm sure, but I had to try.
I also learnt how to branch repositories and how to submit pull requests having made changes/additions/corrections. So, there are two ways. Note that my workflow is based around code hosted on GitHub. The first would be fork the repository into your account, work on it, update it and then submit a pull request having made the changes. Note that the changed code is residing in a clone of the original repository on your account. The second would be to create a branch of the repository, work on the branch, push to the branch and then submit a pull request. In this case, the code resides in a branch of the original repository. The first half of this article explains branching that I was talking about. Don't use merge if you want people to review your pull request/the changes you've made to the code.
I think I'll stop here for now. There are a bunch of other things that I learnt but am not able to put together into something concrete. I'll leave that for the next time. Until then ...