fix for issue #755

[Mo-Gul]

(For whatever reason there seem to some commits as well that were already merged, but I don't know why. Either I did something wrong or could the reason be the rebase which was done? Do you have an idea? If not, do you have an advice how to "fix" my fork without deleting and reforking it?)

[ilayn]

You might want to work with branches instead of master branch to avoid such issues. If origin is your fork and upstream is the official repo what happens when you do

git fetch upstream
git rebase upstream/master
git push origin -f

[Mo-Gul]

@ilayn, thank you for your suggestion. I'll be happy to test it after one more question: I just did a commit when I saw your message. Is that a problem when executing these commands?

[ilayn]

When you have your changes and also you pick upstream changes thry stack on top of each other in a scrambling fashion confusing git. If you keep your master branch pristine and only use it tobstay up to date also work on features on your local branches theybstay mutually exclusive

[Mo-Gul]

@ilayn, ok, let's see if I have understood you right.

• Never tough the master branch also in my fork besides "syncing" it with the upstream/master.
• Work on branches in the fork instead.

Right?

I am still not sure if I should run your suggested commands though ...

[muzimuzhi]

@Mo-Gul
You can first run git checkout -b backup, this creates a new branch backup that points to HEAD. Then you can safely modify the master branch, without the risk of losing current modification. (Actually, even if you lost some commits in git log, you can still find them in git reflog before git gc.)

[ilayn]

Also the changes seem to be rather trivial so in any case can be redone without too much effort.

[hmenke]

I've rebased it for you. In the future could you please also format your commit messages like

short summary

optional long summary with more details
that might span multiple lines

where short summary should be less than 50 characters. Take as an example my commit message on bd8c9c4 and refer to the documentation https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project

[Mo-Gul]

Thank you guys for your input. But I guess this is at my current git knowledge too high for me.

@hmenke, I'll do my best. Besides that this pull request is finished from my side. The above mentioned commit relates to the codeexamples and not to the issue handled here.

[ilayn]

It's not you, it's Git. Unfortunately, just like its creator, it commits cardinal sins in usability design. One of the most annoying one is that the function changes its meaning depending on its arguments (matlab anyone?). So here is a simple workflow; if you stay in it, it's all going to be fine.

Anytime you want to do something, sync your fork to the official one(I mentioned it above but here again)

git fetch upstream
git rebase upstream/master
git push origin -f

This keeps your fork up-to-date such that when you open a PR you don't get annoying merge conflicts because something else got in between.

Then anytime you want to do something new, create a branch

git checkout -b <insert-branch-name>

How you read this ? Switch to my insert-branch-name and if it doesn't exist create that branch. Then do you magic on that branch and when you are ready commit all your changes. Now you want to push it to your fork. So what you write is

git push

It works without arguments because the default is origin. It will complain (only the first time) that you don't have this branch on remote. But fortunately it will tell you what to do on the screen. Thanks git

git push --set-upstream origin insert-branch-name

Then you can come to github and open a pull request by pushing buttons. If you stick to this machinery 90% of your problems would go away. For the remaining 10% ask before you do it.

[Mo-Gul]

@ilayn, aah, ok. Currently my workflow to keep in sync with the main repository was something like

git fetch upstream
git checkout master
git merge upstream/master

and it very often worked fine... I don't know the exact syntax because I am using the TortoiseGit GUI. (And was there a push missing which I might have done? (Can't remember exactly.))

I just invited Henri and you so you have write access to my repository too. So you maybe can fix stuff for me for the remaining 10%. Here the question is, how do I know/recognize that problems will appear upfront?

Maybe it's because I did "something" to my repository before Henri rebased it, it seems something is wrong with my newly created branch https://github.com/Mo-Gul/pgf/tree/PimpLuaExamples as well. (It seems so when I try to open a pull request from that branch.) Could you fix that as well (by rebasing or whatever) and state me what then I have to do on my machine as well so everything is fine (again)?

Many thanks in advance for your help!!

[ilayn]

I would suggest not to use any GUIs at least until you get some affinity to the whole thing. Or if you really must; use GitHub Desktop instead which is kinda nice.

You don't need to invite us because any maintainer can modify the pull-request branches. So that would be an overkill.

It's this line that causes a lot of trouble. So better avoid that one, and try to treat the upstream as the canonical source. You are also a maintainer so better not push or merge or anything else that might compromise the upstream/master. As long as you are on a branch on your fork, you can kill, crash and burn as you like.

git merge upstream/master

[Mo-Gul]

@ilayn, "getting some affinity" is the problem. I guess 90% or more the time I use/need Git is when doing stuff for TikZ. And that is only from time-to-time. So also getting used to the GUI isn't really an option at the moment. To remember the 3 stated lines above I have prominently written down on my desktop because usually I have forgotten them the next time I need them.

Of course that is not an excuse but an explanation why I sometimes mess up stuff in Git. But I hope that my contributions have a (much) higher value than what I mess up with Git and so it is still beneficial to clean up the mess I leave behind ;)

No, I will not push, merge or whatever on the this master. If I should do so, I'll do it by pushing buttons here on GitHub which hopefully will not produce a mess.

To see forward: I'll took a note of your suggestion which I'll follow the next time I work on something (so after PimpLuaExamples). Thank you again for that!

[ilayn]

Well as the saying goes, "when in Rome, do as the Romans do" 😃 Don't fear the learning curve, the key is executing commands slowly and reading every bit of warnings. You won't believe how many times I screwed up in public repos elsewhere. But unfortunately under this stupid user interface Git is fantastically powerful. So better put it in your arsenal.

I'll check the other issue soon.

[Mo-Gul]

What will work for the other PR will not here (in the same way) because the changes for this PR were done in master branch. So I don't know how to revert that ... But luckily (and thankfully) Henri already cleaned up my mess. So I think this here should be safe to merge. If not, please let me know what I need to do.

[hmenke]

Merged in 197450c

Please also have a look at the new commit message to get a feeling for what is sensible and what is not.