如何查看"git stash -u"的未跟踪文件; [英] how to view untracked files that were "git stash -u"

查看:467
本文介绍了如何查看"git stash -u"的未跟踪文件;的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

将内容存储在git中非常有用. 存放取消跟踪的文件并像这样进行存放时

Stashing content in git is very useful. when stashing untrack files and going through your stash like this

echo test > foo
git stash -u # foo is stashed
git stash show -p stash@{0}

未跟踪的文件不会显示. 我们怎么看到他们?

untracked files are not shown. how can we see them?

谢谢

推荐答案

您只需要查看第三个隐藏提交即可.但是只是需要"稍微低估了事情,直到您知道三个隐藏提交之前,这才有意义.要了解我的意思,请继续阅读.

You just need to look at the third stash commit. But "just need to" understates things a little bit, and this makes no sense until you know what the three stash commits are. To see what I mean, read on.

当您运行git stash savegit stash push时,Git的正常操作是创建两个提交,这两个提交都不在任何分支上.如果您像这样绘制之前"的图片,则将具有以下一系列提交:

When you run git stash save or git stash push, Git's normal action is to create two commits, neither of which are on any branch. If you draw the "before" picture like this, you would have this series of commits:

...--o--o--*   <-- branch (HEAD)

git stash save完成后,您有两个 new 提交,它们不在分支branch上,也不在任何其他分支上:

After git stash save completes, you have two new commits that are not on branch branch and not on any other branch either:

...--o--o--*   <-- branch (HEAD)
           |\
           i-w   <-- the stash

w提交保存工作树状态,而i提交保存索引.这两个提交中的每一个都非常类似于其他任何提交,实际上,i提交是使用大多数常规git commit机制进行的:Git将当前索引写入内部的 tree 使用git write-tree的对象,然后使用git commit-tree创建 commit 对象.如果您不知道这些内部对象是什么,则不必为此担心太多:重点在于,这也是git commit通过编写树然后提交对象来完成其大部分工作的方式. (git commit的其余部分包括首先收集您的日志消息,然后在最后更新分支名称.)

The w commit saves the work-tree state while the i commit saves the index. Each of these two commits is very much like any other commit, and in fact, the i commit is made using most of the normal git commit mechanism: Git writes the current index to an internal tree object using git write-tree, then makes a commit object using git commit-tree. If you don't know what these internal objects are, don't worry too much about that: the point is that this is also how git commit does most of its job, by writing a tree and then a commit object. (The rest of git commit consists of collecting your log message first, and updating the branch name at the end.)

w提交稍微复杂一点,因为它具有 merge 提交的 form (但没有意图),但有两个父级而不是一个父级.但基本上,它会保存工作树的快照,就像您对所有跟踪的文件运行了git add一样.

The w commit is a little more complicated because it has the form (but not intent) of a merge commit, with two parents instead of one. But basically it saves a snapshot of the work-tree, as if you had run git add on all your tracked files.

当您添加--all--include-untracked(简称为-a-u)时,git stash所做的是添加一个 third 提交,我们可以绘制此提交方式:

When you add --all or --include-untracked (-a or -u for short), what git stash does is that it adds a third commit, which we can draw this way:

...--o--o--*   <-- branch (HEAD)
           |\
           i-w   <-- the stash
            /
           u

第三次提交是快照,但这是一个非常奇怪的快照.它只包含未跟踪文件 -未跟踪但未被忽略的文件(git stash save -u),或未跟踪文件包括未被跟踪和忽略的文件( git stash save -a).它还没有 parent 提交.

The third commit is a snapshot, but it is a very odd snapshot. It contains only the untracked files—either the untracked-but-not-ignored files (git stash save -u), or the untracked files including the untracked-and-ignored files (git stash save -a). It also has no parent commit.

Git加上push动词的原因 1 ,如git stash push所示(否则它基本上是save的代名词),是当您创建新的存储时,Git会使用藏匿处 reflog 来跟踪较早的藏匿处.当前的存储量以引用日志形式显示为stash@{0},而较早的存储量变为stash@{1}.

One reason1 that Git added the push verb, as in git stash push—which is otherwise basically a synonym for save—is that when you make a new stash, Git uses the stash reflog to keep track of earlier stashes. The current stash is stash@{0} in reflog terms, and the earlier stash becomes stash@{1}.

这些名称中的每一个只是Git给您提供的更一般的东西的一个特例:您可以引用任何解析为正确的哈希ID的名称的任何提交.任何提交的真实名称"都是其庞大的丑陋哈希ID. gitrevisions文档全面描述了所有方式您可以将哈希ID拼写到Git;使用branchstash之类的名称就是这种方法之一.

Each of these names is just a specific case of a more general thing that Git gives you: you can refer to any commit by any name that resolves to the correct hash ID. The "true name" of any commit is its big ugly hash ID. The gitrevisions documentation has the complete description of all the ways you can spell a hash ID to Git; using a name like branch or stash is one such way.

使用名称stash专门定位提交w.然后,Git使用w本身查找提交i,如果存在,则提交u. Git之所以可以这样做是因为每个提交都包含其 parent 提交的哈希ID.使w具有合并提交形式的原因在于,它至少有两个父级:i(索引提交)和*(运行git stash savegit stash push时坐在的提交)首先.

Using the name stash locates commit w specifically. Git then uses w itself to find commit i, and, if it exists, commit u. Git can do this because each commit includes the hash IDs of its parent commits. What makes w have the form of a merge commit is that it has at least two parents: i, the index commit, and *, the commit you were sitting on when you ran git stash save or git stash push in the first place.

我们可以通过添加尖号^字符和一个数字以专门查看带编号的父级来修改大多数修订说明符(如stash).编写stash^1是命名提交*的一种方式.编写stash^2是命名提交i的一种方式.如果提交u存在,则编写stash^3对其进行命名.请注意,在某些系统(Windows)上,^可能是一个特殊字符,需要加倍或加引号,因此您可能需要stash^^3来代替stash^3.

We can modify most revision specifiers (like stash) by adding a caret ^ character and a number to look specifically at the numbered parent. Writing stash^1 is a way of naming commit *; writing stash^2 is a way of naming commit i. If commit u exists, writing stash^3 names it. Note that on some systems (Windows), ^ may be a special character that requires doubling or quoting, so instead of stash^3 you might need stash^^3.

1 另一个原因是增加了使用pathspecs进行部分隐藏的能力:git stash save将任何额外的参数作为消息包含在隐藏提交中,因此他们需要一个新的动词来使用-m指定消息,为pathspec参数留出空间.

1The other reason was to add the ability to do partial stashing using pathspecs: git stash save took any extra arguments as a message to include in the stash commits, so they needed a new verb that used -m to specify the message, leaving room for pathspec arguments.

我们可以使用git show查看任何提交.对于隐藏w提交,这会失败,因为Git认为w提交是合并,因此我们可以改用git stash show. (这是 的合并,但不是git show可以正确显示的一个.)我的相关问题要求在u提交上使用git diff,因为在这种情况下,我们不想获取git show显示的标题,但是如果我们只想查看未跟踪的标题文件提交,可以在此处使用git show

We can view any commit using git show. For stash w commits this misfires because Git thinks that the w commit is a merge, so we can use git stash show instead. (It is a merge, just not one that git show can show properly.) My earlier answer to a related question calls for using git diff on the u commit, because in that particular case, we don't want to get the header that git show shows, but if we just want to look at the untracked file commit, it's OK to use git show here:

git show stash^3

例如

.以下是上述foo示例的输出:

$ git show stash^3
commit 4c9bd2486706980f5a492d19c49270381db2d796
Author: Chris Torek <chris.torek gmail.com>
Date:   Sun Sep 16 12:35:03 2018 -0700

    untracked files on master: f72737e initial

diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo

使用类似stash@{1}的名称标识reflog条目#1中的提交,这是存储堆栈"中的下一个存储. (引用日志从零开始计数,因此stashstash@{0}表示相同的提交.)因此,对于stash@{1},您将需要stash@{1}^3stash@{1}^^3.

Using a name like stash@{1} identifies the commit in reflog entry #1, which is the next stash in your "stash stack". (The reflog starts counting from zero, so stash and stash@{0} mean the same commit.) So for stash@{1} you would need stash@{1}^3 or perhaps stash@{1}^^3.

这篇关于如何查看"git stash -u"的未跟踪文件;的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆