# Merges between PHP5 and PHP7

- Thread: https://externals.io/message/76794
- Original archive: https://news-web.php.net/php.internals/76794
- Started by Anatol Belski on 2014-08-22T09:20:54+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #76794 — Anatol Belski — 2014-08-22T09:20:54+00:00

URL: https://externals.io/message/76794#76794

Hi,

as there are many data type changes, here's an idea on how to simplify the
merges. Git supports custom merge drivers which attracted my attention, so
I've ended up with the following trick:

=== Add to .git/config ===

[merge "7"]
    name = Compatibility merge between PHP5 and PHP7
    driver = ./replace.sh %A %O %B

=== Add to .git/info/attributes ===

*.c merge=7
*.h merge=7
*.re merge=7
*.l mrege=7
*.y merge=7


=== Create replace.sh ==

#/bin/bash

CURRENT="$1"
ANCESTOR="$2"
OTHER="$3"

#
http://git.php.net/?p=php-src.git;a=blob;f=compat/replace.php;hb=refs/heads/str_size_and_int64
php /path/to/replace.php --macros "$ANCESTOR"

exec git merge-file "$CURRENT" "$ANCESTOR" "$OTHER"


The basic idea behind this - do some automatic processing on the fale
which is getting in before merge. Say when merging from PHP5 to PHP7, one
could automatically replace macro names or whatever, we can extend it. For
now I've just added the macro script.

This can solve simple cases yet, for example if something like this comes in:

if(type == IS_LONG)

it'll overwrite it to

if(type == IS_INT)

before merge start, so the automatic merge will go smoothly.

In the case for example like

char *hello = estrdup("hello");

to zend_string *

or

long one = Z_LVAL(z_one);

to

php_int_t one = Z_IVAL(z_one);

the automatic replacement is not that easy to do, so this would fail (even
the macro names were the same, long vs php_int_t or other placeholder name
would fail). But at least we had a mechanism getting rid of the simple
cases, no matter how the naming issues was solved.

Just as side effect, the git attributes will apply to all the branches, so
that should be activated only when merging 5 to 7. I think a tip from
someone more experienced in git might help to solve this or improve this
mechanism.

Regards

Anatol

---

## #76801 — Derick Rethans — 2014-08-22T11:39:42+00:00

URL: https://externals.io/message/76794#76801 · In reply to: #76794

> as there are many data type changes, here's an idea on how to simplify 
> the merges. Git supports custom merge drivers which attracted my 
> attention, so I've ended up with the following trick:

As there are that many differences, does it still make sense to GIT 
merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I 
would expect that to have a much greater rate of success.

cheers,
Derick

---

## #76920 — Derick Rethans — 2014-08-28T15:23:54+00:00

URL: https://externals.io/message/76794#76920 · In reply to: #76801

> 
> 
> > […]
> 
> As there are that many differences, does it still make sense to GIT 
> merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I 
> would expect that to have a much greater rate of success.

Really, no comments about this at all?

cheers,
Derick

---

## #76921 — Arvids Godjuks — 2014-08-28T15:30:28+00:00

URL: https://externals.io/message/76794#76921 · In reply to: #76920

Just implement and show it working, then i'd say the guys will react.
28 авг. 2014 г. 18:24 пользователь "Derick Rethans" <derick@php.net>
написал:

> 
>
> > […]
>
> Really, no comments about this at all?
>
> cheers,
> Derick

---

## #76926 — Pierre Joye — 2014-08-28T20:01:47+00:00

URL: https://externals.io/message/76794#76926 · In reply to: #76801

>
> 
>
> > […]
>
> As there are that many differences, does it still make sense to GIT
> merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I
> would expect that to have a much greater rate of success.

I brought this topic a while back too. The same issue happens for pecl
extensions. The more exts I do the more I think about either using separate
branches or separate source files, respectively separate realeses or common
release for both 5.x and 7.x.

For the core, I have the feeling than manual merges will be far less
painful.

Cheers,
Pierre

---

## #76929 — Anatol Belski — 2014-08-28T20:43:04+00:00

URL: https://externals.io/message/76794#76929 · In reply to: #76920

Hi Derick,


> 
>
>
> > […]
>
> Really, no comments about this at all?
>
>
Since there was just a little interest, I thought it's rather this topic
died. Now after working more than a week on master I do share your opinion
as well - manual merge is probably the success strategy.

The most pain will come from new APIs, just to name some - zend_string vs
char*, arrays and changed macro/function signatures. However, once 5 is
converted to 7, the pain should decrease. Of course sometimes it'll get
complicated, but that's also not  the case for automatic. I think also,
when we do the further work and see some systematic cases which can be
automated, good to know such a mechanism does exist.

Regards

Anatol