![[de]](/mwf/flags/de.png "Germany")
Half of it is merge commits, and some of those merge commits are bad merges. I have rebased the branch on top of the current default branch, and will push that later today for consideration as a replacement. A nice linear history is easier to follow.
I think PlrCtrl as it is can replace the current main branch. Mouse control is not implemented yet and you have to set the correct control set in your player settings. But it is playable; and as the interface changed, much scripting work done for the old control mode would have to be re-ported.
I am currently working on the branch and also took care of the errors of the bad merge... I hope if you push that later, it will not lead to me having to merge loads again. And please do not merge plrctrl into default just yet. I am not done with the new controls yet. Now it is hardly playable.
Please remember that while it's annoying to have current changes mess up the game, there's a lot of overhead involved in merging branches all the time (quite visible in the PlrCtrl branch). Besides, the main branch isn't much more playable anyway.
That's true. I am not against rebasing plrctrl into default, I am just skeptic about it. Nothing is more annoying for a content developer if the platform he is working on, does not work properly.
The right solution is to work on non-overlapping areas in different branches and only merge the branch once, at the end.
![[us]](/mwf/flags/us.png "United States")
And in the meanwhile I think it's OK to merge default into an experimental branch (because it sometimes happens that the latter needs a fix from default) as long as the default branch is required to always be in good shape (which it currently isn't, and maybe that's the source of the problem).
> it's OK to merge default into an experimental branch
What isn't really ok IMO is merging own unpublished changes onto a branch. This should be rebased instead, so we don't have branch-commit-merge situations all the time. This might even be useful if the changeset has already been published on an external repository to keep our development history clean.
> which it currently isn't, and maybe that's the source of the problem
We should really get default back to working order poste-haste.
I think the bad merges resulted from the confusion that was caused by this:Sven did some changes to the plrctrl branch and merged it with an older default tip, committed it. I merged the plrctrl branch with a new default, committed it and pushed it. Sven pushed his changes+merge only after that. I merged my plrctrl branch into his plrctrl branch, committed and pushed it.
In the (my) last merge, KDiff was confused because of that and solved a few deltas automatically which should have been conflicts (that have to be solved manually). So, for the future, we know: If you merge+commit, always push after that immediately.
Which leads us to your rebase. Perhaps it is wiser to either push it now rather than later or not at all (rebase from another rev later). IMO, as stated above, PlrCtrl is not working (enough) to be rebased to the default branch. The bugs by the even actually almost-finished proplists and other changes in default are already annoying enough.
Okay, a first version is now in my bitbucket repos: http://bitbucket.org/guenther/openclonk/I think I'll fix up the branch markers, and maybe the dates, add the latest commits from the openclonk.org plrctrl branch, test the result, and push it to the openclonk.org default branch.
Okay, what does this mean? I guess merges are a bad thing... Therefore:
* If some branch exists only on your computer, you must rebase it.
* If the branch is also in a remote repository, on the other hand, push the merge immediately, because rebasing a merge will not be possible (or at least very, very messy).
Or did I get that wrong?
* If some branch exists only on your computer, you must rebase it.
* If the branch is also in a remote repository, on the other hand, push the merge immediately, because rebasing a merge will not be possible (or at least very, very messy).
Or did I get that wrong?
> * If some branch exists only on your computer, you must rebase it.
You don't have to, but it makes for a cleaner history graph.
That's nice and all, but the complicated merges and conflicts that mess up the history are of course those that happen in the PlrCtrl-branch, which is edited by many people and frequently needs new features from the main branch (Proplists, etc.). Noone gets confused by one-developer-branches that move on commit by commit and get backmerges from the main branch now and then.
I consider a clean graph to be essential for effective developing. I don't think we have to argue about the fact that these plrctrl-spaghetti-branches are /really/ hard to read?
I mean, there doesn't even seem to be a per-branch history view? :/
I mean, there doesn't even seem to be a per-branch history view? :/
> I mean, there doesn't even seem to be a per-branch history view? :/
Click the "Filter" button in TortoiseHG's history viewer, then choose the branch you want to see.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
