Junio C Hamano writes:
> Let's do this for now instead. That would make it clear to people
> who (rightly or wrongly) think the "--follow" option should do
> something that we already do so, and explain the output that they
> see when they do give the "--follow" option to the command.
>
> I may
Jeff King writes:
> On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
>
>> > I am a little lukewarm on my patch if only because of the precedent it
>> > sets. There are a trillion options that revision.c parses that are not
>> > necessarily meaningful or implemented for sub-commands
Jeff King writes:
> I guess it depends on your perspective. I can see the argument that
> blame is already doing what --follow would ask for, and thus it is a
> no-op. I think of it more as --follow is nonsensical for blame.
Is "--follow" a nonsense in the context of blame? I am not so sure.
I
On Sep 19, 2012, at 12:42 PM, Jeff King wrote:
>> So I am in general OK with it, but if we are to go that route, we
>> should make sure that the documentation makes it clear that blame
>> follows whole-file renames without any special instruction before
>> doing so. Otherwise, it again will send
On Sep 19, 2012, at 1:37 PM, Jeff King wrote:
> On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
>
>>> I am a little lukewarm on my patch if only because of the precedent it
>>> sets. There are a trillion options that revision.c parses that are not
>>> necessarily meaningful or im
On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
> > I am a little lukewarm on my patch if only because of the precedent it
> > sets. There are a trillion options that revision.c parses that are not
> > necessarily meaningful or implemented for sub-commands that piggy-back
> > on it
On Wed, Sep 19, 2012 at 12:36:56PM -0700, Junio C Hamano wrote:
> > Like this (totally untested) patch:
> >
> > diff --git a/builtin/blame.c b/builtin/blame.c
> > index 0e102bf..412d6dd 100644
> > --- a/builtin/blame.c
> > +++ b/builtin/blame.c
> > @@ -2365,6 +2365,10 @@ int cmd_blame(int argc, co
Jeff King writes:
> On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
>
>> That is a totally wrong message to send. You failed to teach the
>> reader that there is no need to do anything special to tell the
>> command to follow per-line origin across renames.
>>
>> So if anything,
On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
> That is a totally wrong message to send. You failed to teach the
> reader that there is no need to do anything special to tell the
> command to follow per-line origin across renames.
>
> So if anything, I would phrase it this way
Drew Northup writes:
> Make note that while the --follow option is accepted by git blame it does
> nothing.
>
> Signed-off-by: Drew Northup
> ---
> Documentation/git-blame.txt | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-blame.txt b/Documentatio
Make note that while the --follow option is accepted by git blame it does
nothing.
Signed-off-by: Drew Northup
---
Documentation/git-blame.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 7ee9236..7465bd8
11 matches
Mail list logo
