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.
