uTools-Manuals/docs/git/git check-attr.html

<div class="c-markdown doc-markdown"><div class="doc-postil"><div class="c-markdown"><h2>命名</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>git-check-attr  - 显示 gitattributes 信息</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>概要</h2></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">git check-attr [-a | --all | attr…] [--] pathname…

git check-attr --stdin [-z] [-a | --all | attr…]</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>There is already a project called BBChop created by Ealdwulf Wuffinga on Github that does something like that using Bayesian Search Theory [9]:</p></div></div><div class="doc-postil"><div class="c-markdown"><blockquote><p>BBChop is like <code>git bisect</code> (or equivalent), but works when your bug is intermittent. That is, it works in the presence of false negatives (when a version happens to work this time even though it contains the bug). It assumes that there are no false positives (in principle, the same approach would work, but adding it may be non-trivial).</p></blockquote></div></div><div class="doc-postil"><div class="c-markdown"><p>But BBChop is independent of any VCS and it would be easier for Git users to have something integrated in Git.</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>Conclusion</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>We have seen that regressions are an important problem, and that "git bisect" has nice features that complement very well practices and other tools, especially test suites, that are generally used to fight regressions. But it might be needed to change some work-flows and (bad) habits to get the most out of it.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Some improvements to the algorithms inside "git bisect" are possible and some new features could help in some cases, but overall "git bisect" works already very well, is used a lot, and is already very useful. To back up that last claim, let’s give the final word to Ingo Molnar when he was asked by the author how much time does he think "git bisect" saves him when he uses it:</p></div></div><div class="doc-postil"><div class="c-markdown"><blockquote><p>a <code>lot</code>.

 About ten years ago did i do my first <code>bisection</code> of a Linux patch queue. That was prior the Git (and even prior the BitKeeper) days. I literally days spent sorting out patches, creating what in essence were standalone commits that i guessed to be related to that bug.

 It was a tool of absolute last resort. I’d rather spend days looking at printk output than do a manual <code>patch bisection</code>.

 With Git bisect it’s a breeze: in the best case i can get a ~15 step kernel bisection done in 20-30 minutes, in an automated way. Even with manual help or when bisecting multiple, overlapping bugs, it’s rarely more than an hour.

 In fact it’s invaluable because there are bugs i would never even <code>try</code> to debug if it wasn’t for git bisect. In the past there were bug patterns that were immediately hopeless for me to debug - at best i could send the crash/bug signature to lkml and hope that someone else can think of something.

 And even if a bisection fails today it tells us something valuable about the bug: that it’s non-deterministic - timing or kernel image layout dependent.

 So git bisect is unconditional goodness - and feel free to quote that ;-)</p></blockquote></div></div><div class="doc-postil"><div class="c-markdown"><h2>Acknowledgments</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>Many thanks to Junio Hamano for his help in reviewing this paper, for reviewing the patches I sent to the Git mailing list, for discussing some ideas and helping me improve them, for improving "git bisect" a lot and for his awesome work in maintaining and developing Git.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Many thanks to Ingo Molnar for giving me very useful information that appears in this paper, for commenting on this paper, for his suggestions to improve "git bisect" and for evangelizing "git bisect" on the linux kernel mailing lists.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Many thanks to Linus Torvalds for inventing, developing and evangelizing "git bisect", Git and Linux.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Many thanks to the many other great people who helped one way or another when I worked on Git, especially to Andreas Ericsson, Johannes Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Many thanks to the Linux-Kongress program committee for choosing the author to given a talk and for publishing this paper.</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当该属性被定义为 true 时。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>&lt;value&gt;</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当一个值已经被赋值给该属性时。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>缓冲发生<code>GIT_FLUSH</code>在 git [1] 中的选项下。调用者负责避免溢出输入缓冲区或从空输出缓冲区读取引起的死锁。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>示例</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>在示例中，使用以下<code>.gitattributes</code>文件：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">*.java diff=java -crlf myAttr

NoMyAttr.java !myAttr

README caveat=unspecified</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>列出一个属性：$ git check-attr diff org/example/MyClass.java org/example/MyClass.java: diff: java</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>列出文件的多个属性：</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git check-attr crlf diff myAttr -- org/example/MyClass.java

org/example/MyClass.java: crlf: unset

org/example/MyClass.java: diff: java

org/example/MyClass.java: myAttr: set</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>列出文件的所有属性：$ git check-attr --all -- org/example/MyClass.java org/example/MyClass.java: diff: java org/example/MyClass.java: myAttr: set</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>列出多个文件的属性：</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java

org/example/MyClass.java: myAttr: setorg/example/NoMyAttr.java: myAttr: unspecified</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>并非所有的价值观都同样明确：</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git check-attr caveat README

README: caveat: unspecified</code></pre></div></div></div>