> 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.
Just to remind you of what the context of this discussion is:
You commented on an article that says, paraphrased: "Stop merging criss and cross y'all, it's dumb and counterproductive; rebase everything instead, it'll help you in the long run."
In that context, you asked "well merge commits are easily to revert, if i can't merge, how to i revert a feature branch?"
I answered to that, in the context given by the article on which you were commenting. That context is: "Rebasing all your things is mandatory."
As i said in my previous post, if you're not willing to even mentally adopt that context, then nothing i can say would be helpful.
Are you interested in doing that?
--
> we're not obsessive over having a "clean history", and are instead more than happy with a realistic one.
I deeply resent the implication. This kind of stance is what led me to my initial post you took offense to. What you perceive as obsession is experience and knowledge by people who have experienced both sides of the coin, along with their benefits and pains, and made a rational decision on which is more favourable in the long term.
You won't find me accusing you of obsession with fixed history just because you haven't had the (mis)fortune to make the full range of experiences on this.
> Instead of the commits simply disappearing for a time.
Nothing disappears, that is specifically why i mentioned tags. If one abandons a branch and the history is valuable to keep around, you stick a tag on the end of that branch, give it a description pointing at the ticket, then put a similar tag on the end of the remade branch, and off you go.
> not to get in the way.
How is git getting in the way of teamwork in your opinion?
> It's not a fuck-up.
Bugs are fuck-ups. There are no two ways around that. Especially when they're bad enough that a feature branch would be removed wholesale, and not simply disabled with a flag.
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.