Build Master: Progress toward 2.065

[Dicebot]

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.