人間が読める/同等のgit変更ID

バージョン管理システムの中には、PERFORCEなどのCLを単純な整数として保持しているため、同じブランチ上で2つの異なるCLを調べると、どのCLが最初にマージされたかを容易に理解できます。しかし、Gitの場合、CL/short CLは長い16進数文字列であり、人間の目でも簡単には比較できません。この問題を解決する方法はありますか？人間が読める/同等のgit変更ID

出典

2017-02-13 Sazzad Hissain Khan

これは、Gitのすべてのコミットに_message_が関連付けられており、おそらくタグも同様の理由からです。 –

誰かがなぜ投票したのか分からない。 –

それは価値があるのは私ではありませんでした。 –

私は恐れていません。システムの分散された性質は単調に増加する "リビジョン番号"を排除します。あなたと地球の反対側の他の誰かがバージョンnとなり、誰がn+1であるかを正確に同時に（修正しないで）パッチをコミットすることに決めたら？この種の同期は、リビジョン番号を割り当てることができる単一の中央サーバーがある場合にのみ可能です。それは分配されるために支払うべき価格です。

しかし、技術的な解決策はありませんが、社会的解決策があります。良いブランチ名、適切なタグ付けは、プロジェクトで何が起こっているのかを理解するのに役立ちます。 git branch --mergedおよび--no-mergedは、どのブランチがマージされ、どのブランチがマージされないかについての詳細を示します。

出典

2017-02-13 05:19:54

（これは正解であり、upvotedです）。タグを使うときには、 'git describe'を使うこともできます。これはやや人間フレンドリーな数を計算し、 ' - -g 'という形式の出力を生成しようとします。これは ''からコミットの線形カウントへの近似値です。コメントに記述するのに余りにも多くのスペースを取る制限の下では、 ''の値は安定しています。 – torek

describe、branches、タグなどの出力は[treeish]と呼ばれるものの例です（http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git#18605496 ）歌う。 –

実際にそれらは「コミット」していますが、もちろん、ツリーが必要な場合は、コミットを識別するものはすべてツリーに解決されます。 'git show'のようないくつかのコマンドは、コミットにアクセスします。この場合、gitrevisionsの '^ {tree}'接尾辞を使用して、コミットIDを対応するツリーIDに強制的に変換することができます。 – torek

いいえ、gitのSHA-1ハッシュは40文字の文字列です。ファイルの内容に基づいて計算されます。 git olnyはSHA-1をデータベースに格納します。人間の目には見えない。

gitの履歴を確認する場合は、git log --oneline --decorate --graph --allは表示されません。

出典

2017-02-13 05:08:58

人間が読める/同等のgit変更ID

答えて

関連する問題