Github Local Setup

I finally got my head around Git with the help of torvista and swguy. So I have a XAMPP server set up locally. I never considered the ability of using git commands just like MS-DOS! lol That is really EASY!

I have cloned my fork of Zencart to c:/xampp/htdocs/zencart that I want to do normal local development on. Actually installed stores will need to have config files added. Do you just copy the distro-config.php files in and NOT add them to git?

But I also want to be able to test on 1.5.7 where the database will be different. To me this means a different Head and different config files. So, this morning I cloned the same fork a second time c:/xampp/htdocs/zc157 so I can keep the config files (and databases) unique and the same. For this clone, I want to reset the head to 157. From what I read, this should work with some warnings about branch management. I do not think my branches will be that complex.

Is this viable?

I think that what I really want to know is how you can switch branches (ZC156/157/158) and get that current branch to use the correct database that was created the first time you used that branch to create a new Zen Cart.
A custom configure with case switch for versions?
Preventing the warnings for the admin and zc_install folder are done with constants in the admin:

Code:

---

define('ADMIN_BLOCK_WARNING_OVERRIDE', '1'); //bypasses checks in (admin) init_admin_auth to allow admin access when a) the admin folder has not been renamed and b) installer folder /zc_install exists.
define('WARN_INSTALL_EXISTENCE', 'false'); //bypasses check in (admin) init_errors: prevents a messageStack warning in the admin if the installer folder /zc_install exists.

---

files named "dev-whatever" are ignored by Git.

git is very powerful. and while you may think it may be easy, it is very easy to screwup.

files named "dev-whatever" are NOT ignored by git. files in the .gitignore file are ignored by git for that specific repo.

see:

https://github.com/zencart/zencart/blob/v158/.gitignore

one can also configure a global .gitignore for ones workstation which are not part of any specific repo.

someone who is new to git changing heads has problems written all over it (IMO). i would suggest reading up on changing branches.

good luck.

Quote:

---

Originally Posted by carlwhat

git is very powerful. and while you may think it may be easy, it is very easy to screwup.

files named "dev-whatever" are NOT ignored by git. files in the .gitignore file are ignored by git for that specific repo.

see:

https://github.com/zencart/zencart/blob/v158/.gitignore

one can also configure a global .gitignore for ones workstation which are not part of any specific repo.

someone who is new to git changing heads has problems written all over it (IMO). i would suggest reading up on changing branches.

good luck.

---

Carl that helps. I did not know that the configure.php files were ignored by Git and that was my problem! Thank you! I have been reading everything I can.

Quote:

---

Originally Posted by torvista

I think that what I really want to know is how you can switch branches (ZC156/157/158) and get that current branch to use the correct database that was created the first time you used that branch to create a new Zen Cart.
A custom configure with case switch for versions?

---

Yes, that is what I was concerned with. Now that I know configure.php is ignored based on .gitignore, this should be perfectly viable solution. I was worried about locally created files and how that worked with git.

Quote:

---

files named "dev-whatever" are NOT ignored by git. files in the .gitignore file are ignored by git for that specific repo

---

Correct.
To clarify my lazy statement....dev-whatever files are ignored in the zencart repository as defined by an entry in the .gitignore file that is in the zencart repository:

Code:

---

dev-*.*

---

Quote:

---

someone who is new to git changing heads has problems written all over it (IMO). i would suggest reading up on changing branches.

---

I've done plenty of reading, but it is not obvious to me what the pitfalls are of changing branches/HEAD are, in the context that is obvious to you?
Can you expand a little on this?
Thanks.

branches and HEAD are not the same thing.

creating and changing branches is part of the power of git.

resetting your HEAD puts you in a detached head state. i do not operate so well in said state.

@torvista you obviously have a process that works for you. but branches and HEAD are different. and being in a detached HEAD state one can lose all commits if a new commit is made on said state.

Again, this Head question could well by my wording mistake on my part. So I have at least one clone of my fork that I can play with so

Attachment 20017

The goal was to be able to bring up an older version to test bug fixes on. Now this says "new" branch which bothers me a bit. Is this actually ZC157? And how are the different releases, A-D noted as they do not appear to be branches. Again, I am a total noob and am trying to tie all the bits I have read into a real workflow here.

Thank you all for you input and patience.

Chris

> branches and HEAD are not the same thing.

Indeed, HEAD is a pointer to a commit.

> But I also want to be able to test on 1.5.7 where the database will be different.

If you REALLY want to do this, you'd be better off creating another folder. But remember that 1.5.7 is currently static and not scheduled to be changed anymore, so it doesn't make sense to use git to manage your view of the files - just pull the Zip of 1.5.7d and set it up.

Here's where branching and changing the current HEAD pointer DOES make sense: suppose @proseLA makes a fix that you want to test out.
You don't want to just merge it in to your current 1.5.8 because it might still change. So:
- create a new branch (and switch to that branch) using git checkout -b new-branch-name
- merge in @proseLA's change
- test
- revert back to the true 1.5.8 mainline by saying git checkout v158.
- (optionally) delete the branch new-branch-name.

Quote:

---

Originally Posted by swguy

> branches and HEAD are not the same thing.

---

Yes, that part is clear but was trying to figure out how to move backward

Quote:

---

Originally Posted by swguy

If you REALLY want to do this, you'd be better off creating another folder. But remember that 1.5.7 is currently static and not scheduled to be changed anymore, so it doesn't make sense to use git to manage your view of the files - just pull the Zip of 1.5.7d and set it up.

---

And yes, this makes sense. Again, my brain wants to understand the workflow for all plausible issues and fixes.

Thanks!

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).

Quote:

---

Originally Posted by 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).

---

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.

Quote:

---

Originally Posted by 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).

---

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

@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.

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.