documentation

[ghost]

So first time for me using github. I'm not sure if i did everything in the "normal" way :-D If there is anything i should change or do different for the next commit please let me now.

i just modified the README.rst.

I tried to update the documentation. I realized how complicated it can be two write a documentation for other people. Especially if i'm new to the framework. Nevertheless i tried to make clear that there are different ways to use pyjaco. And to include all aspects that confused me the first time I used pyjaco.

I'm also not sure about the "make" installation or if this is obsolete.

I currently work on some examples which demonstrate how one can use pyjaco and i can include in the doc next time.

[Neppord]

@silentrunner I see that in your first commit you do, you commit the ~ file. can you rebase to remove this file in the commits? Tell me if you need help.

You also changed the rights of files, was this intetional? If so, give them a singele commit (or one for each file), with a good name.

You reuse the name "Update README.rst" for alot of commits. give them new names, or squash them to a single commit, depending if they do the same thing or not.

@chrivers if this is how it actualy works nowdays and he fixes the errors then i 1+ this

[ghost]

So it took me sometime to understand the rebase method. I now did the rebase and squashed all commits to one. I hope i did it right.

Hope this also solved the ~ issue.

The right changes of these files happend somehow during installing pyjaco from the local repository. I'm not sure why. Pushing them was probably a beginners mistake :-D

It is necessary to redo that or can you simply ignore this when merging.

[Neppord]

@silentrunner heres how to remove the changes of the files

To reset the changes of files done in last commit, where files are:

• casetest
• debian/rules
• htmltest.py
• pyjs.py
• run_tests.py

First inspect that they have bean changed in the last commit.

$ git diff HEAD^ -- casetest debian/rules htmltest.py  pyjs.py run_tests.py
diff --git a/casetest b/casetest
old mode 100755
new mode 100644
diff --git a/debian/rules b/debian/rules
old mode 100755
new mode 100644
diff --git a/htmltest.py b/htmltest.py
old mode 100755
new mode 100644
diff --git a/pyjs.py b/pyjs.py
old mode 100755
new mode 100644
diff --git a/run_tests.py b/run_tests.py
old mode 100755
new mode 100644

Then fix so they don't.

$ git checkout HEAD^ -- casetest debian/rules htmltest.py  pyjs.py run_tests.py
$ git add casetest debian/rules htmltest.py  pyjs.py run_tests.py
$ git commit --amend
[master 0a7e7a9] Update README.rst
 Author: silentrunner <tobias.baum.eu@gmail.com>
 1 files changed, 113 insertions(+), 34 deletions(-)
$ git diff HEAD^ -- casetest debian/rules htmltest.py  pyjs.py run_tests.py

Note that its always good to make a new branch to save your old changes, or make the new ones in. This works like a backup. In this case you have your backup at githhub, and can always do a git checkout origin/master untill you have pushed that is.

[Neppord]

If you don't understand what the git commands do, just ask, I'll gladly help you out!

[Neppord]

@silentrunner about the "It is necessary to redo that or can you simply ignore this when merging."

It depends on if you actually want to be in the history or not. Usually (in GIT) you pick in commits as a whole, and very rarely does a patch checkout and only takes one part of a commit.

One of the benefits with GIT is that you can tell someone to make the changes before you pull it, yourself.

That said, I really like your work. 1+, as i said before.

[ghost]

@Neppord So, i did everything according to your instructions. Looks like it worked :-D If there is anything else please let me know.

But one question. I understand 'checkout' (checkout Checkout a branch or paths to the working tree) but why i have to use the 'add' in the next step? (add Add file contents to the index) isn't this the opposite of what i'am trying to achieve here? Or do I add the previously done changes?

Nevertheless, i will play around with GitHub in the next time so hopefully the next commit will be more painless :-D Thanks a lot for your patience and help.

[Neppord]

@chrivers if you give the thumbs up so that i can merge this, or just merg it yourself.

@silentrunner Thank you for your patience! And that you manage to use rebase, with no more help, is amazing!

About the GIT commands

The checkout does what you say but minus one thing you think it does. In difference to checking out a complete branch it does not move your HEAD there (HEAD is a pointer to the current commit).

So what we do is reintroduce the files as they where to the working tree (the directory) before HEADi.e. how they where in HEAD^. Then we tell the index that this is how the files should look like after the commit using the add command. Then committing with the --amend flag tells GIT to change the current commit with what we added, instead of adding a new one (you can think of it like adding a new and squash it). GIT is smart enough to se that between HEAD^ and HEAD there is no longer any changes for these files, and removes them from the commit completely.

If you did not understand what i just read, dont hesitate to ask more.

[Neppord]

@silentrunner

i reread your post again, good thing to do, should have done before pushing the Comment button. I am not sure, but you might have confused the index for the actual commit? In shorter explanation then above, and maybe clearer.

We add things to the index, so that GIT can use it to commit the difference. The difference here is between the commit that was on HEAD^ and the index, on the files that was added to the index. Why its HEAD^ and not HEAD is because we used the --amend flag.

I hope i explained it good, in at least one of my explanations.

If someone else have something to add, pleas do. Its good to discusse GIT.

One more note: play more with GIT then GitHub, you have more use for GIT.