On Mon, Mar 26, 2012 at 12:03 PM, Alexey Shein <con...@gmail.com> wrote:
> 26 марта 2012 г. 4:30 пользователь Stas Malyshev > <smalys...@sugarcrm.com> написал: > > Hi! > > > >> Main problem is that our current workflow doesn't allow branch-only > >> changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only > >> you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go > >> there. > > > > Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an > > example? > > I can see it if the code had substantial change there so bugfix no > > longer applies. In this case, I would try the merge, see it fail and > > resolve it as "all ours". It shouldn't take longer than 10 mins. Though > > it you have ideas how to improve that without disrupting the rest of the > > process and the common use case, you are welcome. > > For example this commit > > http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4 > by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will > describe better. It was then accidentally merged into PHP-5.4 by > Hannes (which broke something in PHP-5.4) when he was merging his own > changes which merge made a lot of confusion. > > We should really deal with this problem first before diving further, > since it will have great impact on the whole working process with git. > If we can live with simple git merge - it would be simply awesome. > > >> 1) use cherry-picking in one repo. This has big downside (as dsp > >> pointed) that we can't use git annotate, bisect and other commands > >> assuming that commit is introduced in repository only once. > > > > bisect is a bit weird now btw, since it seems to be a bit confused by > > 5.3-5.4 merge that happened not when it thinks it did - so if you try to > > bisect changes in 5.4 branch only, you will get some very old changes > > in. You can quickly go through that, marking them as good, but still not > > ideal situation. > > Yep, already tried bisect and it doesn't seem work good at least for > php-5.3 branch. > > >> Okay, since I'm not too familiar with release process, assume > >> following (please, correct me if I'm wrong): > >> * PHP 5.3 can't have features, only bugfixes > > > > True. > > > >> * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and > >> master) and bugfixes that should stay only in PHP-5.3 > > > > Not entirely true - 5.3 code can have bugfixes that aren't merged up, > > but that would not be the common case. Example - bugfix regarding magic > > quotes or safe mode, which are not in 5.4. > > So it's still possible to have not-merged up bugfixes. That means that > we should take that into account. > I'm just trying to figure out our needs to better understand what > needs to be done then. > > > > >> * PHP-5.4 and master can have bugfixes and features that are merged > >> upstream (master) and bugfixes/features that should stay only in > >> current branch > > > > 5.4-only fixes very unlikely, as master and 5.4 are very close today. If > > we ever do big changes in master this is a possibility, as described > > above, but still won't be a common case - unless we rewrite our engine > > completely, which doesn't seem to be likely. > > > >> * All branches are have regular releases > > > > True, except for master. > > > >> In gitflow you have 4 branches: > >> * master - contains only production ready releases, nobody commits here > directly > >> * develop - main development branch, all work usually is get merged here > >> * feature/<name> - feature/bugfix branches for separate bugfixes and > >> features. Merged into develop. > >> * hotfix/<name> - same that feature branches but is urgent and is > >> always merged into master *and* develop. For example, when security > >> release is issued, this fix should go into release and into main > >> development branch. > >> * release/<name> - pre-release stability branches, for bug-fixes only. > >> Merged into develop and master (making a new release). When you have a > >> release branch, you can't commit into develop (so hotfixes go here > >> too, if we have release branch). > > > > I don't like that "can't commit into" thing - the main advantage of git > > as I see it that you can manage release branch and dev/stable branches > > separately and not have the situation of asking people to sit on their > > code for 2 months while release is being stabilized. > > Sorry, I messed this up. You actually can commit into the develop, new > features go there, while bugfixes should go in release branch. If you > want you can merge release branch into develop anytime you want, it's > just should be done at least once when release branch is closed. > > >> Make a bugfix in 5.3 > >> $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based > on 5.3 > >> $ git flow feature finish -k bugfix 5.3-develop > >> Bugfix get merged into 5.3-develop - this should be implemented since > >> gitflow supports only 1 develop branch for now. -k says to keep branch > >> after finish, since we'll need it to merge upstream > > > > Why would we need bugfix branch in our repo here? I would say keep it in > > your own fork, test it, show it off, get it ready - then merge it into > > php repo. What is the reason for us to keep halfbaked fix branches in > > our repo? > > > >> Merge bugfix from 5.3 repo to 5.4 > >> First, rebase branch against 5.4 > >> $ git rebase --onto develop-5.4 bugfix~<num> bugfix > >> Where <num> is number of commits in your branch. I know it sucks, but > >> that's how it works :) > > > > I don't like it. Too fragile and too easy to mess up. > > > > In general, this scheme seems quite complex and I don't really see what > > the benefit of it would be. Could you explain why would we want to do > this? > > Canonical gitflow is very straightforward and clean. Here it seems > complex because I tried to apply it on the fly to PHP needs. PHP adds > complexity because we support several release branches at once, while > in gitflow there's only one release branch in the given moment of > time. That's why my first thought was to divide our release branches > in separate repos, this way we could start use gitflow in its current > state. > Advantages: > * clean separation of release branches, main development and hotfix > branches > * if you use git-flow tool you don't have to remember what branch > should you start your feature/bugfix, where to merge when it's ready, > it's all already thought through and automated, that's really cool > especially when you make a release > > I strongly recommend you to read original article > http://nvie.com/posts/a-successful-git-branching-model/ and spend half > an hour on this hands-on tutorial http://vimeo.com/16018419, so you > can really feel how it works. > > No doubt that we can't use gitflow as-is, i.e. we would need to modify > it to suit our needs, but it can realy simplify our life. > > Disadvantages: > * Cli oriented toolbox. As Matthew pointed out you can't use git-flow > with git GUI tools and support on Windows seems not so good > * Written in bash. There was attempt to rewrite it into python, but it > seems things stopped there about year ago: > https://github.com/nvie/gitflow/tree/feature/python-rewrite > * Some time (not much) is needed to understand the system > > -- > Regards, > Shein Alexey > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I've personally never used the Gitflow utility as I've found it largely unnecessary. The branching model is really quite simple once you get the hang of it. Of course, pure Gitflow wouldn't work because we have two main development branches instead of one and they frequently interact with one another. The problem is that merge conflicts could occur if merged changes affect code that is different between 5.3 and 5.4. And we do NOT want merge conflicts being resolved on the main develop branch! With this many people, that could get.... ugly. The Gitflow model uses a temporary "release" branch to merge develop into master. What if we took a similar approach with merging changes into both dev branches? Here's what I'm thinking: git checkout -b Feature-Name 5.4-develop (build your feature, commits, etc) (do a fresh pull on 5.3 and 5.4-- ALWAYS do a pull of any branch you're about to merge into!!!!) git checkout 5.4-develop git merge --no-ff Feature-Name git checkout Feature-Name git checkout -b Feature-Name-5.3 Feature-Name git rebase 5.3-develop (resolve merge conflicts, if any) git checkout 5.3-develop git merge --no-ff Feature-Name-5.3 git branch -d Feature-Name git branch -d Feature-Name-5.3 Basically, what the above does is creates a temporary "duplicate" branch for the feature and then rebases that duplicate off of the other version to be merged into (rebase tends to minimize merge conflicts and make them easier to deal with than merge IMHO). This way, we're not polluting the main develop branches in the event of a merge conflict. This also preserves the original feature branch for the duration of the merge process in case we need it as a reference point. So what this means is that we'd be using a "parallel" Gitflow model in which there are 2 master branches and 2 develop branches (one for 5.3 and one for 5.4). Merging into each master branch would just follow the existing Gitflow process from each respective develop, since those two won't(?) ever need to interact directly. What do you think? If it sounds confusing let me know and I can throw together a flowchart that should help illustrate the concept. --Kris
