Исправление torvn77, (текущая версия) :
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
Можешь даже свой транспорт положить в /usr/l…
И если kernel.org в этот транспорт не умеет то что будет?
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо»
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах ip, apt или btrfs и я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.
Вместо неё стоит реализовать
git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1)
То есть ты предлагаешь сделать отдельную команду distributed_search_client работу которой ты понял неправильно так как иначе вместо ошибочного | head -n1 использовал бы конвеер из кучи grep, в частности |grep kernel.org и наверное gawk на случай если попадётся адрес вида diadia_kiev.com/kernel.org/linux который вне сомненья будет удовлетворять твоему наивному запросу потому как kernel.org то в нём есть…
Это во первых, а во вторых как твоя утилита distributed_search_client обработает запрос вида
git search tag=kernel,linux,sources,src branch=brainfuck type=commit autor='Free Jone' include_txt='func brainfuck.extfs(devname) date_dia='2002.06.24.12:32-2016.12.xx.24:00'
Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту distributed_search_client особенно если искомый коммит есть удалён из kernel.org и остался только в личном экземпляре исходников Free Jone?
Писать письма не обязательно через SMTP
Если запихать все эти возможности в сам git, то это и будет огромным костылём.
Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений единой очень гибкой системы.
Исправление torvn77, :
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
Можешь даже свой транспорт положить в /usr/l…
И если kernel.org в этот транспорт не умеет то что будет?
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо»
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах ip, apt или btrfs и я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.
Вместо неё стоит реализовать
git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1)
То есть ты предлагаешь сделать отдельную команду distributed_search_client работу которой ты понял неправильно так как иначе вместо ошибочного | head -n1 использовал бы конвеер из кучи grep, в частности |grep kernel.org и наверное gawk на случай если попадётся адрес вида diadia_kiev.com/kernel.org/linux который вне сомненья будет удовлетворять твоему наивному запросу потому как kernel.org то в нём есть…
Это во первых, а во вторых как твоя утилита distributed_search_client обработает запрос вида
git search tag=kernel,linux,sources,src branch=brainfuck type=commit autor='Free Jone' include_txt='func brainfuck.extfs(devname) date_dia='2002.06.24.12:32-2016.12.xx.24:00'
Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту distributed_search_client особенно если искомый коммит есть удалён из kernel.org и остался только в личном экземпляре исходников Free Jone?
Писать письма не обязательно через SMTP
Если запихать все эти возможности в сам git, то это и будет огромным костылём.
Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений очень гибкой системы.
Исправление torvn77, :
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
Можешь даже свой транспорт положить в /usr/l…
И если kernel.org в этот транспорт не умеет то что будет?
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо»
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах ip, apt или btrfs и я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.
Вместо неё стоит реализовать
git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1)
То есть ты предлагаешь сделать отдельную команду distributed_search_client работу которой ты понял неправильно так как иначе вместо ошибочного | head -n1 использовал бы конвеер из кучи grep, в частности |grep kernel.org и наверное gawk на случай если попадётся адрес вида diadia_kiev.com/kernel.org/linux который вне сомненья будет удовлетворять твоему наивному запросу потому как kernel.org то в нём есть…
Это во первых, а во вторых как твоя утилита distributed_search_client обработает запрос вида
git search tag=kernel,linux,sources,src branch=brainfuck type=commit autor='Free Jone' include_txt='func brainfuck.extfs(devname) date_dia='2002.06.24.12:32-2016.12.xx.24:00'
Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту distributed_search_client?
Писать письма не обязательно через SMTP
Если запихать все эти возможности в сам git, то это и будет огромным костылём.
Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений очень гибкой системы.
Исправление torvn77, :
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
Можешь даже свой транспорт положить в /usr/l…
И если kernel.org в этот транспорт не умеет то что будет?
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо»
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах ip, apt или btrfs и я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.
Вместо неё стоит реализовать
git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1)
То есть ты предлагаешь сделать отдельную команду distributed_search_client работу которой ты понял неправильно так как иначе вместо ошибочного | head -n1 использовал бы конвеер из кучи grep, в частности |grep kernel.org и наверное gawk на случай если попадётся адрес вида diadia_kiev.com/kernel.org/linux который вне сомненья будет удовлетворять твоему наивному запросу потому как kernel.org то в нём есть…
Это во первых, а во вторых как твоя утилита distributed_search_client обработает запрос вида
git search tag=kernel,linux,sources,src branch=brainfuck type=commit autor=‘Free Jone’ include_txt=‘func brainfuck.extfs(devname) date_dia=‘2002.06.24.12:32-2016.12.xx.24:00’’
Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту distributed_search_client?
Писать письма не обязательно через SMTP
Если запихать все эти возможности в сам git, то это и будет огромным костылём.
Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений очень гибкой системы.
Исходная версия torvn77, :
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
Можешь даже свой транспорт положить в /usr/l…
И если kernel.org в этот транспорт не умеет то что будет?
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо»
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах ip, apt или btrfs и я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.
Вместо неё стоит реализовать
git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1)
То есть ты предлагаешь сделать отдельную команду distributed_search_client работу которой ты понял неправильно так как иначе вместо ошибочного | head -n1 использовал бы конвеер из кучи grep, в частности |grep kernel.org и наверное gawk на случай если попадётся адрес вида diadia_kiev.com/kernel.org/linux который вне сомненья будет удовлетворять твоему наивному запросу потому как kernel.org то в нём есть…
Это во первых, а во вторых как твоя утилита distributed_search_client обработает запрос вида
git search tag=kernel,linux,sources,src branch=brainfuck type=commit autor=‘Free Jone’ include_txt=‘func brainfuck.extfs(devname)’
Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту distributed_search_client?
Писать письма не обязательно через SMTP
Если запихать все эти возможности в сам git, то это и будет огромным костылём.
Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений очень гибкой системы.