6 ms·

I like to be able to (temporarily) revert an entire feature branch, which merge commits help with. Is there a way to easily do this without them?

Mithaldu 11y ago
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?
jerf 11y ago
It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be. I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing. I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones. That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.

Mithaldu 11y ago

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?

jerf 11y ago

It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be. I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing. I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones. That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.