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, 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 ;-) > > 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 ? > 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? WHat do you suggest specifically to improve commiting on both master and to-be-released branches? Olaf
signature.asc
Description: Message signed with OpenPGP using GPGMail
