Help me escape from Git Hell

In addition to my seemingly insoluble workflow problem here: http://modxcms.com/forums/index.php/topic,53427.0.html, I have a new problem in a different Git clone directory that just won’t go away.

I cloned the MODx 2.0 GitHub branch to my machine straight from the MODx repository (no forking involved). All I’ve done is pull from it, but now I’ve got an unstaged change in core/lexicon/ru/email.inc.php. I didn’t change the file (or any other files), but Git seems to think I did and keeps telling me I have unstaged changes in that file.

I can’t rebase because of the "modified" file. I’ve tried checking out the file (with various merge and force options), git reset --hard HEAD, stash, and everything else I’ve seen mentioned for discarding unstaged changes, but git status continues to report that I have unstaged changes in that file.

I also have a mysterious file called tow.tbh that’s appeared with the ominous but completely incomprehensible content:

fatal: ambiguous argument ’tag’: unknown revision or path not in the working tree.
Use ’--’ to separate paths from revisions

I did "prune" the branches other than 2.0 and possibly that’s a factor, but I don’t see how that would affect a single file.

I’ve been reading everything I can on Git. I’m trying to like it, and I see the value of it to core developers, but I’m really beginning to hate it as a tool for contributors. If we want people to use the development version of MODx and report bugs (and hopefully contribute), we desperately need some MODx-specific Git documentation with detailed workflow advice -- especially since it appears that the SVN version of 2.0 is no longer current.

Please pardon the negative tone, but I’ve spent a week trying to get Git to work for me and getting pretty much nowhere.

Yes it is a bit different, its OK being able to check out branches but if you do a re-build/upgrade you only get one set of core transport files, so you have to keep track of which branch you’re on if you only have one Git directory. I use one for the 2.0 branch, one for the 2.1 etc.and just point my browser at the different installs, bit SVN like I know but at least I know where I am at any time.

Another thing is I’ve not yet sussed how to do development using Git, when I’m developing 3PC’s I usually get a basic package install then replace the /core/components and core/assets directories with their SVN counterparts, then I can carry out work, test changes and just check it in as I go, you can’t do this with Git, you can’t detach sub directories as they don’t contain a tracking directory(SVN uses .svn per directory). I’ve though about using symlinks but I’ve not tried this yet.

I only checked out the 2.0 branch and, like you, I assume that I’ll create a completely separate 2.1 install if I want that.

Did you create a fork for it at GitHub? That’s what the MODx docs suggest. The trouble, as I say in the other thread I linked to, is that if you contribute changes, push them to your fork, and issue a pull request, until your pull request is honored (and it may never be), your local repo is out of synch with the MODx repo. If you want to keep your local repo up-to-date (and your fork) you have to pull from the main MODx repo (which will undo your changes) and push to your fork (which will undo your changes there). You can’t "stash" your changes, because you have to commit them to issue the pull request.

I guess you could do a fetch and a selective merge from the main repo, but I haven’t figured out an easy way to do that. You’d have to remember all the files you’d modified over time (and it could be a long list) and if someone else modifies the same files, it could get pretty ugly.

It would help a lot if you got a quick response on any pull request and you could just revert any changes that weren’t going through, but I doubt if that’s a realistic expectation.

Branching is cheap in Git, so maybe the solution is to create a local development branch that never synchs with the MODx repo. But then, that branch may be missing some critical updates and, over time, it will become useless.

Your idea of using SVN for your work is really interesting, but how do you push those changes to your fork for a pull request?

Are you using a Git GUI, or doing everything in Bash? I’ve been doing pretty much everything in Bash, but it often tells me that my commands are nonsense and I can’t seem to keep track of when to use "modx 2.0" and when to use "modx/2.0".

Hopefully, someday this will all make sense to me.

....but how do you push those changes to your fork for a pull request

I don’t at the mo, I just get a list of changed files from the SVN log and manually copy these into my git project then stage, sign-off, commit, push. The two areas aren’t synced automatically as yet, that’s why I’m, trying to work out how best to develop just using GIt.

I use a git GUI, Cola GIT on my linux box and I think the one on windows is called git-gtk or git-cheetah(can’t remember), helps with visualizing what changed, branch histories, visual commit changes etc.
When you change branches and do a fetch you can visually see where HEAD is, helps a lot.

I solved the original issue by deleting my fork and my MODx directory and starting over.

In the process, I think I may have found a workflow that makes sense with Git.

I created my own fork of MODx and cloned it locally:



So I have a master branch based on my fork (referred to as Origin).

I configured a new remote called "modx" that points to the MODx repository:




updates my master to match the current state of the MODx 2.0 branch. I have to make sure that "git status" shows everything is clean before doing the pull.

If I had local changes to master that I wanted to keep, I’d use this instead:


but I don’t think I ever will because I’ll only work on branches I create.

To contribute, I create a branch and switch to it:


On that branch, I edit files and do


Now I push the branch with the changes to my fork:


And issue a pull request for that branch, then do



Each change I make is on a separate new branch with a new name.

Since I never modify my master branch, and always pull or rebase from the MODx repo, it’s always up to date.
The changes I make in the local branches are never merged into my master branch, but I get them there when I pull or rebase from the MODx repo if the pull request is honored and, if not, I don’t want them.

Once the changes are accepted or rejected, I can delete those local branches with:



And then delete the remote branches with:



It sounds like you have changes you want to keep, so I think you could merge them into your master branch and always use:



I don’t know if this all works, but it’s the only thing I could think of that makes sense and, so far, it seems to be working.

My only question is whether deleting the remote branches after the pull request has been honored could affect the MODx repo -- causing the loss of the changes, but it doesn’t seem like it should.

Hopefully, we’ll get some feedback soon from the git gurus so we know how to work.

I thought I’d update this thread based on recent discoveries.

First, I think the phantom changed files are the result of crlf conversion by Windows. Diff generally shows the files to be identical, or every line in the file to be changed (even though there are no visible changes). Setting core.autocrlf = false seems to help. I still see them occasionally -- always in lexicon files. I generally just commit them, which seems to keep Git happy and, so far, causes no problems.

On the workflow, I’ve been doing a lot of reading and after going though the workflow section of the ProGit book a number of times, I think I’ve come up with a much better workflow for contributors. It’s close to the workflow suggested on the MODx rtfm site, but with one important exception: I clone the modx repository instead of my fork, then create a remote for the fork (called myfork). My master branch matches the MODx master branch, but I never check it out, though it would be harmless to pull to it if the MODx master branch changes.

So the process looks like this:

git clone http://github.com/modxcms/revolution.git revo
git remote add myfork [email protected]:BobRay/revolution.git
cd revo
git checkout -b 2.0 origin/2.0

(now on 2.0 branch)

git pull (pulls from the MODx repo 2.0 branch automatically)



(a naked "git push" fails, as it should, because I don’t have push rights to the MODx repo)

git checkout -b bugfix
(now on bugfix branch -- make some changes)
git commit -am "Commit Message"
git push myfork bugfix

(issue pull request at GitHub to pull from my bugfix branch to the MODx repo 2.0 branch)

git checkout 2.0 (go back to the 2.0 branch).

I never merge anything so my 2.0 branch always matches the MODx repo 2.0 branch.

I don’t think there’s any need to push anything but bugfix branches to my fork, because when dealing with a pull request the bugfix commit will be compared with the current MODx 2.0 head if and when it is integrated, so the state of the 2.0 branch at my fork is irrelevant (not 100% sure about this).

I think the rebase command suggested in the docs is a mistake, because rebasing after pushing changes to a public repository really messes up the commit history, and as long as no local changes are made in the 2.0 branch, it’s never necessary.

If people want to make local changes to the 2.0 branch, they should do it in a new branch below the 2.0 branch or, better yet, in a different install of MODx altogether.