- 1
- 2
- 3
- 4
- 5
Господа. Помогите решить хитрую задачку.
Есть у меня проект корне которого лежат файлик весь проект под контролем git кроме этого файлика. там конфигурация специфичная для тестового сервера.
Вот мне нужно сделать еще одну ветку, и как бы сделать так что бы этот файлик был подконтрольный гиту в этой ветке.
т.е. когда я делаю checkout файлик менялся. А когда push файлик игнорировался бы.
Очень буду благодарен если кто подскажет как быть.
Follow us!
>проект под контролем git кроме этого файлика
Тогда уж:
А вообще, автор явно хочет сотворить хуету, раз ему понадобилось что-то подобное. А потом будут ныть "кокококококо гит говно то ли дело свн"
Поэтому вопрос и тут ;)
> раз ему понадобилось что-то подобное
Не понадобилось. Не выйдет.
Даже если эта магия возможна, то получится фигня.
Был файлик вне мастера, при чекауте другой ветки перетёрся, при переходе обратно на мастре остался файл из чужой ветки.
Да ну, при переходе на мастер файлик выносится. Он только в той ветке и существует.
Я бы написал скрипт, который смотрит на текущую ветку гита, генерячит конфиг и запускает сервер. И поместил бы скрипт в .gitignore.
А кто сказал, что это надо делать в гуе? И в каком из гуев?
http://habrahabr.ru/company/microsoft/blog/216037/
но при этом есть и консоль, it's up to you
В спермомирке.
Я иногда смеха ради пытаюсь их открыть и понять, как делать ребейз, pull --rebase, merge --squash или что-нибудь подобное, плююсь и закрываю.
Ну и если есть разработческий сервер без иксов - гуй вообще не вариант.
Для не-программистов (бек-оффис тоже работает с репозиторием в плане управления медиа-ресурсами) немного сложновато, но после обучения кое-как справляются. На програмистов оказывает другой эффект - те, кто пользуются либо виндузятники, либо маководы, и для них графический интерфейс представляет как-бы все возможности программы. Т.е. даже если что-то можно сделать, но этого нет в интерфейсе программы, то целесообразность это делать тут же ставится под сомнение. Логика такого человека работае примерно так: если в интерфейс не добавили, то наверное, это что-то плохое, или ненадежное, или очень продвинутое, доступное только администратору и т.д. И поэтому это делать не нужно.
По другим наблюдениям: люди которые пользуются графическим интерфейсом к Гиту не могут нормально мержить и не могут оперативно искать информацию в репозитории. Т.е. по-сути пользуются ВЦС для того чтобы выкачать код и закачать обратно.
Я подозреваю, что без графического интерфейса они мёржить вообще не смогут. Интерактивный мёрж, кмк - основное преимущество графического интерфейса и плагинов.
1. пул другую ветку.
2. коммит того что автоматически смержилось (зачастую с "елочками").
3. правка предыдущих изменений.
Я не спрашивал, но подозреваю, что среда делает неудобным произвольное редактирование результата, и т.как простым "выбрать А/Б" не получается решить, то решение оставляется на потом. Почему нужно коммитить промежуточную стадию - хз. Но делают это с упорством достойным лучшего применения.
Я всегда коммичу. считаю чем чаще тем лучше. правда не в мастер. делаю ветку task777 например и туда весь поток сознания. Ну еще у меня хуком на коммит кеш чистится. :)
Мне очень нравится, постоянно пользуюсь
Там однородный интерфейс для добавления в индекс/удаления из индекса целых файлов и отдельных чанков.
Единственная проблема - он на моём сервере почему-то подтормаживает.
Повезло Вам, с нормальными людьми работаете. Вот если бы они игнорировали более простой путь нажатий на кнопки, погружались бы в чтение инструкций и копались бы в недрах неосновного инструмента (основной - IDE/редактор, без VCS можно обойтись) и рассеивали своё внимание на ненужные действия, то стоило бы волноваться за их психическое здоровье.
> Простота в использовании - явно нет.
Опять же, всё относительно. Нажать на кнопку проще, чем искать редко используемую фигню. Нажать на кнопку проще, чем вбивать одну и ту же часто повторяющуюся команду ещё раз. Нажать на 10 кнопок, поставить 20 галочек и проскроллить до нужного поля - сложнее, чем написать скрипт.
А простота тут непростая, интегральная. Включает в себя привычки, стиль жизни, частоту использования определённых операций и и их многочисленность. Плюс навязанная сложность. Подключившему интернет вдруг хочется сидеть и читать новости и высеры своих знакомых, познавшему регулярки - везде пихать их, прослышавшему про CVS и --magic-option-132 использовать их.
Если Ваши коллеги удовлетворяют потребности клиентов, довольны своей работой и не используют то, что им не нужно, то остаётся только порадоваться за них. Пришёл, поработал, сфокусировался на коде, а не на побочных программах, не забивая себе голову консолепроблемами, нажал на кнопку, всё работает, все довольны, и побежал вечером домой к жене. Красота же.
Простота обычно понимается как минимальное количество атомарных операций необходимых для того, чтобы выполнить какую-то задачу. Например, для того, чтобы набрать параграф текста можно жать на кнопки экранной клавиатуры мышкой, а можно печатать. С экранной клавиатурой - сложнее.
Как правило продвинутые пользователи используют менее сложный интерфейс для того, чтобы повысить производительность. Т.е. производительность повышается за счет того, что выполняется меньше атомарных операций для достижения цели. И как правило в таком интерфейсе кнопок очень мало. Например, профессионал в работе с Фотошопом обычно работает в полноэкранном режиме в котором кнопок вообще не видно. Профессионал в 3Д типа Майи так же работает с интерфейсом с минимумом кнопок. Люди, которые много печатают (стенография, редактирование) предпочитают интерфейсы с минимумом кнопок, и еще есть куча примеров.
Мои коллеги - просто нубы, по большому счету. То, что они кого-то удовлетворяют, это просто счастливая случайность. Радоваться за них - ну я не знаю, в смысле "им повезло" - наверное. Но если посмотреть на это с позиций справедливости, то их везение - не заслужено, и особо не радует.
> отказывается пользоваться принятыми определениями
Определений не было. Здесь может быть и так, и так, смысла в спорах нет. Иначе же выйдет какая-то философия. Сотни ненужных определений, километровые математически выверенные споры на пустом месте и одна бритая птица, прекращающая все ненужные споры.
> продвинутые пользователи
Профессионалам пришлось долго к этому идти, долго учиться, оттачивать мастерство. Возможно, что-то пришло естественным путём.
Простому человеку сложно быть эффективным, работая так же, как и профессионал. А если потом он собирается вообще свалить в другую область, то переходить на другой интерфейс вообще нет смысла. Тем более, что у программиста не такая бурная работа с кнопками/инструментами как в фотошопе, а набирать буквы и скобочки программисты могут и так достаточно хорошо.
> Но если посмотреть на это с позиций справедливости, то их везение - не заслужено, и особо не радует.
Если Вам приходится доделывать за ними, а всем платят одинаково, то да. А если они никому не вредят, то пусть живут себе. Просто не смотрите на то, как они работают, если это возможно.
Тут дело не в том, что приходится за кем-то доделывать. Работать с нубами плохо не только изза этого. Например, нельзя рассчитывать на хорошее понимание кода сотрудниками, нельзя рассчитывать на самостоятельность в решении повседневных задач. Нельзя рассчитывать на оперативную смену технологий. Плохо еще и то, что у нубов есть такое же право голоса относительно решений которые должны приниматься всем коллективом относительно будущего проекта.
Примеры:
- Я не могу использовать хорошую систему сборки потому что сотрудники не умеют пользоваться ничем. И после года мучений, они так и не научились пользоваться Антом который когда-то был выбран потому что лучше всего интегрируется с их редактором.
- Проект над которым я работал целый год похоронили потому, что ни один из сотрудников не осилил с ним разобраться. Проект требовал знания другого (но очень похожего) языка.
- Я не могу объяснить менеджменту что именно плохо в проекте потому, что нубы-сотрудники не понимают проблему. И, как следствие, я не могу ее исправить, потому что у меня для этого нет ресурсов.
И с чего, ты взял, что не меняю?
Основатели компании придумали что-то, что может зарабатывать им на жизнь. Но придумали они это скорее случайно, т.как до конца не понимают почему оно работает. Но т.как работать оно продолжает, и прибыль какую-то приносит, то компания может развиваться, в том числе пополняя штат. У нас, сейчас, по моим скромным подсчетам, менеджеров пример 50% от всех работающих в компании, например. И, прямо скажем, пользы от этого нет никакой. Все эти люди по-сути существуют за счет компании, и занимаются тем, что проводят большую часть времени в бесполезных совещаниях.
Просто, обычно, люди предполагают линейную зависимость, и равномерное распределение вклада в успех компании от всех, кто в ней работает. Но вполне же может быть и так, что от конкретного работника зависит меньше 0.1%, и тогда становится абсолютно не важно, нуб он, ходит ли вообще на работу и т.д. Более того, возможны ситуации, когда вклад негативный, но все-равно компенсируется другими работниками.
Статистика нормально работает только на большом количестве тестов...
Да еще и величина тут не совсем случайная. Запросто можно все 10 стартапов слить...
11 лет.
- интересно, а magit в этой системе координат "умный" или "красивый"?
А еще лучше таки чекинить общий файл с конфигурацией указывающий на локальный файл, который уже самому и менять. Я так делаю с настройками среды. Т.е. в Гит попадает файл с
А уже в environment.ini можно писать что угодно, и не думать о том, как оно будет у других разработчиков.
А ведь все эти костыли из-за пыховской рахитектуры, при которой в одной папке могут валяться и статика и запускаемые скрипты и модули... Даже в сраном CGI было разделение.
И shared-хостинг тоже необязателен. Можно поставить PHP хотя бы на питушиный OpenVZ и вынести весь код за пределы документрута.
Впрочем, некоторые движки обходятся без .htaccess. В начале каждого php-файла производится проверка константы, объявленной в index.php, из которого данный файл должен инклюдиться, и, если константа не объявлена, «хакер» посылается на три буквы.
Но повторяю, что необходимость в костылях возникает только на shared-хостингах.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]
хотя бы так. вот например у меня с ним и проблемы. в старой версии в нем "садом и гамора". И на продакшене соответственно тоже самое. Вот в данный момент пилю новую версию сайта. Но и баги же исправлять надо в стабильной версии. Вот баги исправляю в стабильной потом мержу с девелоперсокой а этот htaccess запарился я его руками менять. Да кто муже раз не поменял залился продакшен свалился, бида печаль
Только что он делает хз. У нас есть админ который не умеет nginx. А мне не когда еще nginx курить, мне жопы с SOAP с головой.
Сочувствую.
с другой стороны, он сам виноват, что пытается осилить ынтерпрайзные вещи из технологий для разработки домашних страниц
С клиентской стороны - вполне няшная либа: даёшь ей wsdl'ку и получаешь объект с соотв. методами. Мне понравилось.
С серверной не работал, но есть что-то вот такое: http://php.net/manual/ru/class.soapserver.php
http://pastebin.com/xkGNT9wn
Все что я нагуглил. Это какой то херовенький онлан генератор, класс который еще надо проверить и IntelliJ IDEA чего то умеет надо проверить умеет ли тоже phpstrom