Tag: code monkey

Posted on

GIT Gotchas and other things that make you cry

Lions and Tigers and Bears, Oh My!

Encountered x file(s) that should have been pointers, but weren’t

We encountered this issue when trying to merge master after someone had committed a slew of PDFs. Although we couldn’t identify the exact situation that caused this problem, the result is that nobody could merge master into their branches.

Not No Body! Not No How!
Not No Body! Not No How!

It looks like this was once filed as an issue with git, itself: https://github.com/git-lfs/git-lfs/issues/1939

But amongst the threaded comments, it looks like there is a root issue with the file types that are used to compare files and that on strange and rare occasions a unicorn fart fills the git-void with pain by changing these on the server.

After several dozen attempts, I came across this gem of a command: 

$ git lfs migrate import --everything --include='*.pdf'

migrate: override changes in your working copy? [Y/n] Y
migrate: changes in your working copy will be overridden ...
migrate: Sorting commits: ..., done
migrate: Rewriting commits: 100% (5940/5940), done
migrate: Updating refs: ..., done
migrate: checkout: ..., done

The pain was almost over. Let’s see how merge does, now. 

$ git merge --ff-only

fatal: Not possible to fast-forward, aborting.

Hmmm… Okay. Let’s not force a fast-forward merge; let’s just do a regular merge. 

$ git merge

warning: Cannot merge binary files: Deployment Scripts/CopyFiles/UpperGreatLakesSinglesChallenge.pdf (HEAD vs. refs/remotes/origin/bugfix/13032-ems-error-saving-ppc)
:
:
CONFLICT (add/add): Merge conflict in Deployment Scripts/CopyFiles/UpperGreatLakesSinglesChallenge.pdf
Auto-merging Deployment Scripts/CopyFiles/UpperGreatLakesSinglesChallenge.pdf
:
:

Then I performed a manual merge on all the files by taking the server’s file (on the right in Sublime Merge, when resolving conflicts).
But Sublime Merge couldn’t actually commit the non-changes, so I went back to the git console to wrap up tackling the lfs-merge nightmare (like a Dream Warrior to Krueger): 

$ git commit

[bugfix/13032-ems-error-saving-ppc f093b0c49] Merge remote-tracking branch 'refs/remotes/origin/bugfix/13032-ems-error-saving-ppc' into bugfix/13032-ems-error-saving-ppc
See the source image
Posted on

On Robots, Automation, APIs Opencaching and Groundspeak

I Am Not The Droid U R Looking 4

Groundspeak is shooting itself in the foot, and with the new opencaching.com website, sponsored by Garmin, it’s time they stop being selfish and open up their API … and they better do it quickly.

dor.ky blog, by Scott Wilcox, has a great explanation and a few good comments on why groundspeak needs to open their API.

The forums at groundspeak on the topic pretty much ended with a comment from Jeremy (doubtlessly employed at Groundspeak) stating:

There is a private API and it is available for trusted partners. We have no plans to offer an open public API at this time. It was considered in the past but the current decison is to keep it private.

Sounds short-sighted, if you ask me – especially considering that this comment was made August 2008, nearly two and a half years ago and they still haven’t opened their API.

Why does this interest me? Support tools by fans would be an enormous benefit to Groudspeak. I would like to develop an app or even a web-page that helped geocachers manage and automate their virtual caches. Imagine, as a geocache owner, that you are able to provide a form for people to simply fill out. Once done, it allows the geocacher to log that they found the virtual. (Better yet, it even automates their log post if they have the right answers!)

Imagine, then, the service growing from that idea, allowing earth caches and history caches along with the virtual caches … all automated.

Currently, Groundspeak not only doesn’t provide an API, but their site license prohibits the use of spiders, robots, scraping, etc. That’s understandable, but they should create an API. Google’s done it and see how they’ve grown. Flickr’s done it, too… they’re going strong despite the competition. It appears that any strong data-driven company has an open API. People want to automate process, they want to enhance the experience.

As @williamtm commented on the dor.ky blogpost Why GeoCaching.com needs an API

If an API was made available, and a company/developer like atebits, TapBots, or any number of the excellent developers out there decided to make a Geocaching app, doubtless it would be brilliant. For starters, you can dump the ugly custom UI, improve the speed of it, and, as you said, improve the reputability of it over 3G/EDGE/etc, and bam, you might have an app that’s actually worth £5.99.

Fact is, the app as it is now is just terrible. It rarely seems to work when I’m out and about and want to find nearby caches, and often simply visiting the website using Safari and finding caches that way is faster.

At such a critical time when new geocachers are nudged into other offerings, it’s the combination of a variety of good tools and access to data that will win the race. Opencaching.com already has a public API out and ready for anyone who wants to develop a kick-a$$ iPhone app for them (and I would be one of the first ones to buy it)… Is geocaching.com up to the challenge?