8/25/2023 0 Comments Vim git blame![]() 7 habits of effective text editing: a short guide on getting better at editing by the Vim author.usevim: a vim blog with some great outbound links.Patrick Schanen's Vim Page: an index of vim resources more complete than this list.vi.: questions and answers stackexchange style.: the most popular vim wiki, lots of great content.Vim Mac Mailing List: low volume mac specific list.Vim Dev Mailing List: high volume dev list.Vim Use Mailing List: high volume user support list.Vim Announcements Mailing List: low volume announcement list.Our Wiki!: Let me know if you want to be a contributor.#vim on freenode: 1000+ person reasonably active IRC channel.Vim user manual (PDF): 341 pages (extracted from full help linked below).The command read from the standard input for the file contents. Replace this author name with " External file (-contents)" to better differentiate such lines from actual working copy lines.Īnnotate using the contents from the named file, starting from ![]() This is slightly confusing since this data isn't the working copy and while it is technically "not committed yet", its also coming from an external file. This is similar to the way blame handles working tree contents when blaming without a revision. When the -contents option is used with git blame ( man), and the contents of the file have lines which can't be annotated by the history being blamed, the user will see an author of "Not Committed Yet". (Merged by Junio C Hamano - gitster - in commit cf85f4b, ) blame: use different author name for fake commit generated by -contents See commit 603d0fd () by Jacob Keller ( jacob-keller). Still with Git 2.41 (Q2 2023), the output given by " git blame" ( man) that attributes a line to contents taken from the file specified by the -contents option shows it differently from a line attributed to the working tree file. Specify ' -' to make the command read from the standard Pretend the file being annotated has a commit with theĬontents from the named file and a parent of ,ĭefaulting to HEAD when no is specified. This makes the -contents option significantly more flexible, as it is no longer required to check out the working tree to the desired commit before using -contents.īlame-options now includes in its man page: This enables use of -contents with an arbitrary revision, rather than forcing the use of the local HEAD commit. Generating such a commit in that case would combine the currently checked out file contents with the provided revision, which breaks normal blame behavior and produces unexpected results. Note that the behavior of generating a fake working commit is still skipped when a revision is provided but -contents is not provided. Remove the check to disallow -contents and a final revision. Then, always generate a fake commit when we have contents provided, even if we have a final object. ![]() This is because the blame process generates a fake working tree commit which always uses the HEAD object as its sole parent.Įnhance fake_working_tree_commit to take the object ID to use for the parent instead of always using the HEAD object. If you try to pass a revision while using -contents, you get the following error: fatal: cannot use -contents with final commit object name The -contents option always blames the file as if it was based on the current HEAD commit. This option has been supported since 1cfe773 ( git-blame: no rev means start from the working tree file.,, Git v1.5.0-rc4 - merge) (" git-blame: no rev means start from the working tree file.") This is akin to copying the contents into the working tree and then running git blame. The -contents option can be used with git blame ( man) to blame the file as if it had the contents from the specified file. (Merged by Junio C Hamano - gitster - in commit 62df03c, ) blame: allow -contents to work with non-HEAD commit See commit 1a3119e () by Jacob Keller ( jacob-keller). Keeping such parent blobs in memory seems like a reasonable optimization that should incur additional memory pressure mostly when processing the merges from old branches.īefore Git 2.41 (Q2 2023), " git blame -contents= -``" ( man) used to be forbidden, but now it finds the origins of lines starting at contents through the history that leads to. When a parent blob already has chunks queued up for blaming, dropping the blob at the end of one blame step will cause it to get reloaded right away, doubling the amount of I/O and unpacking when processing a linear history. (Merged by Junio C Hamano - gitster - in commit 4d8c4da, ) blame.c: don't drop origin blobs as eagerly See commit f892014 () by David Kastrup ( fedelibre). with Git 2.22 (Q2 2019), will do so faster, because of a performance fix around " git blame", especially in a linear history (which is the norm we should optimize for). The git blame command annotates lines with information from the revision which last modified the line, and.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |