7 ms·

If i understand you right, you want to do this: - Checkout master. - Start an interactive rebase of master onto the last commit before the series

If i understand you right, you want to do this: - Checkout master. - Start an interactive rebase of master onto the last commit before the series of commits you wish to remove. - Mark all the commits you don't care about as "skip". - Let the rebase run and resolve conflicts on the way, the same as you'd do with your current work flow.

purephase 11y ago
Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags. While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway). [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
tokenizerrr 11y ago
This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete I revert the revert I just made and merge the feature branch again.
- Mithaldu 11y ago
  You introduce explicit revert commits?
  - tokenizerrr 11y ago
    Yes, this is a feature of git: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert I don't think rewriting the history of public branches is a good idea.
    - Mithaldu 11y ago
      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.
      - tokenizerrr 11y ago
        Wow, way to be literally the opposite of constructive. Grow up.
        Mithaldu 11y ago
        We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.
        Profan 11y ago
        The constructive thing in this case would be to introduce your own solution to the problem and argument for it, not bring the level down to day-care level and go all "wow, i'm just gonna avoid you now.".
        Mithaldu 11y ago
        I already introduced my own solution in: https://news.ycombinator.com/item?id=9744402 https://news.ycombinator.com/item?id=9744402 To which his only complaint was "this rewrites history", followed by "i'll rather fuck over future developers by throwing in a revert blob followed by a revert-revert blob followed by ANOTHER merge only this time slightly different". There is no point in arguing with someone who thinks that is in any way reasonable. Additionally there is nothing day-care level about this. I've had clients like that, big companies too. Arguing for all sort of development horrors. I've fired those clients. I'd rather spend my time on companies that value the sanity of their people. So, really, i don't give a fuck. And unless he comes back with something along the lines of "i've realized that what i've been doing is sheer insanity and torture of myself and fellow developers", i don't care to hear what he has to say, the same as i am sure he doesn't care what i have to say. And really, i don't care whether you think what i am saying is constructive either. This factitious politeness that you and people like you insist upon is a blight on this industry. Please give me all the downvotes you can muster. It pleases me if i manage to upset people by being earnest, honest and direct, since it tells me more about their character than they're ever likely to realize themselves; and maybe, just maybe, they might end up wondering "Why is that guy so mean to me and doesn't even feel bad about it? What have i done wrong?" And if you actually care to find out something, if a constructive dialogue is your goal, then don't start it out with statements borne of inexperience and lack of knowledge. Start it out with the only question that matters: Why?

purephase 11y ago

Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags. While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway). [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html

tokenizerrr 11y ago

This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete I revert the revert I just made and merge the feature branch again.

Mithaldu 11y ago
You introduce explicit revert commits?
- tokenizerrr 11y ago
  Yes, this is a feature of git: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert I don't think rewriting the history of public branches is a good idea.
  - Mithaldu 11y ago
    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.
    - tokenizerrr 11y ago
      Wow, way to be literally the opposite of constructive. Grow up.
      - Mithaldu 11y ago
        We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.
        Profan 11y ago
        The constructive thing in this case would be to introduce your own solution to the problem and argument for it, not bring the level down to day-care level and go all "wow, i'm just gonna avoid you now.".
        Mithaldu 11y ago
        I already introduced my own solution in: https://news.ycombinator.com/item?id=9744402 https://news.ycombinator.com/item?id=9744402 To which his only complaint was "this rewrites history", followed by "i'll rather fuck over future developers by throwing in a revert blob followed by a revert-revert blob followed by ANOTHER merge only this time slightly different". There is no point in arguing with someone who thinks that is in any way reasonable. Additionally there is nothing day-care level about this. I've had clients like that, big companies too. Arguing for all sort of development horrors. I've fired those clients. I'd rather spend my time on companies that value the sanity of their people. So, really, i don't give a fuck. And unless he comes back with something along the lines of "i've realized that what i've been doing is sheer insanity and torture of myself and fellow developers", i don't care to hear what he has to say, the same as i am sure he doesn't care what i have to say. And really, i don't care whether you think what i am saying is constructive either. This factitious politeness that you and people like you insist upon is a blight on this industry. Please give me all the downvotes you can muster. It pleases me if i manage to upset people by being earnest, honest and direct, since it tells me more about their character than they're ever likely to realize themselves; and maybe, just maybe, they might end up wondering "Why is that guy so mean to me and doesn't even feel bad about it? What have i done wrong?" And if you actually care to find out something, if a constructive dialogue is your goal, then don't start it out with statements borne of inexperience and lack of knowledge. Start it out with the only question that matters: Why?