Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski:
On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote:
Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski:
On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
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).
How so exactly? So, it is not OK to have a developer spend a few
minutes integrating upstream changes into the local branch but it
is OK
to have the release manager waste time wading through hundreds of
unnecessary commits when preparing a release or chasing a
regression?
It is absolutely not OK for you as RM spending valuable time fixing
an
ugly log. Every committer is obliged to leave a clean log. If a dev
does
not stick to these rules he should be taken away his commit right.
If you want to clean up because committers are too stupid to do so,
we
should take the command-and-leutnant approach.
I have _no_ intention of policing other committers. It is emotionally
cheaper for me to take time to clean things up and than to hold all
those conversations about policies.
But why do you want to do the extra work to clean up somebody's else
mess? A project team needs to agree on some standards and rules making
life easier for everyone -- the project members as well as our clients
reading the log and using the software.
A project won't run w/o rules. It is pretty discouring for every a lot
of devs if someone else does not stick to the rules and produces garbage
commits.
Committers never push
directly to a live release branch, but request a PR for it. You as
the
RM will merge it. It will give you all the freedom you need. So
5.0/master and 4.4/master should be protected branches writable by
you
only. I am fine with that.
Michael
If folks can live with the restriction of release branches being
writable to PMs only, I am fine with that but I think it is just a
matter of time this rule gets broken. It is just cannot be enforced
properly without git commit hooks.
This dev commit branch should not be rewritten of course. But will you
really go through all commits, cherry pick and squash. This is just
daunting.
If people cannot bring up the disciple, they should reconsider their work.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
