Hi Alan! > Where do you see that? I keep reading that Atlasssian document and I don’t > see > where it requires cherry picking each and every commit.
You have a master branch and a development branch. All work happens on the development branch but releases happen from master branch, right? So how do all the commits end up on the master branch? Someone has to pick the 'good' ones from the development branch over to the master branch. Especially when a release comes near. > Can you point me to the parts that justify your allegations? My 'musts' listed below are not from gitflow. Those are requirements we do have as ASF project. As an ASF project we are required to maintain a clean code provenance and a immutable project source history. This means we must not do any history rewrite of stuff which already hit the ASF repo (of course a local! rebase or your own work which you did not push to some ASF repo is perfectly fine). So we should really disable history rewrite on our cannonical ASF git repo. As to my argument about branch deletes. Gitflow requires that you create an own branch for every feature someone does. But that would have us end up with 400++ branches pretty soon. I guess you see that this is not really easy to maintain. Of course after a feature got merged in to some 'upstream' branch then we can delete this feature branch technically. But the problem is that it's really easy to trash a GIT repo with branch deletes. And there is no way back other than a full file restore from a backup. What people don't get most of the time: A delete of a branch in SVN is really just an additional commit which sets a 'deleted' flag. So you can always do an undelete in SVN. But that's not the way it works with GIT. If you delete a branch in GIT then it is gone. Especially if there was a git-prune or git-gc scheduled afterwards. So I'd rather forbid all history rewrite (including deletess) on our repos and do experimental stuff on a different repo (either an own sandbox repo at ASF or on github). LieGrue, strub > On Friday, 30 January 2015, 6:04, Alan D. Cabrera <l...@toolazydogs.com> > wrote: > > >> On Jan 28, 2015, at 11:48 PM, Mark Struberg <strub...@yahoo.de> > wrote: >> >> Alan, the gitflow way is basically review then commit. Because the > 'Release Manager' (of whom we lack...) needs to review and choose > (cherry-pick) EACH AND EVERY SINGLE COMMIT. > > Where do you see that? I keep reading that Atlasssian document and I don’t > see > where it requires cherry picking each and every commit. > >> And even worse - by deleting the 'temp' branch afterwards we also > loose all the other work later. >> >> And once again: >> >> We must not delete anything from our repos! >> >> We must not squash commits! >> >> We must not loose any history! >> We must guarantee a verifyable code provenance! >> >> Those are no 'should' those are MUST! > > You guys must be reading something different than I am or I am accidentally > skimming over some critical bit: > > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow> > > Can you point me to the parts that justify your allegations? > > > > Regards, > Alan >
