search

FlorianASchroeder / TDVP

Tree-Tensor-Network State for Bosons
4 stars 0 forks source link

formatplot function missing #1

Closed jfeist closed 8 years ago

jfeist commented 8 years ago

many of the plotting commands in scratchpad use a function formatPlot, but it is missing from the repository.

FlorianASchroeder commented 8 years ago

Yes I'll include the function in the next commit.

FlorianASchroeder commented 8 years ago

I don't really understand the pull requests yet, and how to commit to which branch so that you can easily get the commit needing to check all the other changes I made. I've committed 'formatPlot' to my experimental branch. How to proceed now? What would have been the best way?

jfeist commented 8 years ago

Pull requests are (requested) merges between branches on different repositories, for example if I have made a change that I think is useful for you as well. If I open a pull request with these changes, you have a chance to inspect them, and also to comment on them and discuss possible changes, and merge it once you're satisfied. But there is no requirement that all changes are made through pull requests, and especially your own development can proceed however you want to. (Maybe I should also mention that pull requests are a feature of github, not of git itself)

I guess we should decide on some "development model". That's really your decision, but my proposal would be to keep it as simple as possible: you keep committing "normally" to your local repository (mostly in the experimental branch, I guess), and push these changes to github. I will keep my development (what little there will be of it, anyway) in a separate branch (jf), that I will probably rebase periodically onto "your" experimental branch to get the latest changes. This would meant that I don't treat jf as a "public" branch that is meant to be used by others, since rebasing rewrites history. Consequently, you probably want to delete the jf branch from your github repository. If I do anything that might be useful to you as well, I will make a separate pull request to your repository with just those changes. This way, I think you can proceed developing freely, and don't have to worry about what I do. I can then worry about integrating your changes as well, if necessary. If I need help, I'll ask, of course :smile:

BTW, if you have made some changes yourself after a pull request has been opened, there are two options to keep the history "clean": First push all your changes from the local repository to github, and then do the merge. Then you have two "parallel" branches that got merged. Or, alternatively, first merge the pull request, and then rebase your (new) local commits onto the updated branch from the github repository (most easily by doing "git pull --rebase" to pull the changes to your local repository, instead of just "git pull"). The difference between merging and rebasing is nicely explained, e.g., here: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

I saw that you have a commit "Merge remote-tracking branch 'origin/experimental' into experimental" - I guess you did git merge origin/experimental in your local repository? If you just did "git pull", it should not have created an "unnecessary" merge.

I'm sorry that I don't know mercurial, so I have no idea what the equivalent for all of these things is in mercurial, or which concepts are the same and which are very different. I know git takes a while to get used to.

jfeist commented 8 years ago

And I just realized I forgot to answer your actual question: I think how you proceeded with formatPlot is exactly the best way, apart possibly from the unnecessary merge commit. I can now just rebase my branch on top of experimental again, and get these changes.

FlorianASchroeder commented 8 years ago

Ah ok. I guess I still need a bit of practise. I was also not that experienced in mercurial. So I basically need to learn everything.