Fixes for issues 526, 572, 594. New git repository.
Fomka
fixes for issues 526, 572, 594 were commited to "master" and
"interface-fixes" branches of "Fomka/ufo2000" github repository.
Repository link: http://github.com/Fomka/ufo2000
Links to issues: http://ufo2000.net/mantisbt/view.php?id=526,
http://ufo2000.net/mantisbt/view.php?id=572, http://ufo2000.net/mantisbt/view.php?id=594.
Links to fixes are below.
526: http://github.com/Fomka/ufo2000/commit/e9bcc0609584631e99d12997658326483ef70ba1
572, part 1/2: http://github.com/Fomka/ufo2000/commit/ee3024601ea88620350d1b389cf1253e1bb7a12e
572, part 2/2: http://github.com/Fomka/ufo2000/commit/60e10af2e43520aabca3c02d1c6ea0aacaf47ec7
594, part 1/2: http://github.com/Fomka/ufo2000/commit/613feb711c51503b8506ec7604cf6f0160f85ecf
594, part 2/2: http://github.com/Fomka/ufo2000/commit/29638d4448a00f0ab339884f9644b5920153fb07
I hope that this fixes will be included into next release and will do
any corrections to achieve it.
The fixes are in my git repository which was forked from Serge's. I
want to have 2 branches at this time: interface-fixes and code-cleanup-
and-comments. The first is for small fixes of user interface that will
improve the way player interacts with the game. The second is for
introducing/updating comments inside the code that may appear during
work on other branches in untouched pieces of code.
Since I'm beginner to git my repository may contain errors, tell me
about them.
--
Best regards,
Fomka
Siarhei Siamashka
Thanks for working on these fixes and improvements.
As you admitted yourself, your git repository is a bit messy. One simple
criteria is to check whether you or somebody else can successfully apply
your patches to the current ufo2000 code in repository (either git or svn)
without conflicts.
To ensure this, you should not merge code in your own branches, but instead
rebase them on top of the main ufo2000 git repository 'master' branch. It is
described in "Creating the perfect patch series" part of git manual (and the
other recommendations from this section also apply):
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#patch-series
--
Best regards,
Siarhei Siamashka
Siarhei Siamashka
> On Saturday 14 August 2010 10:17:26 Fomka wrote:
> > I hope that this fixes will be included into next release and will do
> > any corrections to achieve it.
[...]
> As you admitted yourself, your git repository is a bit messy. One simple
> criteria is to check whether you or somebody else can successfully apply
> your patches to the current ufo2000 code in repository (either git or svn)
> without conflicts.
>
> To ensure this, you should not merge code in your own branches, but instead
> rebase them on top of the main ufo2000 git repository 'master' branch. It
> is described in "Creating the perfect patch series" part of git manual
> (and the other recommendations from this section also apply):
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#patch-series
To be more specific and give an example. Rebasing can be done like this:
1. Clone your repository
$ git clone <your_git_repository>
$ cd ufo2000
2. Tell git about the main ufo2000 repository (let's call it 'upstream')
$ git remote add upstream git://github.com/ssvb/ufo2000.git
3. Switch to the branch which has some of your patches
$ git checkout interface-fixes
4. Next let's make a copy of this branch (this is not strictly necessary, but
may be safer to experiment with). And then switch to it.
$ git branch interface-fixes-to-be-rebased
$ git checkout interface-fixes-to-be-rebased
5. Now do the rebase itself (on top of the upstream master branch)
$ git pull --rebase upstream master
6. If you are lucky and your branch did not diverge much, everything is
done. But sometimes conflicts have to be resolved. For example, we get
the following error message at this point:
First, rewinding head to replay your work on top of it...
Applying: Fix for issue 572, without path colouring.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging src/soldier.cpp
CONFLICT (content): Merge conflict in src/soldier.cpp
Failed to merge in the changes.
Patch failed at 0001 Fix for issue 572, without path colouring.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
As it says, there is a conflict in 'src/soldier.cpp' file. Just open it for
editing and find:
<<<<<<< HEAD
if(error != "")
g_console->printf(COLOR_SYS_INFO1, "%s", error.c_str());
=======
//Not enough TUs for required action plus reserved time AND enough for
reserved action
if(reserved_time_message != "") //print message about reserved TUs
//TODO Must use report_game_error()
g_console->printf(COLOR_SYS_INFO1, "%s",
reserved_time_message.c_str());
>>>>>>> Fix for issue 572, without path colouring.
This block contains the part of code which was changed both in your branch and
in upstream (divided by <<<<<<<, =======, >>>>>>>), so git can't decide which
one of them to take. You need to edit this part of code and keep the lines
which you think are correct here.
After the editing is finished, you need to tell git that the conflict is
now resolved. This is done by:
$ git add src/soldier.cpp
And then continue rebase, just like git suggested above.
$ git rebase --continue
7. The next problem that we encounter is:
Applying: Fix for issue 572, without path colouring.
Applying: Staying in touch with ufo2000
Using index info to reconstruct a base tree...
<stdin>:1442: trailing whitespace.
<stdin>:1447: trailing whitespace.
<stdin>:1452: trailing whitespace.
<stdin>:1457: trailing whitespace.
if (x == 1 and y == 1) then
<stdin>:1477: trailing whitespace.
end
warning: squelched 140 whitespace errors
warning: 145 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging readme_pt.txt
CONFLICT (content): Merge conflict in readme_pt.txt
Auto-merging ufo2000.rc
CONFLICT (content): Merge conflict in ufo2000.rc
Failed to merge in the changes.
Patch failed at 0002 Staying in touch with ufo2000
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Now it did not like 'Staying in touch with ufo2000' patch. As I can understand,
this is a mostly useless commit with whitespace and end of line changes in text
files. If we don't really want this patch, we can skip it:
$ git rebase --skip
Eventually the rebase process will be finished. At this point you have a set of
your patches applied on top of the most recent ufo2000 code in git. And you can
now push this rebased branch ('interface-fixes-to-be-rebased') to your
repository:
$ git push origin interface-fixes-to-be-rebased
That's basically all. I have pushed 'rebased-patches-from-fomka' to my github
repository as an example here:
https://github.com/ssvb/ufo2000/commits/rebased-patches-from-fomka
You can check how all these branches look on the network graph here:
https://github.com/ssvb/ufo2000/network
One last thing. This set of patches can now be easily applied to ufo2000
repository without conflicts (we have resolved them already). But honestly,
there is little interest in commits like "Removed comment //curr which was
submitted in previous commit". If you made a mistake in one commit, and
corrected it in another one, then it just makes a lot of sense to combine
these commits in a single one, making a "perfect patch series".
When the "perfect patch series" is ready and the patches are good enough for
inclusion, I can push them to the main ufo2000 repository. It may happen that
I will only push some selected set of patches to the repository, leaving out
the rest. In this case, your branch will need to be rebased again, so that the
remaining stuff can be cleanly applied to the upstream master branch too.
One more hint. If you want to delete some of the already unneeded branches in
your github repository, you can run something like this:
$ git push origin :no-hawknl
This command will remove 'no-hawknl' branch (that's my old branch, which has
been applied to ufo2000 main repository long ago, but you still have a copy
of it). It's easy to create and delete various experimental branches with git.
Good luck. And feel free to ask more questions if you get stuck.
Fomka
I've completed all steps you described, and have branch
'interface-fixes-to-be-rebased' in my local repository. The branch
content is the same as yours 'rebased-patches-from-fomka'.
Have read about perfect patches series. Followed the example in
section 'Rewriting a single commit' trying to delete that '//curr'
commit. However, the commit remains in commit log. Does it mean that
it is not deleted?
I've deleted some branches from my github.com repository.
Then I failed in pushing local branch changed to my remote repository.
First of all, I tried to mess with yours remote repository and got
plenty of 'authentication failed' messages. After I specified proper
address that points to my remote I got another error
git.exe push "fomka" interface-fixes-to-be-rebased:master
To g...@github.com:Fomka/ufo2000.git
! [rejected] interface-fixes-to-be-rebased -> master (non-fast-
forward)
error: failed to push some refs to 'g...@github.com:Fomka/ufo2000.git'
To prevent you from losing history, non-fast-forward updates were
rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
I'm stucked on that error and even want to recreate my repository,
based on latest changes in yours. Is that recreation possible on free
github plan? If yes, how to do that?
--
Best regards,
Fomka
Siarhei Siamashka
> I've completed all steps you described, and have branch
> 'interface-fixes-to-be-rebased' in my local repository. The branch
> content is the same as yours 'rebased-patches-from-fomka'.
>
> Have read about perfect patches series. Followed the example in
> section 'Rewriting a single commit' trying to delete that '//curr'
> commit. However, the commit remains in commit log. Does it mean that
> it is not deleted?
>
> I've deleted some branches from my github.com repository.
OK
> Then I failed in pushing local branch changed to my remote repository.
> First of all, I tried to mess with yours remote repository and got
> plenty of 'authentication failed' messages. After I specified proper
> address that points to my remote I got another error
>
>
> git.exe push "fomka" interface-fixes-to-be-rebased:master
>
> To g...@github.com:Fomka/ufo2000.git
> ! [rejected] interface-fixes-to-be-rebased -> master (non-fast-
> forward)
> error: failed to push some refs to 'g...@github.com:Fomka/ufo2000.git'
> To prevent you from losing history, non-fast-forward updates were
> rejected
> Merge the remote changes before pushing again. See the 'Note about
> fast-forwards' section of 'git push --help' for details.
Here git rejects your push just because you are not adding some new commits on
top of the existing, but replacing some of the older commits with updated
variants (so the operation is 'destructive' and needs special confirmation).
I you really want to overwrite your master branch with these changes, you also
need to add '-f' option when using 'git push':
-f, --force
Usually, the command refuses to update a remote ref that is not an
ancestor of the local ref used to overwrite it. This flag disables the check.
This can cause the remote repository to lose commits; use it with care.
> I'm stucked on that error and even want to recreate my repository,
> based on latest changes in yours. Is that recreation possible on free
> github plan? If yes, how to do that?
It should be possible, but I think you don't really need it yet.
Siarhei Siamashka
> section 'Rewriting a single commit' trying to delete that '//curr'
> commit. However, the commit remains in commit log. Does it mean that
> it is not deleted?
About this part. One of the ways of rearranging patches is to do something
like this. Let's suppose that we have 4 commits in the repository:
A, B, C, fix-for-B
We want to combine 'B' and 'fix-for-B' into a single commit.
It is possible to do the following:
$ git format-patch HEAD^^
This will produce *.patch files in the current directory for the last 2
commits ('C' and 'fix-for-B'). The more '^' characters you add in the end,
the more patch files you get.
Then you can run:
$ git reset --hard HEAD^^
This will remove the last two commits from the current branch (be careful
when using it!). And basically you will have only patches A and B applied,
which can be seen by 'git log'.
The next step is to correct wrong B commit. First you can just apply the
patch 'fix-for-B' to the sources:
$ patch -p1 < fix-for-B.patch
Then you need to commit these changes so that they are combined with the last
commit:
$ git commit -a --amend
After this step you will have the last commit having the changes from both 'B'
and 'fix-for-B' combined. The final part is to apply the remaining patch C
using 'git am' command:
$ git am C.patch
That's all. Using something like this and variations of these commands, you can
join, split or modify commits until you like the result. The final result is a
clean patch series which you can share with the others. Either by sending the
patch files generated by 'git format-patch' command. Or just by pointing
someone to the branch with these changes in your repository.
As mentioned in many git guides and tutorials, such rewriting of the commit
history is done only in the private work-in-progress branches. Once this stuff
is committed to the main repository (and especially if some version of the game
is released with it), fixing any bugs naturally requires separate commits and
messing with the previous commits history is not allowed.