Topic Yet another Git rant
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to PeterW
Given that Mercurial provides even less help with history modification than Git - I highly doubt it. As I said, Git and Mercurial are both equally bad as far as I'm concerned.
Basically, neither of them really address the issue of patch dependencies. Instead they reason about revision dependencies, which is pretty restrictive. And when people want to break out of that (as they always will want to do within about the first five minutes) they fall back to "rebase" mechanics which just dumps a whole lot of patches on you so you can construct another completely pointless revision history out of it.
The way I have come to look at it is that I am building a "story" - not of something that actually happened, but of something that could have happened in an ideal world. A world where I never had to go back on a change, or never had to completely rewrite a feature because the code it was based on was changed in parallel. That's unqestionably a good idea, as it documents your changes better than a jumbled mess of back-and forth. Yet all this should have references to where development actually came from, in case a bug needs to be traced along that path (which is why I don't want to do a mega-rebase, as the people on Stack Overflow suggest).
So if that's what Git workflow demands, I try to construct it. Staged merges sort-of manage to get me there, but now the restrictions on squashing are really derailing my efforts...
(Addendum: Just to clarify, I am talking about work here, specifically merging this and this, which means getting through about 150k LOC in changes with conflicts all over the place. All this is way too subtle for a project the size of OpenClonk, as we don't even have that much code or activity in the first place.)
Basically, neither of them really address the issue of patch dependencies. Instead they reason about revision dependencies, which is pretty restrictive. And when people want to break out of that (as they always will want to do within about the first five minutes) they fall back to "rebase" mechanics which just dumps a whole lot of patches on you so you can construct another completely pointless revision history out of it.
The way I have come to look at it is that I am building a "story" - not of something that actually happened, but of something that could have happened in an ideal world. A world where I never had to go back on a change, or never had to completely rewrite a feature because the code it was based on was changed in parallel. That's unqestionably a good idea, as it documents your changes better than a jumbled mess of back-and forth. Yet all this should have references to where development actually came from, in case a bug needs to be traced along that path (which is why I don't want to do a mega-rebase, as the people on Stack Overflow suggest).
So if that's what Git workflow demands, I try to construct it. Staged merges sort-of manage to get me there, but now the restrictions on squashing are really derailing my efforts...
(Addendum: Just to clarify, I am talking about work here, specifically merging this and this, which means getting through about 150k LOC in changes with conflicts all over the place. All this is way too subtle for a project the size of OpenClonk, as we don't even have that much code or activity in the first place.)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill