From: Dylan Reid <dgreid@gmail.com>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] blame: can specify shas of commits to ignore on command line
Date: Tue, 4 May 2010 17:46:59 -0400 [thread overview]
Message-ID: <j2sfd211a421005041446ub9c2247ai484c2473df856b31@mail.gmail.com> (raw)
In-Reply-To: <4BE0918C.9090204@lsrfire.ath.cx>
Thanks for the speedy reply.
> Only the long option --ignore-commit works with your patch, -I doesn't.
>
Correct. I took that out because I didn't want to use "-I' which
could eventually be used by a more commonly used feature. Do you
agree or do you think it is worth using it. It's a UI decision I
didn't want to make.
>
> This function was moved from below, but it seems to be indented with
> three spaces instead of tabs now. Adding a declaration without moving
> the function would avoid that and result in a smaller patch.
>
Good catch, I'll do that and re-send.
>
> An ignored commit can still be blamed if there is no other commit to
> pass it on. So e.g. the initial commit for the file could end up being
> blamed for lines that were added by later commits which are being
> ignored. That may look confusing.
>
> Would it make sense to pass the blame to some kind of null commit, i.e.
> a special marker that says "I could tell you who is to blame for this
> line but you said you don't want to know"?
>
A null commit could work. I think the behavior should be to not
ignore the commit. Meaning if you specify a commit that introduced a
line of code that line of code will still be blamed on the ignored
commit. Does That sound logical or is it too confusing?
Thanks,
Dylan
next prev parent reply other threads:[~2010-05-04 21:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 2:21 [PATCH] blame: can specify shas of commits to ignore on command line Dylan Reid
2010-05-04 21:28 ` René Scharfe
2010-05-04 21:46 ` Dylan Reid [this message]
2010-05-04 23:01 ` Junio C Hamano
2010-05-04 23:08 ` Dylan Reid
2010-05-05 5:19 ` Junio C Hamano
2010-05-05 5:28 ` Dylan Reid
2012-03-08 21:01 ` cnighswonger
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=j2sfd211a421005041446ub9c2247ai484c2473df856b31@mail.gmail.com \
--to=dgreid@gmail.com \
--cc=git@vger.kernel.org \
--cc=rene.scharfe@lsrfire.ath.cx \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).