Github Local Setup

[g2ktcf]

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?

[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?
Preventing the warnings for the admin and zc_install folder are done with constants in the admin:

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.

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

[g2ktcf]

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.

[g2ktcf]

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.

[torvista]

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:

dev-*.*

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.

[carlwhat]

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.

[g2ktcf]

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



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

[swguy]

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

[g2ktcf]

> branches and HEAD are not the same thing.

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

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!