git-contacts questions

> 1) Passing just "HEAD" as a committish like in "git contacts HEAD"
> does not output anything for me, but using the SHA1 for HEAD does
> neither. My HEAD commit does not add any files, but only modifies
> previously existing files, so I would have expected some output. In
> case it turns out to be correct to have no output in my case, could we
> probably say that in some message to the user?

> 2) For some commits I get error messages from "git blame" in function
> get_blame because multiple -L options are specified:
>
> $ git contacts b0783baacd20be7007df40cf274985c4863d63fb
> fatal: More than one '-L n,m' option given
> fatal: More than one '-L n,m' option given
> fatal: More than one '-L n,m' option given
> fatal: More than one '-L n,m' option given
>
> From reading git-blame's man page it indeed seems to me as if only one
> -L option is allowed, so is this something that needs to be fixed in
> git-contacts?

>> 1) Passing just "HEAD" as a committish like in "git contacts HEAD"
>> does not output anything for me, but using the SHA1 for HEAD does
>> neither. My HEAD commit does not add any files, but only modifies
>> previously existing files, so I would have expected some output. In
>> case it turns out to be correct to have no output in my case, could we
>> probably say that in some message to the user?
>
> It should be HEAD^, or -1, like with 'git format-patch'.

>> 2) For some commits I get error messages from "git blame" in function
>> get_blame because multiple -L options are specified:
>>
>> $ git contacts b0783baacd20be7007df40cf274985c4863d63fb
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>>
>> From reading git-blame's man page it indeed seems to me as if only one
>> -L option is allowed, so is this something that needs to be fixed in
>> git-contacts?
>
> You are probably using a newer version of the script on an older version of Git.

> On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>>> 1) Passing just "HEAD" as a committish like in "git contacts HEAD"
>>> does not output anything for me, but using the SHA1 for HEAD does
>>> neither. My HEAD commit does not add any files, but only modifies
>>> previously existing files, so I would have expected some output. In
>>> case it turns out to be correct to have no output in my case, could we
>>> probably say that in some message to the user?
>>
>> It should be HEAD^, or -1, like with 'git format-patch'.
>
> Oh, that's pretty much unexpected. Wouldn't it be much more natural if
> I had to specify the commit(s) that introduce(s) the changes that I
> want others to look at?

>> You can also try git-related instead[1].
>>
>> [1] https://github.com/felipec/git-related
>
> I just did very quickly (with Ruby 1.8.7) and I get:
>
> $ git related b0783baacd20be7007df40cf274985c4863d63fb
> C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in
> `popen': can't convert Array into String (TypeError)
>         from C:/Program Files
> (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args'
>         from C:/Program Files (x86)/Git/libexec/git-core/git-related:345

> On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth
> <sschuberth@gmail.com> wrote:
>> On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>
>>>> 1) Passing just "HEAD" as a committish like in "git contacts HEAD"
>>>> does not output anything for me, but using the SHA1 for HEAD does
>>>> neither. My HEAD commit does not add any files, but only modifies
>>>> previously existing files, so I would have expected some output. In
>>>> case it turns out to be correct to have no output in my case, could we
>>>> probably say that in some message to the user?
>>>
>>> It should be HEAD^, or -1, like with 'git format-patch'.
>>
>> Oh, that's pretty much unexpected. Wouldn't it be much more natural if
>> I had to specify the commit(s) that introduce(s) the changes that I
>> want others to look at?
>
> Yeah, that's exactly what you are doing. How do you tell 'git log' to
> show you certain changes?

>> $ git related b0783baacd20be7007df40cf274985c4863d63fb
>> C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in
>> `popen': can't convert Array into String (TypeError)
>>         from C:/Program Files
>> (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args'
>>         from C:/Program Files (x86)/Git/libexec/git-core/git-related:345
>
> Fixed.

> On Tue, Oct 29, 2013 at 11:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth
>> <sschuberth@gmail.com> wrote:
>>> On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>
>>>>> 1) Passing just "HEAD" as a committish like in "git contacts HEAD"
>>>>> does not output anything for me, but using the SHA1 for HEAD does
>>>>> neither. My HEAD commit does not add any files, but only modifies
>>>>> previously existing files, so I would have expected some output. In
>>>>> case it turns out to be correct to have no output in my case, could we
>>>>> probably say that in some message to the user?
>>>>
>>>> It should be HEAD^, or -1, like with 'git format-patch'.
>>>
>>> Oh, that's pretty much unexpected. Wouldn't it be much more natural if
>>> I had to specify the commit(s) that introduce(s) the changes that I
>>> want others to look at?
>>
>> Yeah, that's exactly what you are doing. How do you tell 'git log' to
>> show you certain changes?
>
> I'm not sure what you're trying to point me at. It's clear that from
> an implementation view you need to blame HEAD^ if you need to know
> which poeple should review your changes in HEAD.

>> I'm not sure what you're trying to point me at. It's clear that from
>> an implementation view you need to blame HEAD^ if you need to know
>> which poeple should review your changes in HEAD.
>
> I agree that the situation when providing only HEAD is really
> disappointing...
>
>> But IMHO that is an implementation detail that should be hidden from
>> the user.
>
> ... but it's not just an implementation detail: git-contacts takes a
> range of commits, so you can ask for people to Cc for a whole patch
> series for example.
>
> If I understand correctly, "git contact $ONE_COMMIT" does
> "git contact $ONE_COMMIT..HEAD" implicitly, and this is weird when
> $ONE_COMMIT is HEAD.

>>> $ git related b0783baacd20be7007df40cf274985c4863d63fb
>>> C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in
>>> `popen': can't convert Array into String (TypeError)
>>>         from C:/Program Files
>>> (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args'
>>>         from C:/Program Files (x86)/Git/libexec/git-core/git-related:345
>>
>> Fixed.
>
> Thanks, but now I'm getting
>
> $ git related b0783baacd20be7007df40cf274985c4863d63fb
> fatal: ambiguous argument '\^b0783baacd20be7007df40cf274985c4863d63fb': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
>
> I've checked of course that the commit exists.

> On Tue, Oct 29, 2013 at 2:34 AM, Sebastian Schuberth
> <sschuberth@gmail.com> wrote:
>> 2) For some commits I get error messages from "git blame" in function
>> get_blame because multiple -L options are specified:
>>
>> $ git contacts b0783baacd20be7007df40cf274985c4863d63fb
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>> fatal: More than one '-L n,m' option given
>>
>> From reading git-blame's man page it indeed seems to me as if only one
>> -L option is allowed, so is this something that needs to be fixed in
>> git-contacts?
>
> You are probably using a newer version of the script on an older version of Git.

>>> $ git contacts b0783baacd20be7007df40cf274985c4863d63fb
>>> fatal: More than one '-L n,m' option given
>>> fatal: More than one '-L n,m' option given
>>> fatal: More than one '-L n,m' option given
>>> fatal: More than one '-L n,m' option given
>>>
>>> From reading git-blame's man page it indeed seems to me as if only one
>>> -L option is allowed, so is this something that needs to be fixed in
>>> git-contacts?
>>
>> You are probably using a newer version of the script on an older version of Git.
>
> Right. git-blame learned to accept multiple -L's in 58dbfa2e59a1, and
> git-contacts started taking advantage of that feature in 4c70cfbfbc2d.
> A git-contacts prior to 4c70cfbfbc2d might work for you.