Am 2017-05-15 um 11:54 schrieb Julian Sedding:
Force pushing is considered a bad practice in Git for good reasons,
thus rewriting history of published branches is IMHO a no-go. It makes
everybody's life harder (and developers less experienced with Git may
not be able to integrate the rewritten history at all).
Don't get me wrong. I do a lot of rebasing locally because I
appreciate a commit history that tells a story (i.e. commits should be
intentional, logical units, not accidental bits of work).
Could we perhaps achieve a pretty history by enforcing a
review-then-commit workflow? That way we can have temporary feature
branches (which may be deleted or force pushed in my book), work out
the history and only merge to master (or the respective release
branch) when we're happy with the change and the history.
I made this propopal already several days ago. See thread "Git policies
and practices". I don't want either the master/release branch to be
rewritten.
On Thu, May 11, 2017 at 9:23 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
...
I am not sure I understand what you mean by git apply.
Can we go back to what appears to be the only sticking point here?
It seems pretty clear that major release branches do not need to be
in
different repos. Local clones per major release are perfectly
sufficient.
The question is whether or not people can live with HEADs of
release
branches being volatile for a short period of time (not more than a
few
days) until every active committer gets used to using dev branches
for
building change sets?
To be more precise: do you want to do this only once or before every
release?
I want to be able to do it on a case by case basis. Like the one we
just had.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
