4 ms·

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, b

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
  Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on. > My view on rewriting history is that it should not happen on shared branches Depends on how shared they are and how big the fuck-up is. Everything is relative. > as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly There should not be any merge involved there. See first paragraph. > or works directly on master. That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work. > I'm not sure how the tags with descriptions would help with easily rolling back They don't. They help with marking places where old broken branches were abandoned and marking places where their new counterparts were reinstated. Lastly: > it is not up to me If it's not up to you, and they'd not be willing to listen then the conversation is moot and your org is broken. You can't wedge one small part of a rebase-based workflow into a larger workflow that pretends git is just SVN with a different syntax. I can tell you how to do everything correctly and how it will actually make things nice and smooth, but if everything is not an option, then a little can't be applied to your situation.
  - tokenizerrr 11y ago
    > Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". I'm not even sure what you're trying to say here. In general we don't rewrite history of shared branches thus rebasing is certainly not a requirement. > It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on. They're not my developers. I'm one of the developers. I'm trying to educate my coworkers more in the ways of the git, but it's slow progress. There has been no cleanup work so far, mostly because we're not obsessive over having a "clean history", and are instead more than happy with a realistic one. > Depends on how shared they are and how big the fuck-up is. Everything is relative. It's not a fuck-up. Bugs happen, noticing and fixing them is progress. The revert commit references the issue tracker, and this itself is valuable history. Instead of the commits simply disappearing for a time. > That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work. Git is there to faciliate teamwork, not to get in the way.

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
Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on. > My view on rewriting history is that it should not happen on shared branches Depends on how shared they are and how big the fuck-up is. Everything is relative. > as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly There should not be any merge involved there. See first paragraph. > or works directly on master. That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work. > I'm not sure how the tags with descriptions would help with easily rolling back They don't. They help with marking places where old broken branches were abandoned and marking places where their new counterparts were reinstated. Lastly: > it is not up to me If it's not up to you, and they'd not be willing to listen then the conversation is moot and your org is broken. You can't wedge one small part of a rebase-based workflow into a larger workflow that pretends git is just SVN with a different syntax. I can tell you how to do everything correctly and how it will actually make things nice and smooth, but if everything is not an option, then a little can't be applied to your situation.
- tokenizerrr 11y ago
  > Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". I'm not even sure what you're trying to say here. In general we don't rewrite history of shared branches thus rebasing is certainly not a requirement. > It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on. They're not my developers. I'm one of the developers. I'm trying to educate my coworkers more in the ways of the git, but it's slow progress. There has been no cleanup work so far, mostly because we're not obsessive over having a "clean history", and are instead more than happy with a realistic one. > Depends on how shared they are and how big the fuck-up is. Everything is relative. It's not a fuck-up. Bugs happen, noticing and fixing them is progress. The revert commit references the issue tracker, and this itself is valuable history. Instead of the commits simply disappearing for a time. > That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work. Git is there to faciliate teamwork, not to get in the way.