問題タブ [git-describe]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
36876 参照

git - 「gitdescribe」はタグを無視します

次の行で:

「gitdescribe」でv2.0タグが使用されない理由と、これを修正する方法を誰かが説明できますか?v2.0タグはすでにプッシュされているので、削除して再度追加することはできないと思います。

0 投票する
2 に答える
3774 参照

git - マージをマスターに開発し、タグ付け後に元に戻す必要がありますか?

問題は、マージしてタグ付けした後、正しいバージョン(で表示git describe)をどのように達成するかです。developmastermaster?

私は一般的なgitブランチを使用しています-master本番用です。ショーとマージした後、git describeショーが1.5オンになっているとしましょう。 そこで、で新しい注釈付きタグを作成すると、が表示されます。master,develop, master1.5-234-g1e894af
git tag -a 1.6git describe master1.6

しかし:git describe developそれでも表示されます1.5-somethingが、これは私にとっては奇妙なことです-それはと同じコミットを持っています-なぜGitはそれがまだバージョンmasterに属していると考えるのですか?1.5

私の頭の中にはこれ以上良いものはないので、マスターを開発にマージします。その後、開発1.6-2-...は許容できるバージョンを示しますが、もう1つの役に立たないマージコミットを生成し、「再帰によって作成されたマージ」について警告します。これも意味がないと思います。しかし、正しいバージョンを達成する方法は?

0 投票する
7 に答える
40876 参照

git - 複製せずにリモート リポジトリから最後の git タグを取得する

(チェックアウトされていない) リモートリポジトリから最後のタグを取得する方法は?

私が使用するローカルコピーでdescribe

しかしdescribe、リモートストレージでは使用できません

0 投票する
2 に答える
1111 参照

git - 「gitdescribe」の出力からコードをチェックアウトするGIT

git describe自動化されたバージョン番号を生成するために使用することを考えています。ここで提案するように。

私の質問は、git describeasのo / pを取得した場合v2.0-64-g835c907、将来gitを使用してその特定のリビジョン番号をチェックアウトするにはどうすればよいですか?

0 投票する
1 に答える
1691 参照

git - Gitはさまざまなタグを付けることを説明しています

リポジトリに「Release_V1.0.0.4」というタグを付けました。しかし、これが「gitdescribe」と「gitdescribeorigin」から得たものです。

[root pds_series]#git describe

Release_V1.0.0.2-22-g0859de9

[root pds_series]#git describe origin

Release_V1.0.0.2-18-gce2b24c

「gitdescribe--all」と「gitdescribe--tags」を使用して、適切なタグを取得しました。

[root pds_series]#git describe --all

tags / Release_v1.0.0.4

[root pds_series]#git describe --tags

Release_v1.0.0.4

また、次のコマンドで正しいタグを取得しました。

[root pds_series]#git log --pretty = format:'%ad%h%d' --abbrev-commit --date = short -1

2012-11-15 0859de9(HEAD、Release_v1.0.0.4、マスター)

誰かがこれの背後にある理由を知っていますか?この問題を解決するにはどうすればよいですか?

0 投票する
3 に答える
14354 参照

git - クリーン チェックアウトを説明するときに「git describe -dirty」が「-dirty」サフィックスを追加するのはなぜですか?

--dirtyオプションを発見したばかりでgit describe、非常に便利なことを行う必要があるように見えます。つまりgit describe、作業ツリーがダーティな場合の出力にサフィックスを追加しますが、私のリポジトリの一部ではそうではないようです:

これは、作業ディレクトリがtag に対して相対的に汚れているためではないかと考えましたが、そうではないようです:

Mercurialを使っhg idていたときはよく使っていましたが、デフォルトの動作は、ダーティ リポジトリに対して報告されたコミット ハッシュにサフィックスを追加するという事実が気に入っていたので、それ以来、同等のものを探していましたが、そうではありませんでした。ドキュメントを考えると、私が期待することをしているように見えます:+gitgit describe --dirty

--dirtyをすべきか誤解していますか、それとも正しく使用していませんか?

違いが生じた場合に備えて、すべての git リポジトリはバックミンスター経由でデプロイされるため、関連するサブモジュールはなく、ファイルシステムはnfs共有です。


更新:回避策を発見しましたが、これがどのように違いを生んでいるのかまったくわかりません。

レポで実行するgit diff --quiet HEADと、突然、git describe期待どおりに動作します。

また、リポジトリをgit describe報告しているときに、 「ローカルのコミットされていない変更、インデックスにチェックインされていません」も表示され、作業ディレクトリに各ファイルがリストされていることを発見しましたが、それらに対する差分はなく、行だけです。dirtygitk---- filename ----


さらなる更新:これは引き続き問題であるため、最終的にgit-describe-dirtyスクリプトを作成しました。これは、実行することから始まりgit describe --dirtyますが、リポジトリが汚れていることが判明した場合は、git update-index -q --refresh再試行して 2 番目の結果を取得する前に実行されます。

何百ものリポジトリを反復処理する場合git describe-dirty、リポジトリがダーティであることを最初に示すリポジトリのインデックス更新のみを使用して実行すると、git update-index -q --refresh ; git describe --dirty毎回実行する場合に比べて大幅に時間を節約できます。

0 投票する
3 に答える
943 参照

git-tag - 特定のタグに関連する git バージョン

リポジトリで複数のタグ識別子を使用しています。例えば。ABC-1.3.5.234 および DEF-1.2.1.25。describe コマンドは、私が望むほとんどのものを提供します。

git describe --long

ABC-1.3.5.234-33-デッドビーフ

しかし、私の履歴の最新の DEF タグと比較した値を知りたかったのです。相対距離を計算するためのベースとして使用するタグを指定する方法はありますか? 正規表現でそれを行うことはできますか?

0 投票する
1 に答える
298 参照

git - git describe の出力でログを取得する方法

git describe問題が発生した場合に、どのリビジョンで問題が発生したかを簡単に追跡できるように、自分のプログラムでの出力を使用したいと考えています。

出力は次のようになります。v2.12-20-g22290d9

checkout簡単にできることはわかっていますが、git logまたは同様のツールを使用してログを追跡するにはどうすればよいですか?

0 投票する
1 に答える
612 参照

git - git describe:不可解なコミット数

次の抜粋を考えてみましょうgit log --oneline --decorate --graph:

(注: タグ v0.8.4 はブランチ 'develop' からのコミットにあります)

実行すると、どうしてgit describeこれが得られるのですか:

つまり、git はタグ v0.8.4 以降のコミットを 16 回カウントします。私はそれが戻ってくることを期待していv0.8.4-1-g552485aます。

具体的には ( --debug オプションを使用する場合):

興味深いことに、開発ブランチに切り替えると:

git describe期待どおりに戻ります: v0.8.4-1-g0992f78

背景: SmartGit とその Git-Flow 機能を使用しています。

関連するコミットのグラフィカル ビューを次に示します (赤: マスター、青: 開発):

ここに画像の説明を入力

0 投票する
0 に答える
548 参照

git - git-describe がコミットをカウントする方法を変更できますか?

私の質問はgit describe: inexplicable commit count and commit count Calculation in git-describeに関連していますが、どちらの質問ともまったく同じではありません。私は現在のプロジェクトの機能ブランチで開発を行っており、機能ブランチのgit describeバージョン番号を取得するために使用しており、最近のタグとコミット数を使用して、単調に増加すると思われるバージョン番号を作成しています。(たとえば、私のブランチは現在 v1.1.0 よりも 96 コミット進んでいるためv1.1.0-96-g1234567、ユーザーに報告するバージョンでは「バージョン 1.1.0.96」になっています。)

現在、マスター ブランチは最近 v1.2.0 でタグ付けされました。バージョン 1.2 で行われた変更を機能ブランチに組み込みたいと考えています。そこで、master をフィーチャー ブランチにマージしましgit describev1.2.0-1-g9876543。しかし、代わりに、私はを得v1.2.0-97-g9876543ました。

なぜこれが起こっているのか理解しています.Gitマニュアルに記載されているように、コミット数を生成するために生成git describeされgit log v1.2.0..9876543たコミットをカウントしています(97、私のブランチには96のコミットと1つのマージコミットがあったため)。しかし、私が本当に望んでいるのは、git log --ancestry-path v1.2.0..9876543代わりにの結果を使用することです。これはマージコミットのみを示しているため、v1.2.0-1-g9876543期待していた結果が得られます。

の代わりにgit describe使用するように の動作を変更する方法はありますか?git log --ancestry-path v1.2.0..9876543git log v1.2.0..9876543

そして、さらに重要なことは、現在の方法でそれを行うことの利点は何git describeですか? 期待していたバージョン番号付けスキームを生成する独自のツールを作成すると、何を失うのでしょうか?

ところで。ここに git リポジトリの履歴のスナップショットがあるので、今説明した内容を視覚的に確認できます。ブランチはfeature/cmdline私が取り組んでいるものです。(この履歴ビューは、WindowsのGit 拡張ツールからのものです。念のために説明しておきます。)

私の機能ブランチの簡単なスナップショット