SourceTree Git Keeping gitignored Folders on Branch Switch - wordpress

I just checked wordpress into git. I do have the common folders like wp-admin or wp-contents/upload/ on .gitignore since I don't need to stage them.
However I now switched to another brunch and realized those common folders were deleted from the folder.
Is it possible to keep this folders switching a branch?

I guess your another branch doesn't have that common folders originally.
If you want to have common folders for all branches,
Folders must exist before branching.
Sometimes, one branch push its result to another branch, but I think it isn't good.
It's likely to messy your source code management.
When branch finished you can merge it to trunk, then it can be common folders.

Related

Work by team with git on localhost

I am a beginner to this topic and I start developing a part of the special theme on wamp (localhost) and another teammate work on the remaining part.In this regard, think that I should use Git but I do not know what folders (wamp and wp and theme and plugin) put in the repository and which client of git is more suitable for us (all of us do not have much knowledge and little time to do it). please guide me.
anything that needs installation keep it outside of git.
any file which is specific to your machine and local settings , keep t in .gitignore
all the files and folders that are required to setup the project in any new machine + any files that would be changed by your teammates , include in the git.
ideally, the git init should be done in the project root. ou can make a branch for every theme and merge later when finished.
I'd initialize GIT in the root directory of the template itself since you only make changes in that specific folder.
In this case, each template/theme can be considered as one single GIT repository.
Hope this answers your question.

TortoiseSVN "tree conflict" on file when merging

I have a directory in my trunk (trunk/gray/catalog/web/app_code/), and my branch (branches/125/gray/catalog/web/app_code/). The trunk and branch contain 8 files common to both, but the branch has 20 files not found in trunk. These files were SVN added to the branch. Both directories only contain files as children (no children directories). gray/catalog/web/app_code/ was made in the branch and trunk separately with SVN Add.
When I attempt to Test merge branches/125/gray/catalog/web/app_code/ to trunk/gray/catalog/web/app_code/ using Tortoise SVN all of the common files show tree conflict errors, and the files in branch but not in trunk are not added to trunk.
If I attempt the test merge to/from at the gray/catalog/web/ level then no conflicts are shown. The 8 files which are common are shown as being SVN adds, and the 20 files in branch but not in trunk are not added or mentioned at all.
What might cause this?
Don't know if this is beyond stating the obvious, but most of my tree conflicts stem from having renamed things and SVN gets riled up.
Were these files renamed multiple times? or possibly all copy pasted?
Typically these are highly annoying, but fixable by tricking SVN. Either using a switch command, or creating the files anew.
Resolving tree conflict
Why am I getting tree conflicts in Subversion?

Use Fossil for system files?

As a new user of Fossil, I'm curious if there are any negative implications with using Fossil to store things like /etc/, /usr/local/etc files from Unix like systems like FreeBSD & OpenBSD. If I'm doing this for multiple systems, I think I'd create a branch with each hostname to track those files.
Q1: Have you done this? Do you prefer a different VCS to handle the system files?
Q2: Lots of changes have happened in Fossil over the years and I'm curious if it's possible to restrict who can merge branches with trunk. From reading earlier threads it wasn't possible but there are two workarounds:
a) tell people not to merge to trunk
b) have people clone and trunk maintainer pick up changes from their repo
System configuration files stored in /etc, /var or /usr/local/etc can generally only edited by the root user. But since root has complete access to the whole system, a mistaken command there can have dire consequences.
For that reason I generally use another location to keep edited configuration files, a directory in my home-directory that I call setup, which is under control of git. Since I have multiple machines running FreeBSD, each machine gets its own subdirectory. There is a special subdirectory of setup called shared for those configuration files that are used on multiple machines. Maintaining multiple copies of identical files in separate repositories or even branches can be a lot of extra work.
My workflow is the following;
Edit a configuration file in my repository.
Copy it to its proper location.
Test the changes. If problems occur, go back to step 1.
Commit the changes to the revision control system. Copy the
committed files to their proper location.
Initially I had a shell script (basically a list of install commands) to install the files for me. But I also wanted to see the differences between the working tree and the installed files.
So for my convenience, I wrote a script called deploy to help me with this. It can tell me which files in the repo are different from the installed files and can show me the differences. It can also install files to their proper locations.

Single git repo setup tracking multiple locations on hard drive

I'm very new to the world of git (done some svn in the past) and would like some advice on trying to accomplish the following.
My current workflow is that I setup the static html files using Middleman to get the base HTML structure and styles before porting over to a Wordpress template. These static files are located at C:/git/project-name/HTMLTemplates.
My wordpress setup uses Xampp so the theme files are kept in C:/Xampp/wordpress/wp-content/themes/project-theme.
What I would like to do is have a single git repo that tracks the changes of the two different locations (HTMLTemplates and project-theme)
Is this at all possible, or do I simply create two individual repos (eg: proect-static and project-wordpress)?
No, there is no mechanism in git for this. Git assumes that all files that it manages (the "working copy") live in a single directory (and subdirectories); there is no support for managing two separate directories in in repo.
So you'll have to somehow keep everything in one directory, probably as subdirectories HTMLTemplates and theme or similar.
You could use two git repos, but I'd strongly advise against this. A single repo should contain a whole "project", i.e. everything needed to build one piece of software (excluding things like external libraries). If you split your project across two repositories, you cannot usefully branch and merge (because you'd have to do it in both repos simultaneously), you cannot easily check out old versions etc..
To solve your problem, I see a few possible solutions:
Have some build / deployment script that copies everything to the right places. You probably alread have a script that invokes Middleman, and possibly tells Wordpress to refresh its cache, so you could add it there.
Set up a symbolic link for the wordpress directory. On UNIX-like systems this is easy and commonly done. On Windows, you can create "junction points", which I believe work similarly.
Configure Wordpress / Apache to read the directory directly from your git working copy. The path should be configurable.
I would prefer the first solution; this has the added advantage that it will decouple your development environment from the server configuration. This will make it easier if your setup later changes or your project needs to run in a different environment (development on a different machine, someone else also wants to work on your project, you want to deploy to a hosted server somewhere etc.).
Note: The problem is, I believe, that your are trying to use git as a deployment tool. While many people do this, git is not really suitable for this purpose. Deployment should usually be a separate step.

could not guess version control system

recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.

Resources