Поправьте таки свой вопрос. Что вам нужно? Рандомные числа, состоящие из неповторяющихся цифр? Тогда замените "чтоб в строке не было одинаковых чисел" на "чтоб в строке не было одинаковых цифр". Если так, то Ivanq написал приемлимую реализацию.
2. помещаете нужный файл в рабочую директорию любым способом. Например,
git checkout --
Где - любой коммит, в котором этот файл нужной вам версии. см. https://git-scm.com/docs/git-checkout
Я немного запутался что и как вы сделали и через что пытаетесь работать (gui или git bash). Судя по содержимаму вашей директории .ssh - у вас там git_hub - привытный ключ в формате OpenSSH, github_rsa.pub - "парный" публичный ключ. Правда, не совсем понятно как эти ключи там у вас появились. Наверное, вы ставили какой-то софт от GitHub и в какой-то момент у вас создались эти ключи.
Так что в своем ответе я рассказал, как нужно действовать "с нуля".
Пример реализации: stackoverflow.com/a/7550430/3653002
Как альтернатива - вызвать системную функцию получения размера папки. Если это линукс - команда `du`.
В Винде не знаю.
А приведите, пожалуйста, пример в своем ответе. Мне вот, как новичку в конфигурировании nginx, не понятно как тут можно использовать именованные секции. Спасибо.
CwRsync - собственно, rsync под винду =)
Так же можно использовать winscp. Я использую сейчас его по некоторым причинам, но, мне кажется, что rsync будет лучше.
Опишите вкратце путь задачи. Кто ее ставит, как/где тестирует, как она попадает к заказчику? От этого и ответ будет зависеть. urmaul вот вполне логичный вопрос задал - почему бы вам не вливать в мастер не всю ветку develop, а только ветку задачи. Но в некоторых случаях это будет не применимо, например, если у вас передается несколько задач за раз. Как у вас деплой происходит? Автоматически из ветки гита или как-то еще?
Опишите более детально, какие есть участники процесса и как они взаимосвязаны. Я пока понимаю так:
1. Сервер с репозиторием git. Это, так сказать, центральный репозиторий.
2. Компьютеры клиентов, в том числе ваш, имеют свои локальные репозитории, осуществляют обмен изменениями через центральный репозиторий.
3. Сервер с вашим приложением. Нужно, чтобы код на нем постоянно соответствовал тому, что лежит в определенной ветке вашего центрального репозитория. К этому серверу можно подключиться по ssh.
Ну, понятно, что конфликтуют изменения. Под конфликтом конкретных коммитов я имел ввиду конфликт их изменений. То есть, мне нужно узнать, в каких коммитах сделаны эти конфликтные изменения.
Именно в данной ситуации merge мне плохо подходит. Я оставил за рамками вопроса эти детали, но раз зашла речь...
Вливать эту ветку в мастер я пока не могу, и мне нужно поддерживать ее в актуальном состоянии.
В каждом коммите в этой ветке выполняется какой-то этап большой задачи.
Например, в одном коммите я удаляю из набора файлов определение некой неиспользуемой функции.
Если кто-то в мастере создает еще один файл с этой ненужной функцией - будет логично изменить именно тот коммит, в котором выпиливаются эти функции из системы. Я это и делаю. Коммитов там - под 30. Если я буду каждое такое исправление делать отдельным коммитом - потом сам черт ногу сломит что я там делал. А так все относительно структурировано.
Так что я время от времени делаю ее ребэйз на мастер, правлю конфликты и, затем, вношу необходимые фиксы в каждый коммит.
В итоге, когда я волью ее таки в мастер - будет ответвление с последовательностью коммитов, которое сразу обратно вливается в мастер. Все прозрачно и наглядно.
Если бы я использовал merge мастера в эту ветку время от времени - было бы не ясно как именно я разрешал конфликты, я бы мог там ошибиться и фиг потом это заметишь. Так же история этой ветки растянулась бы на много экранов, и коммиты в ветке были бы довольно бесполезны сами по себе и было бы их больше 200.
@codercat, я думаю, определять таймзону по ip - плохой вариант, если он не дублируется каким-то еще. А если пользователь заходит из-под прокси или впн? Сложно представить чисто серверный вариант, который был бы лишен этого недостатка.
