You made a local branch (refs/heads/remotes/origin/devel), which has almost the same name as a remote branch (refs/remotes/origin/devel) - mind the heads/, which makes the former a local branch. This triggers a warning, because if you use remotes/origin/devel git can either complete it to a name of a local branch (prefixing refs/heads/) or a general ref (prefixing refs/). You should rename the local branch to e.g. just devel: git branch -m remotes/origin/devel devel
You removed Simutrans-Experimental.sdf, but what about the other files? You added some patterns to .gitignore, but this has no effect, because the files, which are matched by these patterns, are tracked, so git will not ignore them (except for ipch, which is not tracked). I think the *.old files should not exist at all, the others should be no longer tracked and ignored. I attached a bundle (I had to suffix it with .dat because of the questionable forum rules), which performs this on 8.x and you can pull from (The bundle cannot express untracking a file while keeping it locally, so you have to restore your user files for MSVC manually).
-devel will indeed pick up the correction from 8.x - why does that seem wrong? What would a better workflow be?
The problem was introduced in devel (when merging master into devel) and later merged into 8.x, so I'd expect that the correction flows in the same direction.
Quote
As to the recipe - forgive me for being unfamiliar with the Git command line (I use GIT GUI in Windows). What do the following two lines do:
git am 0001-Correct-mismerge-of-freight_list_sorter_t-compare_wa.patch
"am" stands for "apply mail", which turns patches from mails into commits (it can directly operate on a mailbox, but mail formatted patch files, which git format-patch generates, work, too). So this command is like if you edit the files in the patch with all the changes and commit them with message given in the patch file. It also preserves the author and timestamp, so my name would appear in the log instead of yours (you are recorded as committer, of course).
? In particular, what effect would reverting the change have if there are other patches applied since the change that still need to be applied in order to fix other bugs?
git revert basically applies the changes in the given commit in reverse. E.g. if in the commit a line was added, revert removes it again. I wonder, how did you revert the sort commit in the first place?
Quote
And thank you for the clarification in relation to the various *.vcproj.* files - in fact, I get an error message when I try to remove those. Thank you for all your help - much appreciated :-)
Which error message did you get? The files could not be deleted? This would happen, if MSVC is running and has them opened (The Windows API does not allow removing opened files). You could use git rm --cached, as yobbobandana suggested earlier, which tells git not to track the files any longer, but leaves them in the working copy. I do not know, whether git GUI has a way to do this, too.
the branch structure is thus organised: -master is the branch that contains the code for release versions only. Linux binaries are automatically built every night from the -master branch if it has changed.
-devel is the branch for making significant changes. New features should start life on the -devel branch.
-8.x is the branch for making preparatory pre-releases of release builds in the 8.x series. It is a new addition: previously, there was just -devel (for all development) and -master (for all releases). The idea is that I can make major changes on -devel, but still fix minor bugs on -8.x and release versions with those minor bug fixes whilst the major changes are still in development and unsuitable for release.
In this case, the changes will have been merged in from Standard into the -devel branch. The -devel branch will then have been merged into -8.x, and -8.x will have been merged into -master. Because I am currently working on bug fixes, I have been working on the -8.x branch, so -devel has not been updated since the release of 8.0. -8.x contains a number of different bug fixes, including the reversion of the use of std::sort, so any de-reversion would need to be patched against the -8.x branch rather than against -master.
devel should then pick up the correction from 8.x? This smells wrong to me. The mismerge happened on devel, not 8.x. If you really want to that, then on 8.x revert 6c65f58bc06cec99dc0546fa7af1cf2cde3de9be and am the patch.
Quote
Tron - perhaps it would be easier if you created a Github repository and pushed the fix to that?
I wrote down the recipe above.
Quote
As to the incorrectly staged files: I should leave .vcproj and .vcprojx, as people who develop in Windows might well find those files useful. I shall, however, remove the .sdf file.
Please re-read my post carefully. I did not say to remove *.vcproj and *.vcxproj. The patterns I gave are *.vcproj.* and *.vcxproj.*, which in particular do not include Simutrans-Experimental.vcproj and Simutrans-Experimental.vcxproj.
I'd have to revert the revert manually - isn't creating a .diff with my 8.x branch automatic? I asked because I thought that it'd be quicker for you to produce the .diff than for me to de-revert the changes manually; do correct me if I'm wrong, though :-)
I do not know what you mean by "automatically creating a diff with 8.x". I did a commit ontop of master. I can't make heads or tails of the branch structure. E.g. according to the log the mismerge happened when master got merged into devel, but now devel is an ancestor of master. But I'll try: The correction probably should go into devel and The revert should be reverted on 8.x. Then devel (with the correction) should be merged into 8.x:
You probably have to resolve a conflict about *.sdf (or all removed files, see below) again in the last step.
If devel is a dead end, then do this directly on 8.x, i.e. start with revert, then do am afterwards. Or what is master for? It seems to be halfway lost between devel and 8.x. Maybe the correction should be done on master (if devel is dead) and merged to 8.x, but I do not know what your development strategy is.
Quote
(And the .sdf file probably shouldn't be in the repository - it's a file generated by MSVC++.)
You should remove it then instead of cluttering the repo with it in every other commit. *.old, *.vcxproj.* and *.vcproj.* probably should go away, too:
I don't see the problem. Just revert the revert (which is trivial, except for this .sdf file - What is this? Should this even be in the repo?) and apply the patch.
The crashes are caused by the mismerge 36165d2034040c9d7c0e8bb66e6cdd9663c38b70, not by the change of using std::sort(). This patch, which corrects the mismerge, applies to the master branch of Simutrans experimental. 36165d2034040c9d7c0e8bb66e6cdd9663c38b70 is contained in master, devel and 8.x. But on 8.x the use of std::sort() was reverted.
The conflict resolution for freight_list_sorter_t::compare_ware in 36165d2034040c9d7c0e8bb66e6cdd9663c38b70 looks wrong. I suspect this causes the problem.
-return ((uint16)data[0]) | ( ((uint16)data[1]) << 8 ); + /* according to C standard uint8 will be anyway extended to unsigned */ + return (uint16)(data[0] | ( data[1] << 8 ));
uint8 (typedef for unsigned char) gets promoted to int (see ISO/IEC 14882:1998(E) §4.5:1).
I think such an ignore list is not needed, since one should never do a svn add * anyway.
The ignore list is specifically for files, which are not added to the repo, so they do not show up in svn status. On the contrary, svn:ignore (and .gitignore) has absolutely no effect on files, which are added to the repo. It is only to hide files, which are not tracked. In the ideal case the output of svn status is empty (if you did not modify any tracked files, of course). Having a bunch of files always showing up with "?" just hides files, which you accidentally forgot to add.
Config.default needs to be changed to be able to built it. Everybody has a different config.default on different platforms.
This is the reason, why it is ignored: It is not part of the repo and never should be. It also should not show up on svn status. svn status should only show files with the state "?", which you forgot to svn add. Accordingly, MSVC's user specifc files should be ignored, too, so they do not clutter up the view, when inspecting the status of the working copy.
Quote
This is not true for the SVN and VCPROJ files, which contain only the user independent settings. The dependent ones are in Simutrans.vcproj.JAPAN2.prissi.user (depending on computer and username of course)
As I have written above, if somebody shows me the output of svn status, then I can compile a ignore list, which handles MSVC's user specific files, too.
Aha, so that's what you were thinking. That sounds vaguely reasonable. However, global-ignores is of course a per-client configuration option, and you can't rely on all clients to set global-ignores the same way,...
I buy this argument.
Quote
Oh, of course, that makes sense. ....uh, and that means that patterns for the various .vcproj, .sln, and other related files should be put into the ignore lists. The ones which have been committed already will not be ignored.....
I do not know what exactly should be ignored, because I do not use MSVC. According to prissi something like *.vcproj.* should be included on the list, too. Would somebody show the output of svn status (or git status) when using MSVC?
Do not change svn:ignore to this value. The current setting is perfectly fine: 1. *.o files are ignored by SVN by default, so there is no point in ignoring them explicitly. From the SVN book http://svnbook.red-bean.com/en/1.5/svn.advanced.confarea.html:
Quote
global-ignores [...] The default value is *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store.
2. config.* is ignored on purpose, so other config.foo files, if you use any, are ignored, too, not just config.default. config.template is not ignored by SVN, of course, because by adding the file to the repo SVN was explicitly told to track the file, so it does not ignore it (git handles this similarly). From the SVN book http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.ignore.html:
Quote
Once an object is under Subversion's control, the ignore pattern mechanisms no longer apply to it. In other words, don't expect Subversion to avoid committing changes you've made to a versioned file simply because that file's name matches an ignore pattern—Subversion always notices all of its versioned objects.
