3 ms·

> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this co

> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. If you're working in a large codebase and the function in question is part of your API, don't mutate it, add another function and deprecate the older function. In any case, either developer A or developer B has to pay the cost of mutating the function at some point.

cjfd 6y ago
The point is that the problem is the smallest if the times between the point where A and Bs changes get into the mainline is the smallest. If A adds his parameter on Monday and B adds that same day three new calls and on Tuesday both merge their changes three calls need to be adjusted. If they merge on Friday and B has added three more calls on every day before Friday they have to adjust 12 function calls. Also, when B does not agree that the addition of a parameter is a good idea they can discuss this on Tuesday but otherwise they may wait doing this until Friday. It is also good to get this discussion out of the way as soon as possible. What if they decide that indeed the parameter that B added was good as such but actually needs to be of a different type? In the meantime B also has perhaps also added 12 calls to the function. These 12 calls now also have to be adjusted alongside with the 12 calls in the code of A. The general idea is that one wants to diverge from mainline for the shortest amount of time possible. I think the optimal amount of time for diverging from the main line is one day. If it becomes shorter the problem becomes that one would also need code reviews more then once a day and that becomes a bit burdensome too but code review every day generally sounds like a good idea. Preferably one should also pick a fixed time of the day for the code review. At my previous job I would do this and produce perhaps 10 small commits a day that would all get into the main line the next morning. If everybody does that one minimizes the size of possible conflicts.

cjfd 6y ago

The point is that the problem is the smallest if the times between the point where A and Bs changes get into the mainline is the smallest. If A adds his parameter on Monday and B adds that same day three new calls and on Tuesday both merge their changes three calls need to be adjusted. If they merge on Friday and B has added three more calls on every day before Friday they have to adjust 12 function calls. Also, when B does not agree that the addition of a parameter is a good idea they can discuss this on Tuesday but otherwise they may wait doing this until Friday. It is also good to get this discussion out of the way as soon as possible. What if they decide that indeed the parameter that B added was good as such but actually needs to be of a different type? In the meantime B also has perhaps also added 12 calls to the function. These 12 calls now also have to be adjusted alongside with the 12 calls in the code of A. The general idea is that one wants to diverge from mainline for the shortest amount of time possible. I think the optimal amount of time for diverging from the main line is one day. If it becomes shorter the problem becomes that one would also need code reviews more then once a day and that becomes a bit burdensome too but code review every day generally sounds like a good idea. Preferably one should also pick a fixed time of the day for the code review. At my previous job I would do this and produce perhaps 10 small commits a day that would all get into the main line the next morning. If everybody does that one minimizes the size of possible conflicts.