As I have been, on Linux and Mac, I have a partial solution to the problem of checking out the juce tip. It appears the GIT community decided that a merge strategy of ‘theirs’ (there is an ours strategy) was silly, and it was removed. They have decided that we should all become better programmers and ever deciding that our work is inferior to that of Jules means we are weak etc. Sort of a Sparta programming ethos. Delightful.
So that means we can’t do what we’d like, which is:
git merge -s “take new version over mine if conflicted”
This only crops up if you’ve made any local changes at all. Like building the project, or something radical like that.
Anyway, if a straightforward merge fails, I think the best approach is to check all your changes (and untracked files, whatever) into a new branch, then fetch the origin and then try to merge the bits you care about. I wouldn’t be surprised if that runs you into trouble down the line though.
The nuclear option - and don’t blame me if you lose code doing this, is:
git fetch origin
git reset --hard origin
I did a pretty good mess around with checkout, pull, fetch etc., and the problem is I end up with merge errors all over. Obviously, trying to manually merge juce_amalgamated.h/cpp would be ‘a bad thing’. If someone does have a better strategy, please pipe up.
Couldn’t you clone a fresh copy of JUCE, then merge your changes onto that? A little convoluted, but would it satisfy the requirement?
edit: I think this is meant to be handled by using branch and checkout, but I haven’t quite got my head around it yet either. If anyone could shed some light on this, I’d love to get back to working on my project rather than messing with git. Its name implies that it is the stupid one, but it sure has a way of making me feel like I am!
I’m about to give up on Git and go back to using just JUCE snapshots.
I find the terminology confusing.
I can’t diff a changed JUCE file without it being marked as if the whole file was changed. I guess it has something to do with line ending, but I already tried going through the settings and re-installing.
Git GUI feels like alpha quality software. Git Extensions was pretty much useless too.
I wonder how other teams handle this, specifically how do you keep everybody in sync?
I agree with Bruce that git commands aren’t intuitive for us poor userspace hackers.
What I’m doing, Bruce, is that I’m building a patch for my modifications and then I try to pull the juce head. If that fails, I force remote cloning and reapply the patch (interactively).
It’s a pain that the software is supposed to solve but doesn’t.
Especially if your background is SVN, you must forget about central (and simple) SVN managment.
TortoiseGit in that case is a pain, as it’s reusing TortoiseSVN icon and action name, but it doesn’t perform the same actions (so for me, I have numerous SVN repository, and few GIT repos, I must constantly remind myself not to commit in a SVN repo, or diff/patch/merge in a Git repo).
I had numerous strange issue with Tortoise GIT from simple bad line ending conversion (in that case I started command line git with force option to solve this), unreliable pull/update (something I don’t get any news about changes in a remote repository, and then suddenly 2 weeks full of updates appear).
I wonder if it’s tortoiseGIT fault, sourceforge, or my internet connection, but a “couldn’t connect/understand remote/origin” message would have been welcome.
Ok, I’ve sent a bug report to TortoiseGIT, and which a long and hard test, we’ve conclude this:
Juce repository already includes CRLF as end of line, so if GIT is set to autocrlf to true (the default under windows), then when you checkout the repository, and then try to commit, GIT removes the CR, and because the official files have CRLF, it thinks that all files are modified.
Once solution is to set autocrlf = false in your git config, but if you have any other project with GIT, it’ll break.
Jules, can you make sure the files in the repository are all “LF” ended ?
GIT’s devs thought Linux was the standard, so I guess it easier not to struggle against their choice instead of trying to pass bash script to convert CRLF to CRCRLF to fool GIT stupidity.
OK, I’ve started to mess around with another project that’s considering Git. I mentioned my problems with it, and someone there pointed to the ‘solution’ - git rebase.
git pull --rebase origin master
Will, instead of pulling the tip and trying to merge it, strip off your local changes (if any), then make the tip your new branch head and try to replay your local changes onto it.
As far as I can tell, even though this make merges harder, the juce tip will now be ‘behind’ your changes, so you will be better able to revert/remove things and be where you need to be.
There’s a few other ways to use it - fetch then rebase, for instance, but this seems to be the fave.
Hope that makes sense.
These are the original links I was given, each of which has other links to info:
Just to note that a) I hate git compared to svn, and b) I seem to rely on Beyond Compare from Scooter Software for keeping track of changes between files and folders these days. Saves me ages! There isn’t a Mac version, so I use it through Windows XP via Parallels.
SmartGit is really neat. It’s not open source, but the non-commercial license is free… Works on mac, windows, linux… I hope it makes learning git a little easier for me.
