git-contacts questions

git-contacts questions

[Sebastian Schuberth]

Hi,

I'm currently trying to get git-contacts to work under Windows / MSYS.
I have a few issues that may be due to me using the script in a wrong
way, or the script having some bugs, so I'd like to ask you for help.

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?

Thanks.

-- 
Sebastian Schuberth

Re: git-contacts questions

[Felipe Contreras]

On Tue, Oct 29, 2013 at 2:34 AM, Sebastian Schuberth
<sschuberth@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'.

> 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.

You can also try git-related instead[1].

[1] https://github.com/felipec/git-related

-- 
Felipe Contreras

Re: git-contacts questions

[Sebastian Schuberth]

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?

>> 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.

Well, I'm running Git for Windows 1.8.4, and according to [1]
git-blame was not changed after 1.8.4.

> 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

[1] http://git-scm.com/docs/git-blame.html

-- 
Sebastian Schuberth

Re: git-contacts questions

[Felipe Contreras]

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?

>> 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

Fixed.

-- 
Felipe Contreras

Re: git-contacts questions

[Sebastian Schuberth]

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. But IMHO that is an
implementation detail that should be hidden from the user. Like I
said, I think it would be much more natural if it worked by specifying
the commits that *I* introduced, and then lists all people to contact
for a review.

>> $ 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.

-- 
Sebastian Schuberth

Re: git-contacts questions

[Matthieu Moy]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> 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 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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git-contacts questions

[Sebastian Schuberth]

On Tue, Oct 29, 2013 at 3:39 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:

>> 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.

It's not only weird if $ONE_COMMIT is HEAD, but for any single commit.
At least I would expect "git contacts $ONE_COMMIT" to list the poeple
interested in the single commit $ONE_COMMIT. Instead, what it seems to
do is list the people who are interested in the commits *after*
$ONE_COMMIT.

-- 
Sebastian Schuberth

Re: git-contacts questions

[Felipe Contreras]

On Tue, Oct 29, 2013 at 8:17 AM, Sebastian Schuberth
<sschuberth@gmail.com> wrote:
> 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:

>>> $ 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.

I've pushed a fix, it's not complete, but should work for most cases.

-- 
Felipe Contreras

Re: git-contacts questions

[Eric Sunshine]

On Tue, Oct 29, 2013 at 4:57 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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.

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.

Re: git-contacts questions

[Sebastian Schuberth]

On Tue, Oct 29, 2013 at 8:02 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:

>>> $ 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.

Ah, and 58dbfa2e59a1 is not in any release yet. Thanks.

-- 
Sebastian Schuberth