> On Jan 29, 2015, at 10:28 PM, Mark Struberg <strub...@yahoo.de> wrote: > > 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.
Well, I do agree that’s cumbersome and error prone but I thought that the master was *merged* from a release branch. >> 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). Thanks for providing detail. I agree that if a feature branch is worked on by more than one person it probably shouldn’t be deleted; I think it’s more likely s/shouldn’t/must not/. But that’s a problem w/ git. It’s too bad that there can’t be two repos per project, one is for feature development and the other is for official releases. I don’t see the requirement to squash commits in GitFlow. Thanks for taking the time to bring me up to speed. Frankly, I didn’t have the bandwidth to keep up w/ the initial git discussions. Is there an ASF position document on git usage? With that said, I haven’t been doing a lot of development here lately and so I’ve been reticent on the issue with the exception being where there are gaps in my understanding of things. But, I do want to make one very important observation. The "Apache Way” is not a set of rules. The Apache Way is community over code. That’s it. Nothing else. The biggest aspect of that is treating your colleagues on this project with respect and not trying to bully others to get your way. Take a personal pause on this thread and redouble your efforts to attain your goal while realizing that since this is not a technical issue you will need to garner the consensus of your colleagues. Using expletives and couching accusations of development immaturity will only cause others to “circle the wagons”, making for yet another interminable thread that I have to slog through. We have probably one of the best developer groups on this project in the planet here. They are smart, articulate, and will listen to calm, respectful, reasoning. Regards, Alan
