Re: What's in git.git (stable)
- From
David Kågedal <davidk@lysator.liu.se>
- Date
- Feb 4, 2007, 22:25 UTC
- Message-ID
- <87bqk9ftm5.fsf@morpheus.local>
- In-Reply-To
- <eq5jdt$173$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
Show 25 quoted lines
> Theodore Tso wrote: >> On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote: >>> On Sun, 4 Feb 2007, Jeff King wrote: >>>> >>>> Just a thought, but it might be useful to blame the contents of an >>>> arbitrary file (but starting the history at a given pathname). Something >>>> like "git blame --contents /tmp/foo.c file.c", with contents defaulting >>>> to "file.c". There's much discussion of editor interfaces, and this >>>> leaves the possibility of git-blaming the contents of the editor buffer >>>> (after writing it out to a temp file) without having to save changes to >>>> the working tree file. >>> >>> I agree, that probably would make most sense. If we do this at all. On the >>> other hand, I suspect that most editors would probably want to pipe the >>> contents to the program, not write it to a temp-file. >> >> ... and use it with --incremental, as well. In emacs you can have the >> annotation take place as it is being written out relatively easily, by >> arranging to have a callback function get called each time more >> information is handed back to emacs via a pipe. > > So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should > have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then > pipe current contents of the buffer to "git blame --stdin --incremental > file.c" (where file.c is the name in tree/in HEAD).
But if we allow the standard convention of using - to mean stdin, the --contents option would be more flexible, since "--contents -" would just be a special case.
-- David Kågedal