3 ms·

If you're getting a lot of conflicts then you have folks working on the same code and diverging it significantly. I honestly don't think that's a problem toolin

by kodah 5y ago

If you're getting a lot of conflicts then you have folks working on the same code and diverging it significantly. I honestly don't think that's a problem tooling will improve because it's really an organizational/communication problem. Engineers have to know when to rebase (or merge in changes from the target) if they're working on code with other engineers. If you merge in/rebase sooner, then things tend to be painless. If it's been weeks or months then let the Circus O' Pain begin. This should be fairly easy to recognize in stand up, eg: "Oh, you're working on that module? I need to track your changes, so am I."

_0w8t 5y ago
Frequent and complex merges are inevitable if one maintains a few patches to an actively developed upstream and the upstream either does not want them or the patches are too specific to the product to be a part of the upstream.
skierguy 5y ago
It's much more complicated at scale. Many conflicts can come from things like backporting or working on a feature in a codebase that deals with a lot of churn (like some drivers or the Linux kernel). Some open source projects have internal versions of the code within the company that eventually gets upstreamed after internal validation takes place, but that version of the code may not rebase for a while for some very good reasons (unresolved instability on the main branch, for instance). In that case, the code base is now both significantly ahead (with internal changes) and significantly behind (due to the other changes that have come from other massive organizations working on the same project). I have published on the topic of merge conflicts a couple times, and even I didn't understand how inevitable massive merge conflicts can be until I joined a kernel integration team at a large company. Open source is a helluva drug :)
jrockway 5y ago
Yeah. Something that I've told myself never to do but have continued to do for the last decade is to take some code that's in review ('cause reviewers be slow) and then branch off of it and write something else. There is always "one little thing" in the code that's out for review, and merging that into the future work that you branched off is always a colossal pain. Every time I do it I regret it. (Is it just me, or is it not a social norm to treat code reviews like interrupts? I do that; I have Github connected to Slack and treat "I need my code reviewed" at the same level of priority as something like a production outage. It takes 5 minutes and unblocks an entire developer. But that favor seems rarely returned to me. I can usually get a fast review if I whine and nag, but it should just be automatic. And this isn't an artifact of any particular job, it's been like that at every job. I guess we could just stop doing code reviews, but they are pretty valuable for fixing dumb mistakes and sharing knowledge. But I digress...)
- reshlo 5y ago
  Needing a piece of code reviewed should almost never block a developer. They should have several other tasks they can do in the meantime. The review may take 5 minutes, but it could cost you 30 minutes of context switching if you’re in the middle of something complicated.

by kodah 5y ago

_0w8t 5y ago

Frequent and complex merges are inevitable if one maintains a few patches to an actively developed upstream and the upstream either does not want them or the patches are too specific to the product to be a part of the upstream.

skierguy 5y ago

It's much more complicated at scale. Many conflicts can come from things like backporting or working on a feature in a codebase that deals with a lot of churn (like some drivers or the Linux kernel). Some open source projects have internal versions of the code within the company that eventually gets upstreamed after internal validation takes place, but that version of the code may not rebase for a while for some very good reasons (unresolved instability on the main branch, for instance). In that case, the code base is now both significantly ahead (with internal changes) and significantly behind (due to the other changes that have come from other massive organizations working on the same project). I have published on the topic of merge conflicts a couple times, and even I didn't understand how inevitable massive merge conflicts can be until I joined a kernel integration team at a large company. Open source is a helluva drug :)

jrockway 5y ago

Yeah. Something that I've told myself never to do but have continued to do for the last decade is to take some code that's in review ('cause reviewers be slow) and then branch off of it and write something else. There is always "one little thing" in the code that's out for review, and merging that into the future work that you branched off is always a colossal pain. Every time I do it I regret it. (Is it just me, or is it not a social norm to treat code reviews like interrupts? I do that; I have Github connected to Slack and treat "I need my code reviewed" at the same level of priority as something like a production outage. It takes 5 minutes and unblocks an entire developer. But that favor seems rarely returned to me. I can usually get a fast review if I whine and nag, but it should just be automatic. And this isn't an artifact of any particular job, it's been like that at every job. I guess we could just stop doing code reviews, but they are pretty valuable for fixing dumb mistakes and sharing knowledge. But I digress...)

reshlo 5y ago
Needing a piece of code reviewed should almost never block a developer. They should have several other tasks they can do in the meantime. The review may take 5 minutes, but it could cost you 30 minutes of context switching if you’re in the middle of something complicated.