3 ms·

Are you serious? I was being polite and posted a question asking for some constructive feedback. I got some of this, then Mithaldu went off the deep-end and dec

Are you serious? I was being polite and posted a question asking for some constructive feedback. I got some of this, then Mithaldu went off the deep-end and decided to start ridiculing me and tell me how he'd avoid the company I work at because of the questions I'm asking. And now you're saying that I'm the one crossing a line here? Seriously? I just re-read the guidelines, which did I break? The only one I can imagine is not flagging the comment but that was because the software did not let me since it was a reply to one of my posts. I have been perfectly civil. Telling someone they are not being constructive and should grow up is not uncivil when it's in response to: > Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me. Be sure to read that again and let it sink in. This person wants to know what company I work at so he can avoid it because of a question I asked on the internet about git.

Mithaldu 11y ago
It wasn't your questions that bothered me, but your ideas expressed in these posts: https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744929 https://news.ycombinator.com/item?id=9744929 Your initial question was perfectly fine to me. Further, while i think HN is inconsistent at best in how it applies its rules², i realize that dang does have a point and i could've dug further with questions, to see if your mind could be changed. However, the same applies to you just as much. Instead of accusing me of being a child³, you could just as well have asked why i recoiled in horror and thus rerail the discussion in a constructive direction, like to3m did: https://news.ycombinator.com/item?id=9745547 https://news.ycombinator.com/item?id=9745547 -- ² The rules are hilariously strict, which can be a good thing, but applied to only a small percentage of rule-breaking posts. ³ Not that i particularly care.
- tokenizerrr 11y ago
  Sorry, but when you react like the way you did I simply lose any interest in discussing the matter with you any further. Frankly it also makes you lose credibility in my book; if you cannot manage to have a polite conversation where you disagree with someone then it paints a picture of someone who yells and walks away whenever someone disagrees with them. A person like that may believe they are right, but if they can't properly discuss things, how would they know? So why should I trust them? Not saying that this interpretation is accurate or anything, that's just how your posts came off and why I wasn't interested in further discussing the matter with you and reacted the way I did. But very well, as long as we can keep things polite: There exists a possibility you misinterpreted my intent. I am talking about the following scenario: * Feature branch is written by a developer, has been tested (not as much as they'd like, because deadlines) and it is merged into master * Master branch is made publicly available, CI builds from it, and builds wind up in production * Some time passes, eventually a critical bug is uncovered in the code from the feature branch. This is bad and should have been caught earlier, but it didn't, and shit happens. * Work starts on a fix as soon as the developer resources are available. In the meantime the code from that feature branch should be "disabled" so the product remains functional in the meantime. So what has worked well for us is reverting the merge commit(s) where the feature branch is merged into master. This commit is given a descriptive commit message and we actually appreciate there being a mark in the revision history about this. We have dozens of these projects for different customers, and less than a dozen developers. Rewriting the history of the master branch would result in chaos as every developer gets to merge their own feature branch into master. Are you still recoiling in horror? If so, feel free to elaborate as to why and how you would do this better.
  - Mithaldu 11y ago
    Cheers. I'm pleasantly surprised. Sadly i don't have mounds of time right now to write bigger answers, but i first need to figure out what your knowledge is, because we're not quite on the same page yet. > every developer gets to merge their own feature branch into master. Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Is there a reason that you're saying "every developer gets to"? Normally they'd only need to rebase when they wish to integrate it back into master anyhow, which is likely to be conflict-free if they didn't rely on the feature, and also likely to be conflict-free if they wait until you've re-added the feature in a fixed state. And if they decide to rebase before you re-add it, then they'd have to deal with those conflicts exactly the same as if they'd merge before your revert-revert. Do your developers do the SVN thing of continually merging master into their feature branch? Typically that is a bad habit which should be replaced with rebases of the feature branch. Why do you care if history gets rewritten? Because you fear it would create more work, or because you consider history inviolable. > we actually appreciate there being a mark in the revision history about this. I think tags with descriptions would serve the same purpose. Do you see issues with that?
    - tokenizerrr 11y ago
      > Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Yes. The way we currently do things is keeping things as simple as possible for everyone, even if this doesn't produce the prettiest history. A developer first creates their feature branch based off of master, commits several times to this feature branch, tests it and possibly asks for review from a coworker and then they merge this feature branch into master using --no-ff, always creating a merge commit. It's possible there have been commits to master since they based off of it. If so, they will resolve this in the merge. I do think it would be better if feature branches got rebased prior to merging onto master so they can be tested in this state as well but this is currently not how things are done (it is not up to me). Though that could create issues if there's multiple developers collaborating on a feature branch and they do not communicate properly. The reason I said "every developer gets to" is that in larger projects (which also usually use gerrit, which do not) I've seen that there are usually a select few people in charge of merging the feature branches into master, instead of everyone getting to merge as they see fit. My view on rewriting history is that it should not happen on shared branches as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly, or works directly on master. We also contract some work out to external agencies and their git usage is usually absymal, and I am not in the position to correct or influence any of that. > I think tags with descriptions would serve the same purpose. Do you see issues with that? I'm not sure how the tags with descriptions would help with easily rolling back all the changes introduced through a feature branch, but maybe I'm missing something.

Mithaldu 11y ago

It wasn't your questions that bothered me, but your ideas expressed in these posts: https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744929 https://news.ycombinator.com/item?id=9744929 Your initial question was perfectly fine to me. Further, while i think HN is inconsistent at best in how it applies its rules², i realize that dang does have a point and i could've dug further with questions, to see if your mind could be changed. However, the same applies to you just as much. Instead of accusing me of being a child³, you could just as well have asked why i recoiled in horror and thus rerail the discussion in a constructive direction, like to3m did: https://news.ycombinator.com/item?id=9745547 https://news.ycombinator.com/item?id=9745547 -- ² The rules are hilariously strict, which can be a good thing, but applied to only a small percentage of rule-breaking posts. ³ Not that i particularly care.

tokenizerrr 11y ago
Sorry, but when you react like the way you did I simply lose any interest in discussing the matter with you any further. Frankly it also makes you lose credibility in my book; if you cannot manage to have a polite conversation where you disagree with someone then it paints a picture of someone who yells and walks away whenever someone disagrees with them. A person like that may believe they are right, but if they can't properly discuss things, how would they know? So why should I trust them? Not saying that this interpretation is accurate or anything, that's just how your posts came off and why I wasn't interested in further discussing the matter with you and reacted the way I did. But very well, as long as we can keep things polite: There exists a possibility you misinterpreted my intent. I am talking about the following scenario: * Feature branch is written by a developer, has been tested (not as much as they'd like, because deadlines) and it is merged into master * Master branch is made publicly available, CI builds from it, and builds wind up in production * Some time passes, eventually a critical bug is uncovered in the code from the feature branch. This is bad and should have been caught earlier, but it didn't, and shit happens. * Work starts on a fix as soon as the developer resources are available. In the meantime the code from that feature branch should be "disabled" so the product remains functional in the meantime. So what has worked well for us is reverting the merge commit(s) where the feature branch is merged into master. This commit is given a descriptive commit message and we actually appreciate there being a mark in the revision history about this. We have dozens of these projects for different customers, and less than a dozen developers. Rewriting the history of the master branch would result in chaos as every developer gets to merge their own feature branch into master. Are you still recoiling in horror? If so, feel free to elaborate as to why and how you would do this better.
- Mithaldu 11y ago
  Cheers. I'm pleasantly surprised. Sadly i don't have mounds of time right now to write bigger answers, but i first need to figure out what your knowledge is, because we're not quite on the same page yet. > every developer gets to merge their own feature branch into master. Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Is there a reason that you're saying "every developer gets to"? Normally they'd only need to rebase when they wish to integrate it back into master anyhow, which is likely to be conflict-free if they didn't rely on the feature, and also likely to be conflict-free if they wait until you've re-added the feature in a fixed state. And if they decide to rebase before you re-add it, then they'd have to deal with those conflicts exactly the same as if they'd merge before your revert-revert. Do your developers do the SVN thing of continually merging master into their feature branch? Typically that is a bad habit which should be replaced with rebases of the feature branch. Why do you care if history gets rewritten? Because you fear it would create more work, or because you consider history inviolable. > we actually appreciate there being a mark in the revision history about this. I think tags with descriptions would serve the same purpose. Do you see issues with that?
  - tokenizerrr 11y ago
    > Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Yes. The way we currently do things is keeping things as simple as possible for everyone, even if this doesn't produce the prettiest history. A developer first creates their feature branch based off of master, commits several times to this feature branch, tests it and possibly asks for review from a coworker and then they merge this feature branch into master using --no-ff, always creating a merge commit. It's possible there have been commits to master since they based off of it. If so, they will resolve this in the merge. I do think it would be better if feature branches got rebased prior to merging onto master so they can be tested in this state as well but this is currently not how things are done (it is not up to me). Though that could create issues if there's multiple developers collaborating on a feature branch and they do not communicate properly. The reason I said "every developer gets to" is that in larger projects (which also usually use gerrit, which do not) I've seen that there are usually a select few people in charge of merging the feature branches into master, instead of everyone getting to merge as they see fit. My view on rewriting history is that it should not happen on shared branches as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly, or works directly on master. We also contract some work out to external agencies and their git usage is usually absymal, and I am not in the position to correct or influence any of that. > I think tags with descriptions would serve the same purpose. Do you see issues with that? I'm not sure how the tags with descriptions would help with easily rolling back all the changes introduced through a feature branch, but maybe I'm missing something.