On Tuesday, 10 December 2013 at 13:37:11 UTC, David Nadlinger wrote:
On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
Can't agree. Release _tags_ are public. Release branches exist primarily to organize development.


I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch?

Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option.

David

It is not a problem to reset local branches on rare occasions like this one, whatever developer count is. Reason why rebasing of public branches is discouraged is not some abstract inconvenience of collaboration - it is the fact that commit hashes change in history and anything that has been pointing to part of history that got rewritten will be broken (especially important if, for example, commit hashes are embedded into deployed builds).

This is not the case here. There has not been a single tag on this branch and not a single packaged binary built from it. Just is just a development snapshot, rebasing it is no different than creating a new one. As it won't happen under normal conditions anyway, I fail to see the issue.

Reply via email to