issue-#100 Controls documentation

[Ivan Denisov]

I just tried another commit and saw the []Message only box and this time checked it.
That did not help for the push which failed. Here is the message I got

That is because there is no --force option in your GUI for git.
I do not know the reason why Josef has different interface for the same application.
I am running git from the command line usually so I just can recommend you to use this set of commands.

Code: Select all

git checkout issue-#100
git push --force

[Ivan Denisov]

From my point of view we should avoid force pushes because each such action will confuse another users who already make clones.
Each force push is forcing me to delete synced branch or create new clone from github. That is not very nice.
When only Josef and I was working with the repository it was ok. However now Doug (and maybe Helmut) start to keep repository mirror on local machine (and that is grate).
I think, that some uncertainness in commit message or several small commits for the one issue are less problem than all this troubles with version conflicts.

[DGDanforth]

OK, I did a successful push. Here is what I needed to do.
(1) cut /Docu/Controls.odc from my issue-#100 directory (put it in temporary spot)
(2) PULL issue-#100 (success)
(3) commit issue-#100 with amended message
(4) mark [x] Message only.
(5) push (success)

So, Josef, does issue-#100. now satisfy your requirements?
I did not put the "add..." line into the message.

Here is the redmine difference (one has to be logged in to see it!)
http://redmine.blackboxframework.org/pr ... 456e/diff/

[Josef Templ]

Doug, you have a newer Tortoise Git version than mine.
You have two force options. It should be sufficient to check the first one (known changes).
If this does not work, you can also check the second one.
You can also press the 'Help' button and read the online docu.

- Josef

[Josef Templ]

OK, I did a successful push. Here is what I needed to do.
(1) cut /Docu/Controls.odc from my issue-#100 directory (put it in temporary spot)
(2) PULL issue-#100 (success)
(3) commit issue-#100 with amended message
(4) mark [x] Message only.
(5) push (success)

So, Josef, does issue-#100. now satisfy your requirements?
I did not put the "add..." line into the message.

Here is the redmine difference (one has to be logged in to see it!)
http://redmine.blackboxframework.org/pr ... 456e/diff/

And this was the wrong way.
I told you not to do anything else.
Now we have messed up tze topic branch with a commit that does not have
the proper format.

[DGDanforth]

And this was the wrong way.
I told you not to do anything else.
Now we have messed up tze topic branch with a commit that does not have
the proper format.

But Josef, that was the only way that I could get it to work.
What is "tze"?

You did not respond to my detailed postings of what I saw with a fix (correction) to them.
I did not see the options that you mentioned and showed you what I saw. Is there some
in compatibility with different versions of TortoiseGit?
Here is what I am using

TortoiseGit 1.8.16.0 (C:\TortoiseGit\bin)
git version 1.9.5.msysgit.0 (C:\Program Files\Git\bin; C:\Program Files\Git\; C:\Program Files\Git\etc\gitconfig)

[Josef Templ]

It should have been clear that the latest activities are for fixing the commit message.
A commit message is not fixed by adding new commits.
This is so far beyond my imagination ...

[DGDanforth]

Josef,
I suggest that I pull out of the Git/redmine usage and turn that task back to you and Ivan.
The process is much too detailed for a novice, such as myself, to handle.

I have never liked the idea of Git. It struck me, from the beginning, that BlackBox
should itself be its own maintainer. I started to write an alternative to Git. I call it Org (for organizer).
There are not that many concepts that need to be implemented.
One only needs a central server to hold the master with appropriate lock and release mechanisms.
I would replace redmine with Org. We have a diff mechanism (as you have shown) that can
be used, although not as pretty as redmine's. There would be no limit to the number of issues.
I don't see the need for a local commit. The push back to the server of a branch would have the server do
the checking for compatibility. The very act of pulling a branch would incorporate the issue number
so that the kludge of having a commit message would be eliminated. When one pushed the branch
back the issue information goes back along with it.
Just a comment.
-Doug

[DGDanforth]

It should have been clear that the latest activities are for fixing the commit message.
A commit message is not fixed by adding new commits.
This is so far beyond my imagination ...

Yes, of course that is what these activities have been about.
How do you fix a commit message without doing a commit?
If one does a second commit is that adding new commits?

There is the concept called "the background of obviousness". We seem not to share
that background for, much of what you are saying, I do not understand.

A new comer to a forest will wander, possibly for days, through the forest looking for
a way through, whereas the expert will follow the well worn path and pass through in
minutes. I am still wandering,

-Doug

[Ivan Denisov]

Doug, you got some negative emotions about git. That is not good.
I am suggest to start from the scratch later, because all this confusion appears because Josef forcing you to fix commit message just after you make your first commit.
Now we will fix this history and all Center members who keep repository mirror will make the new clone.
I will also clean this topic from Git tutorial.
Ok?