4 ms·

The dichotomy isn't between merging upstream changes into your branch vs. rebasing your branch on top of them. It's between doing one of those things and doing

by juped 2y ago

The dichotomy isn't between merging upstream changes into your branch vs. rebasing your branch on top of them. It's between doing one of those things and doing nothing, and doing nothing is the better (and easier!) option here. (When I mention it above, it's for a case like "the branch is several months old, two versions have been released in that time, and I'm revisiting it to finish it up now", and in that case you just merge the latest version tag (tag, not branch) before continuing. It's a very specific thing.) The main reason I see in practice that people do something, rather than nothing, is because someone is insisting on clicking the button on Github's web interface to merge a topic, which insists the merge be trivial. Faced with this sort of (bad) maintainership, the topic author has to choose between rebasing the topic, losing some useful graph properties (independence of unrelated branches) in the process, or merging upstream just before upstream merges them, which is incredibly stupid-looking (and very annoying when reading history, nothing is in the place you look for it). Usually they choose the former, or have it chosen for them. And now the branch, topologically, includes a bunch of unrelated things, and if you have any sort of triaging integration, QA, maintenance versions, or just want to read the graph to see what topic depends on what other topic, this is broken on this no-longer-independent topic. (In very bad cases, you might need to acquire a lock on a human, precisely what the whole system is meant to avoid.) The best thing is just to do nothing. If you're using Git as originally intended, your branch became patches anyway, it doesn't have a history. (As the maintainer receiving them, you just apply the patches to the latest version tag, pretty much, unless it's in series with something else, or it's a bugfix (always apply a bugfix commit directly onto the commit that introduced the bug. it can then be merged into any maintenance branch or other branch containing the bug. the word "cherry-pick" need never cross your keyboard.)) But a bad webapp broke things for a lot of people, and it was worked around in various ways.

em-bee 2y ago
i don't understand why the difference between tag and branch matters? why should i merge a tag and not the branch head? as a maintainer, why should i have to make the effort of merging a contribution myself, instead of asking the contributor to make sure that their changes can be cleanly merged? i agree that merging upstream before they merge me seems odd, but that suggests that rebasing is the only way to go. or how else can i ensure that my code can be merged cleanly without creating extra work for the maintainer?
- juped 2y ago
  Integrating things is 100% of a maintainer's job. As someone who wrote one topic, you don't have any insight into the arbitrarily many other topics that coincidentally were written at a similar time to yours; as the maintainer who integrates all submitted topics, you have read and are familiar with all of them. As a topic author, you have no such responsibility to deal with arbitrary other topics you had nothing to do with; this holds in an opportunistic open source contribution, in a workplace, anywhere. There's someone who reads all the patches and has a working knowledge of them: the maintainer. And if they ask you to do their job for them (which you will likely do poorly, not being the maintainer), they are a _bad_ maintainer. (And if software encourages this it's bad software; I'm not attributing this to maintainer malice or something, most people are just taking their cues from common bad software like Github's website.) > why should i merge a tag and not the branch head? Because a branch head is an arbitrary collection of things and a version is a specific supported collection of things.
  - em-bee 2y ago
    i am going to have to disagree to an extent. while on the face of it this makes sense. realities are often different. as a FOSS contributor, making the work of a maintainer easier can mean the difference between my submission being accepted or rejected. if i want to push a change upstream it is therefore in my interest to not rely on the maintainer to do that work. especially not if that maintainer is a volunteer. not every contributor is going to do that, nor should every contributor do that. only those that have sufficient experience to work at the level of the maintainer, but simply are not the designated maintainer because it is not their project. the same holds true at work. i expect everyone in a team to be familiar with the whole project and be capable of doing the work of the maintainer, at least everyone at senior level. whether they end up doing it or not. having a single person be responsible for all merges is an idea that i do not agree with. among other reasons it causes the designated maintainer to become a gatekeeper preventing others from developing that skill and step up to do that kind of work. whether it is practical for the maintainer to do all the integration then is a matter of their workload. the suggestion that only the designated maintainer can do a good job at merging is even somewhat patronizing. on tag vs branch, this seems to me only makes sense if we are developing against a release branch. a development branch often does not have release tags. the "releases" in a development branch are the merges of new feature branches. if each feature is merged on completion then there should not be any work in progress commits anyways. even if rebasing is used, those commits will be pushed all at once, so HEAD is always at a completed feature. i think that these are simply different approaches to development, and it can't be said that one is better than the other. it comes down to preference. i favor an environment where everyone can step up to contribute to the extent of their experience and knowledge over an environment where my capacity is limited by my role. being told that i am not capable of doing something because it is not part of my role is not something i want to hear ever.

by juped 2y ago

em-bee 2y ago

i don't understand why the difference between tag and branch matters? why should i merge a tag and not the branch head? as a maintainer, why should i have to make the effort of merging a contribution myself, instead of asking the contributor to make sure that their changes can be cleanly merged? i agree that merging upstream before they merge me seems odd, but that suggests that rebasing is the only way to go. or how else can i ensure that my code can be merged cleanly without creating extra work for the maintainer?

juped 2y ago
Integrating things is 100% of a maintainer's job. As someone who wrote one topic, you don't have any insight into the arbitrarily many other topics that coincidentally were written at a similar time to yours; as the maintainer who integrates all submitted topics, you have read and are familiar with all of them. As a topic author, you have no such responsibility to deal with arbitrary other topics you had nothing to do with; this holds in an opportunistic open source contribution, in a workplace, anywhere. There's someone who reads all the patches and has a working knowledge of them: the maintainer. And if they ask you to do their job for them (which you will likely do poorly, not being the maintainer), they are a _bad_ maintainer. (And if software encourages this it's bad software; I'm not attributing this to maintainer malice or something, most people are just taking their cues from common bad software like Github's website.) > why should i merge a tag and not the branch head? Because a branch head is an arbitrary collection of things and a version is a specific supported collection of things.
- em-bee 2y ago
  i am going to have to disagree to an extent. while on the face of it this makes sense. realities are often different. as a FOSS contributor, making the work of a maintainer easier can mean the difference between my submission being accepted or rejected. if i want to push a change upstream it is therefore in my interest to not rely on the maintainer to do that work. especially not if that maintainer is a volunteer. not every contributor is going to do that, nor should every contributor do that. only those that have sufficient experience to work at the level of the maintainer, but simply are not the designated maintainer because it is not their project. the same holds true at work. i expect everyone in a team to be familiar with the whole project and be capable of doing the work of the maintainer, at least everyone at senior level. whether they end up doing it or not. having a single person be responsible for all merges is an idea that i do not agree with. among other reasons it causes the designated maintainer to become a gatekeeper preventing others from developing that skill and step up to do that kind of work. whether it is practical for the maintainer to do all the integration then is a matter of their workload. the suggestion that only the designated maintainer can do a good job at merging is even somewhat patronizing. on tag vs branch, this seems to me only makes sense if we are developing against a release branch. a development branch often does not have release tags. the "releases" in a development branch are the merges of new feature branches. if each feature is merged on completion then there should not be any work in progress commits anyways. even if rebasing is used, those commits will be pushed all at once, so HEAD is always at a completed feature. i think that these are simply different approaches to development, and it can't be said that one is better than the other. it comes down to preference. i favor an environment where everyone can step up to contribute to the extent of their experience and knowledge over an environment where my capacity is limited by my role. being told that i am not capable of doing something because it is not part of my role is not something i want to hear ever.