Выборочная загрузка файлов из репозитория

Можно инвертировать: сказать гиту игнорировать изменения части файлов. Тогда git pull или любая (ну почти) другая команда git на них не будет влиять. Главное не забывать, что эти файлы игнорируются, а то потом можно долго сидеть и искать, что не так.

Игнорировать файл:

git update-index --skip-worktree file1 file2 ...

Не игнорировать файл:

git update-index --no-skip-worktree file1 file2 ...

Есть ещё --assume-unchanged, но разницу между ними не помню, так что читать git help update-index.

Проверил, и вот что получилось.

git update-index --skip-worktree file1

Изменил файл на github и сделал git pull в локальный репозиторий. И изменения всё равно загрузились. Далее решил сначала изменить локальный файл file1. Сделал git status и изменений не увидел. Затем изменил файл на github. Попытался сделать git pull и получил ответ:

error: Your local changes to the following files would be overwritten by merge:
        file1
Please, commit your changes or stash them before you can merge.
Aborting

Не работает, выходит.

Там наоборот, можно сказать локальный ignore. Т.е. после

git update-index --skip-worktree dir/*

for file in dir/* ; do echo $RANDOM >$file ; done

команда git status скажет, что ничего не поменялось.

Я до конца не уверен, но считаю, что частично загружать коммиты не получится: внутренности git таковы, всё — это обьекты и связи. Нарушение связей — ошибка. То есть загружать (git fetch) в любом случае придётся всё объекты (изменения/коммиты). Другое дело — как применять эти изменения. Но раз они уже загружены, то почему бы их не применить полностью?

Тогда, наверное, будет лучше, если коллеги будут целиком загружать мой репозиторий с помощью git pull. В другой директории у них будут храниться уже файлы, измененные ими для себя. И из первого репозитория во второй будут копироваться только необходимые обновленные файлы с помощью какого-нибудь скрипта, правильно? Т.е. эта проблема не решается с помощью git'a.

перед пуллом можно делать стэш, после пулла анстэш

заводим отдельный бранч со своими изменениями

сразу после пулла нужно нужно ребейзнуть этот бранч на мастер.

перед пушем и пуллом нужно из основного локального бранча убивать все коммиты из «бранча с изменениями»

руками - через interactive rebase

или можно написать скрипт. Суть такова: все коммиты из «бранча с изменениями» помечаются. Например, через git notes. Или commit messages начинаются с определенной строки типа REMOVE_ME. Дальше скрипт бежит по основному локальному бранчу и черрипикает все коммиты, которые не имеют такой метки.

а вообще, специально для этого есть stash-unstash

Хм, и правда. Мне почему-то казалось, что оно в обе стороны работало, не помню такой ошибки.

перед пушем и пуллом нужно из основного локального бранча убивать все коммиты из «бранча с изменениями»...

Сильно всё переусложняешь. В таком подходе просто нужен git pull в мастер и git rebase master из бранча со своими изменениями. Не нужно городить никакое адище со скриптами. И ТСу нужно переностить файлы целиком, rebase этого делать не будет.

год юзал git-svn, таких скриптов наплодил афигительное количество. Работает, но очень легко ошибиться в скрипте и похерить чужую работу. Или еще хуже - посреди скрипта ошибка, и огромный репозиторий снова git-svn'ить два часа (эти два часа тебя будут непрерывно бить ногами за закоммиченый косяк). В общем ты прав.

Чего только не делают люди, лишь бы не использовать darcs.

Дешевый понт: для vcs важна возможность работы под большим числом возможных архитектур. И предсказуемость на больших проектах.

Кстати, lazy-get относится и к отдельным файлам? (а то казалось, что просто избегание отдельных ревизий и веток из истории)

для vcs важна возможность работы под большим числом возможных архитектур

Ну да, darcs на atmega8 не работает. А git?

И вообще. Я всегда думал, что важно удобство инструмента в первую очередь.

Ну да, darcs на atmega8 не работает. А git?

Не может нормально ответить - промолчи.

И вообще. Я всегда думал, что важно удобство инструмента в первую очередь.

Илита головного мозга? В чем-то удобнее, в чем-то нет.. второе: для git/hg (в меньшей степени) существуют удобные «платформы» (darcsweb и patch-tag, если не ошибаюсь, - не дотягивают). Да и коммьюнити хаскеля, почему-то почему-то больше склонно к git: по hackage прослеживается.

Не понимаю, как тут помогут «stash-unstash», он разве при apply (pop) не смержит вместо перезатирания?