0

I'm using Github pages with Jekyll, and I'm using a plug-in to generate a search index. The plug-in doesn't run on Github, but it does run on the local instances for those of us using Macs and as a daily cron job on a Linux server. The problem I have is that a number of the contributors use Windows, and the plugin won't run on Windows and won't allow Jekyll to start. So, what I'd like to do is to prevent the Windows users from pulling the _plugins folder, Gemfile, _config.yml and a couple of other files and folders, while still keeping all those things synced to the Macs and Linux machines, and keep using Github as the master repository for all this, including the plugin.

I've tried .gitignore (using the whole git update-index --assume-unchanged thing, and then changing the files/folders locally), but that only serves to prevent local changes from being pushed to the master repository, if anyone changes one of the undesired files they will be retrieved on the next pull.

Any ideas as to how I can get around this?

Kara
  • 6,115
  • 16
  • 50
  • 57
IanG
  • 1,459
  • 3
  • 13
  • 18

2 Answers2

1

If all you have is a hammer...

If you have at least Git 1.7, you can use Sparse checkout. Here's some more information.

Really, using Git to fix broken code sounds like a bad idea. Maybe someone will have a more useful suggestion.

Peter Lundgren
  • 8,787
  • 2
  • 26
  • 21
  • Oddly enough I think the end of your comment here may have triggered a couple of synapses, and I think a better approach than trying to force Git into unnatural acts would be to run Jekyll in safe mode. Thanks. – IanG Dec 16 '13 at 22:33
  • Unfortunately the --safe mode option for Jekyll didn't work here because using the plugin requires some extra gems in the Gemfile, and it's these Gems that cause Jekyll to fail on Windows. Oh well. – IanG Dec 17 '13 at 16:13
0

There's nothing built in for this (probably there should be—it would be a way to work around the case-insensitive vs case-sensitive host file system issues).

At the bottom level, you would in general not want to do this at all. The reason is that git doesn't store files by file name. Instead, it stores data by content. It turns all data—whether that's some actual file contents (which git calls a "blob"), or a "commit", or either of the other two internal data structures—into a unique SHA-1 value.

The part of interest here is one of the other two data structures, the "tree". (The last one is the "annotated tag", or sometimes just "tag", but plain "tag" can be confused with the lightweight tag that lives outside the repository object database.) It's the tree that provides the names for each blob within a commit.

You can view the process by which files, trees, and commits are entered into a git repository in section 9.2 of the Git Book.

What git needs here, but does not have, is some simple and convenient way to modify the mappings between "names in the tree objects inside the repository" and "names in the file system on the host holding the work directory". This can be done, in both directions. The Git Book link above shows how you could do it "on the way in" (to take local files and give them tree names that differ from their on-disk names). It's less painful—but still not painless—to do it "on the way out". In particular, you can set up what git calls "sparse checkout" mode to avoid checking most stuff out; then you can use git show to extract individual files under different names:

git show HEAD:path/to/foo > different-name

if necessary.

If there were some way to set up the mapping, you could do something like:

cp mappings/windows-map > .git/info/filemap # NOTE: I MADE THIS UP

(where mappings/windows-map would say that repo-name _config.yml should be turned into working-file-name not-for-use-on-windows/_config.yml, for instance). That would even let you edit the file and commit it, reversing the mapping. But there isn't, so you can't.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks, good info. Agreed that this would be a nice-to-have. I can think of quite a few use-cases where this would be very helpful. – IanG Dec 16 '13 at 22:31