From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: git-blame and blame GUI wishlist
Date: Mon, 6 Aug 2007 00:09:37 +0200 [thread overview]
Message-ID: <200708060009.37595.jnareb@gmail.com> (raw)
1. In git-gui blame viewer you can click on shortened sha1 of a commit
to see file at given version. Unfortunately git-gui goes to other
version of a file by reblaming a file starting from scratch.
It would be nice to have
git blame --incremental=<revision1> <revision2> -- <file>
which would blame only lines which differ between <revision1>
and <revision2>. We can assume that <revision2> is ancestor of
<revision1>, I think. I'm not completely sure if it is possible
and reasonable, i.e. if one can assume that only lines which
differ need reblaming...
And of course use this feature in "git-gui blame" which should
speed up exploring file history a bit.
2. Sometimes I'm interested only in part of a file. Thus I'd like
"git-gui blame" to understand line-range parameter of git-blame.
It means that I'd like to be able to say for example:
git gui blame -L '/^sub git_feed/,/^}$/' HEAD -- gitweb/gitweb.perl
and have only given range of lines blamed, with the rest grayed out
in the "inactive control" style. Of course in the case I specified
line range incorrectly, I'd like to have menu entry or a button to
reblame _whole_ file... Or perhaps do blaming of a whole file in the
background, after blaming specified range fo lines.
This should speed up "git gui blame" a bit. By the way, of course
git-gui should start with the selected line-range visible.
3. Sometimes when reviewing patches I do wonder: why the preimage looks
like it looks like. It would be useful in that situation to be able
to blame the patch (context lines and pre-image lines). Although I'm
not suer if it would bevery useful and used often [enough].
P.S. qgit uses some bottom-up all-files mechanism to get the blame of
all the files together. Could anyone describe in few sentences the
algorithm qgit uses? Would it be useful to put it available e.g. in
gitlib-thin for other viewers, or not; what do you think?
P.P.S. Of couse the examples and ideas are not limited to "git gui
blame"...
--
Jakub Narebski
Poland
reply other threads:[~2007-08-05 23:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708060009.37595.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).