On Tue, Jul 14, 2015 at 11:26PM, Olaf Flebbe wrote:
> Cos,
>
> > I didn't bring up the release or their tags anywhere in my email, so I am
> > not
> > sure what's your point here... Besides, with git we aren't relying on
> > release
> > tags as they are mutable; instead we are relying on commit SHA1.
>
> A git tag is not mutable and should not be moved, since it is an alias for a
> commit hash of a release. For instance github makes release based on tags
> only: For instance see: https://github.com/apache/bigtop/releases,
Evidently, "is not mutable" and "shouldn't be moved" are two very different
properties. What github does for their releases is of no relevance to us.
> I doubt you can move a tag once it is pushed to the apache repository (since
> a force push is not possible, too), but we may try ;-)
Tag is a pointer to a git object. The pointer could be deleted, recreated and
pushed again: no force-push is needed for that. Besides, force-push isn't
disabled on Apache repos (except for master branch).
> > Branches are cheap and easy to clean - once the merge is done the branch
> > will
> > need to be deleted. 2nd merge you're referring to is a non fast-forward
>
> Sure, branches are super-cheap to create. But are we really allowed to
> destroy them later with git push --prune on an ASF git repo ?
Yes, we can do whatever we want with the branches.
> > commit, which is annoying in a sense, but also helps to track the history of
> > the changes and where there are coming from. And yes - cherry-picking is
> > absolutely worst because it changes a commit's SHA1 and makes it impossible
> > for automatic tooling to trace the flow of the changes.
>
>
> I admit that is not easy to understand the flow of information of a
> cherry-pick, but it seems not impossible to trace it. At least git itself
> can do it correctly, since you can merge branches automatically later where
> you did single cherry-picks between them before. I would refrain from doing
> any non-automatic cherry-picks, that's true evil.
>
> What tool is potentially broken with respect to cherry-picks?
Actually any visualization tools like gitk. Or
% git cherry -v
would show contextually equivalent commits as different on different branches
because their SHAs would be different. And so on.
> WHat do you suggest specifically to improve commiting on both master and
> to-be-released branches?
I suggest, again, to follow the model from above URL and avoid cherry-picking
if possible. It's coming from a lot of pain I am enduring in every new company
when they start using git without understanding the mechanics behind it.
Cherry-picking is a broken practice unleashed on many ASF projects by Hadoop
folks misusing git faculties. Unfortunately, those practices proved to be
quite sticky like pretty much any other bad habit...
It is too late to safe branch-1.0, but perhaps we should try this in the
future release.
Cos
