2

git-rev-list man ページには、次のコマンドが表示されます。

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

ただし、最初のコマンドを実行すると、次のエラーが発生します。

$ git rev-list origin..HEAD fatal: ambiguous argument 'origin..HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

「origin」は、次のリモートを指します。

$ git remote -v
origin  c:/hands_on/git/learn/clone/../repo_1 (fetch)
origin  c:/hands_on/git/learn/clone/../repo_1 (push)

コマンドの使い方が間違っていませんか? また、rev-list コマンドはコミットを入力として受け取ると思っていたので、man ページでリモートである「origin」が使用されている理由がわかりません。私は何を誤解しましたか？

4

2 に答える 2

3

git-rev-parse(1) は、リモートの名前を参照として使用する方法を説明しています:

<refname>, e.g. master, heads/master, refs/heads/master
   A symbolic ref name. E.g.  master typically means the commit object
   referenced by refs/heads/master. If you happen to have both heads/master and
   tags/master, you can explicitly say heads/master to tell Git which one you
   mean. When ambiguous, a <refname> is disambiguated by taking the first match
   in the following rules:

    1. If $GIT_DIR/<refname> exists, that is what you mean (this is usually
    useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and
    CHERRY_PICK_HEAD);

    2. otherwise, refs/<refname> if it exists;

    3. otherwise, refs/tags/<refname> if it exists;

    4. otherwise, refs/heads/<refname> if it exists;

    5. otherwise, refs/remotes/<refname> if it exists;

    6. otherwise, refs/remotes/<refname>/HEAD if it exists.

そして git-remote(1)refs/remotes/<remote>/HEADは、 の説明の内容を説明していますgit remote set-head:

   set-head
       Sets or deletes the default branch (i.e. the target of the symbolic-ref
       refs/remotes/<name>/HEAD) for the named remote. Having a default branch
       for a remote is not required, but allows the name of the remote to be
       specified in lieu of a specific branch. For example, if the default
       branch for origin is set to master, then origin may be specified wherever
       you would normally specify origin/master.

つまり、リモートのデフォルト ブランチを使用していて、それを持っていないように見えます。

于 2015-09-20T22:11:42.793 に答える
2

あなたが正しく言っgit rev-listたように、そこでコミット範囲を取ることになっているので、リモートの名前を使用しても意味がありません。

以前のドキュメント（2006年より前、非常に昔）には、次のように記載されていました。

の省略形として、特別な表記法<commit1>..<commit2>を使用できます^<commit1> <commit2>。

これは、このコミット(メーリング リストのディスカッション)で次のように変更されました。

の省略形として、特別な表記法"'<commit1>'..'<commit2>'"を使用できます"^'<commit1>' '<commit2>'"。たとえば、次のいずれかを同じ意味で使用できます。

$ git-rev-list origin..HEAD
$ git-rev-list HEAD ^origin

その変更のコミット メッセージは次のとおりです。

git-rev-list(1): グループオプション; 再フォーマット; より多くのオプションを文書化する

originthere の使用は間違いであり、文字通りリモートを参照することを意図したものではないと推測できます。ドキュメントには一貫性のない例 ( rev-listfoo/bar/baz、origin/HEAD、および A/B のみを使用) がぎっしり詰まっているため、あまり重視しません。

ただし、重要な部分は、コマンドがブランチ (または一般的な参照) で動作することになっており、リモートはそれ自体では有効な参照ではないということです。

于 2015-09-20T17:18:56.680 に答える