Github Local Setup

[swguy]

You certainly *can* move backward; I posted the workflow on the Zen Cart github in answer to your question there.

git checkout v157

The only trouble is that you'll have to keep fiddling with your configure.php files if you do this, since the databases differ between releases (158 vs 157).

[carlwhat]

You certainly *can* move backward; I posted the workflow on the Zen Cart github in answer to your question there.

git checkout v157

The only trouble is that you'll have to keep fiddling with your configure.php files if you do this, since the databases differ between releases (158 vs 157).

i have not had problems using v157 code on v158 databases.

that's not to say they do not exist; i just have not had problems.

v156 and earlier represented problems due to the ezpages db reconfigure, from what i remember.

that said, i am sure that with a little bit of ingenuity, one could use the configure file to determine which codebase they are in, and then adjust to use the correct database so that these problems do not exist when one changes between branches.

best.

[g2ktcf]

You certainly *can* move backward; I posted the workflow on the Zen Cart github in answer to your question there.

git checkout v157

The only trouble is that you'll have to keep fiddling with your configure.php files if you do this, since the databases differ between releases (158 vs 157).

So true. I have it opened in Notepad++ and just forgot it was there! Crap. Thanks for the reminder.

[swguy]

@carlwhat This thread is really not for experienced developers like you. It's for rookies. And my guidance to rookies would be, don't do this and expect it to work well in all circumstances.

Create a github repo to work on a single active branch (1.5.8 currently), and branch off that.

[mc12345678]

Wrote this a little while ago, but got interrupted. Seems to still apply and if not mistaken answers a related question either here or on a different related thread.

With my git software, I routinely retrieve the 1.5.7 (v157) github repo and then move my pointer for my local version to the current published version. This bypasses any merge conflicts that the team may have had to resolve. I also set local tags to the individual released versions which gives me an opportunity to see what differences have been made following a publicly released version. It does entail keeping up pointers to various areas in the distribution and recognizing what are things that were modified for all and what I may be doing locally.

As for configure.php files, I don't normally keep them in the repo as they can cause issues in applying to a chosen site or domain if not purposefully omitted when updating files to said server. Besides the zc_install process will normally generate those files with the format being comparable against the dist-configure.php version. Further if the fileset gets pushed to your online github, unless you have set those files to be ignored, then your credentials are publicly captured in a public repo. If the repo is private, of course the same concern doesn't exist.