IT story

“git fetch --tags”에“git fetch”가 포함됩니까?

hot-time 2020. 4. 4. 11:02
반응형

“git fetch --tags”에“git fetch”가 포함됩니까?


훌륭하고 간단한 질문- "git fetch"의 기능은 git fetch --tags?

즉, 내가 달리면 바로 후에 git fetch --tags바로 달리는 이유가 git fetch있습니까?

무엇에 대한 git pull그리고 git pull --tags? 같은 상황?


참고 : git 1.9 / 2.0 (Q1 2014) 부터 옵션없이 동일한 명령 줄에서 가져온 git fetch --tags태그 외에 태그 가져옵니다 .

참조 c5a84e9 커밋 에 의해 마이클 Haggerty (mhagger) :

이전에는 페치의 " --tags"옵션이 참조 스펙을 지정하는 것과 동등한 것으로 간주되었습니다

refs/tags/*:refs/tags/*

명령 행에서; 특히 remote.<name>.refspec구성이 무시되었습니다.

그러나 다른 참조도 페치하지 않고 태그를 페치하는 것은 그리 유용하지 않지만 다른 참조 와 함께 태그를 페치 할 수 있으면 매우 유용합니다 . 따라서이 옵션의 의미를 변경하여 후자를 수행하십시오.

사용자가 태그 가져 오려면 명시 적 참조 사양을 지정할 수 있습니다.

git fetch <remote> 'refs/tags/*:refs/tags/*'

1.8.0.3 이전의 문서는 " fetch --tags"동작 의 이러한 측면에 대해 모호했습니다 .
커밋 f0cb2f1 (2012-12-14) fetch --tags은 문서가 이전 동작과 일치하도록했습니다.
이 커밋은 새로운 동작과 일치하도록 문서를 변경합니다 (참조 Documentation/fetch-options.txt).

페치중인 태그 외에 모든 태그를 리모트 에서 페치하도록 요청하십시오 .


Git 2.5 (2015 년 2 분기) 이후 git pull --tags더 강력합니다.

참조 19d122b 커밋 에 의해 폴 탄 ( pyokagan) 5 월 13 일 2015 년
(에 의해 합병 Junio C 하마노 - gitster-cc77b99을 투입 , 2015 (22) 5 월)

pull: --tags병합 후보가없는 경우 오류 제거

441ed41 이후 ( " git pull --tags": 더 나은 메시지로 오류가 발생했습니다. 2007-12-28, Git 1.5.4+) 병합 후보를 반환하지 않으면 git pull --tags다른 오류 메시지가 인쇄됩니다 git-fetch.

It doesn't make sense to pull all tags; you probably meant:
       git fetch --tags

그 당시에 git-fetch --tags는 구성된 참조 사양을 재정의하므로 병합 후보가 없기 때문입니다. 따라서 혼란을 방지하기 위해 오류 메시지가 도입되었습니다.

그러나 이후 c5a84e9 ( fetch --tags: 태그 가져올 뿐만 아니라 , 다른 재료, 2013년 10월 30일, 힘내 1.9.0+) git fetch --tags모든 구성 refspecs에 추가로 태그를 가져올 것입니다.
따라서, 병합 후보 상황이 발생하지 않은 경우에는 --tags설정 되었기 때문이 아닙니다 . 따라서이 특수 오류 메시지는 이제 관련이 없습니다.

혼동을 피하려면이 오류 메시지를 제거하십시오.


Git 2.11+ (2016 년 4 분기)를 사용 git fetch하면 더 빠릅니다.

Jeff King ( )의 commit 5827a03 (2016 년 10 월 13 일)을 참조하십시오 . ( Junio ​​C Hamano의해 합병 -- 커밋 9fcd144 , 2016 년 10 월 26 일)peff
gitster

fetch: has_sha1_file태그 추적에 "빠른"사용

우리가 따르고있는 브랜치와 관련이없는 많은 태그가있는 리모콘에서 가져올 때 우리는 태그에 의해 지정된 객체 (페치하지 않을 것입니다!)가 저장소에 있는지 확인할 때 너무 많은 사이클을 낭비했습니다. 너무 조심스럽게

이 패치는 fetch가 HAS_SHA1_QUICK를 사용하여 동시 재 포장으로 인해 정확성이 떨어지는 경우 속도의 정확도를 희생하도록 지시합니다.

포함 된 perf 스크립트의 결과는 위에서 설명한 것과 유사한 상황을 설정합니다.

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

이는 다음과 같은 상황에만 적용됩니다.

  1. 클라이언트 측에는 많은 비용을 들이기 위해 많은 팩이 있습니다 reprepare_packed_git()(가장 비싼 부분은 정렬되지 않은 목록에서 현재 2 차인 중복 항목을 찾는 것입니다).
  2. 자동 추적을 수행 할 수있는 (즉, 클라이언트에없는) 서버 측에는 많은 태그 참조가 필요합니다. 각각은 팩 디렉토리를 다시 읽습니다.
  3. 정상적인 상황에서 클라이언트는 해당 태그를 자동으로 따르고 한 번의 큰 페치 후에는 (2) 더 이상 사실이 아닙니다.
    그러나 해당 태그가 히스토리를 가리키면 클라이언트가 가져 오는 것과 연결이 끊어지면 자동으로 팔로우되지 않으며 해당 후보는 모든 페치에 영향을 미칩니다.

Git 2.21 (2019 년 2 월)은 구성 remote.origin.fetch기본 구성 아닌 경우 회귀를 도입 한 것으로 보입니다 ( '+refs/heads/*:refs/remotes/origin/*')

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

참고 :이 답변은 git v1.8 이상에서만 유효합니다.

이것의 대부분은 다른 답변과 의견에서 언급되었지만 간결한 설명이 있습니다.

  • git fetch모든 브랜치 헤드 (또는 remote.fetch config 옵션에 의해 지정된 모든), 그에 필요한 모든 커밋 및이 브랜치에서 도달 할 수있는 모든 태그를 가져옵니다. 대부분의 경우 이러한 방식으로 모든 태그에 도달 할 수 있습니다.
  • git fetch --tags모든 태그, 필요한 모든 커밋을 가져옵니다. 그것은 것입니다 하지 그들이 가져온했다 태그에서 연결할 경우에도 브랜치 헤드를 업데이트합니다.

요약 : 페치 만 사용하여 완전히 최신 상태를 유지하려면 둘 다 수행해야합니다.

명령 줄에 입력하는 것을 의미하지 않는 한 "두 번 느리게"되지 않습니다.이 경우 별칭이 문제를 해결합니다. 서로 다른 정보를 요구하기 때문에 두 요청을 작성하는 데 본질적으로 오버 헤드가 없습니다.


나는 이것에 스스로 대답 할 것이다.

차이가 있다고 판단했습니다. "git fetch --tags"는 모든 태그를 가져올 수 있지만 새로운 커밋은 가져 오지 않습니다!

완전히 "최신"상태가 되려면, 즉 병합없이 "git pull"을 복제해야합니다.

$ git fetch --tags
$ git fetch

두 배나 느리기 때문에 부끄러운 일입니다. "git fetch"만이 정상적으로 수행하는 옵션이 있고 모든 태그를 가져옵니다.


여기서 일반적인 문제 git fetch는 fetch +refs/heads/*:refs/remotes/$remote/*입니다. 이러한 커밋에 태그가 있으면 해당 태그도 가져옵니다. 그러나 원격의 어떤 분기에서도 도달 할 수없는 태그가 있으면 가져 오지 않습니다.

--tags옵션은 참조 스펙을로 전환합니다 +refs/tags/*:refs/tags/*. 당신은 할 수 요청 git fetch을 모두 잡아. 나는 단지 어떻게 확신 git fetch && git fetch -t다음 명령을 사용하십시오 :

git fetch origin "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*"

그리고 이것을이 저장소의 기본값으로 설정하려면 기본 가져 오기에 두 번째 참조 스펙을 추가 할 수 있습니다.

git config --local --add remote.origin.fetch "+refs/tags/*:refs/tags/*"

리모컨 fetch =두 번째 이 추가됩니다 .git/config.


나는 프로젝트를 위해 이것을 처리하는 방법을 찾는 데 시간을 보냈습니다. 이것이 내가 생각해 낸 것입니다.

git fetch -fup origin "+refs/*:refs/*"

제 경우에는 이러한 기능을 원했습니다

  • 리모컨에서 모든 헤드와 태그를 잡고 Refspec을 사용하십시오. refs/*:refs/*
  • 참조 +스펙 이전에 로컬 분기 및 태그를 빨리 감기로 덮어 쓰기
  • 필요한 경우 현재 체크 아웃 한 분기 덮어 쓰기 -u
  • 원격에없는 브랜치 및 태그 삭제 -p
  • 그리고 강제로 -f

대부분의 경우 git fetch원하는 작업을 수행해야합니다. 즉, '원격 저장소에서 새로운 것을 가져 와서 로컬 지점에 병합하지 않고 로컬 사본에 넣습니다'입니다. git fetch --tags새로운 태그 이외의 것을 얻지 못한다는 점을 제외하고는 정확히 그렇게합니다.

그런 의미 git fetch --tags에서 결코의 슈퍼 세트가 아닙니다 git fetch. 실제로는 정반대입니다.

git pull물론,에 대한 래퍼 일뿐입니다 git fetch <thisrefspec>; git merge. 처음에 무엇을하고 있는지 이해하는 데 도움이되기 때문에 단순히 점프하기 전에 수동 git fetching과 git mergeing에 익숙해지는 것이 좋습니다 .git pullgit pull

즉, 관계는와 정확히 동일합니다 git fetch. git pull의 슈퍼 세트입니다 git pull --tags.


git fetch upstream --tags

제대로 작동하면 새 태그 만 가져오고 다른 코드베이스는 얻지 않습니다.

참고 URL : https://stackoverflow.com/questions/1204190/does-git-fetch-tags-include-git-fetch

반응형