On Thu, Dec 7, 2017 at 7:24 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>>> I do think it may make sense for
>>> the "short" one to use NULL, like:
>>>
>>> skip_to_optional_val(arg, "--relative, &arg)
>>>
>>> but maybe some other callers would be more inconvenienced (they may have
>>
Christian Couder writes:
>> I do think it may make sense for
>> the "short" one to use NULL, like:
>>
>> skip_to_optional_val(arg, "--relative, &arg)
>>
>> but maybe some other callers would be more inconvenienced (they may have
>> to current NULL back into the empty string if they want to stri
On Thu, Dec 07, 2017 at 09:14:31AM +0100, Christian Couder wrote:
> > I do think it may make sense for
> > the "short" one to use NULL, like:
> >
> > skip_to_optional_val(arg, "--relative, &arg)
> >
> > but maybe some other callers would be more inconvenienced (they may have
> > to current NULL
On Thu, Dec 7, 2017 at 1:56 AM, Jeff King wrote:
> I think we'd do better to just assign NULL when there's "=", so we can
> tell the difference between "--relative", "--relative=", and
> "--relative=foo" (all of which are distinct).
>
> I think that's possible with the current scheme by doing:
>
On Wed, Dec 06, 2017 at 05:04:02PM -0800, Jacob Keller wrote:
> What you outlined above is probably the best we can do. We could even
> add some extra helper which does that for us if we want.
>
> I sent a patch that merely reverts the change to --relative and adds a
> test for now though.
Thank
On Wed, Dec 6, 2017 at 4:56 PM, Jeff King wrote:
> On Wed, Dec 06, 2017 at 04:38:29PM -0800, Jacob Keller wrote:
>
>> >> But nope, it looks like the culprit is f7923a5ece (diff: use
>> >> skip_to_optional_val(), 2017-12-04), which switched over parsing of
>> >> "--relative".
>> >
>> > Oh, actually
On Wed, Dec 06, 2017 at 04:38:29PM -0800, Jacob Keller wrote:
> >> But nope, it looks like the culprit is f7923a5ece (diff: use
> >> skip_to_optional_val(), 2017-12-04), which switched over parsing of
> >> "--relative".
> >
> > Oh, actually, I guess I was half-right. It feeds &options->prefix as t
On Wed, Dec 6, 2017 at 4:24 PM, Jeff King wrote:
> On Wed, Dec 06, 2017 at 07:22:35PM -0500, Jeff King wrote:
>
>> On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:
>>
>> > I think I narrowed this down to "git diff-index --name-only --relative
>> > HEAD" producing a list of files *not*
On Wed, Dec 06, 2017 at 07:22:35PM -0500, Jeff King wrote:
> On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:
>
> > I think I narrowed this down to "git diff-index --name-only --relative
> > HEAD" producing a list of files *not* relative to the current
> > directory.
>
> Hmm, my gue
On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:
> I think I narrowed this down to "git diff-index --name-only --relative
> HEAD" producing a list of files *not* relative to the current
> directory.
Hmm, my guess would have been something funny in the setup code
forgetting our origin
On Wed, Dec 6, 2017 at 4:01 PM, Jacob Keller wrote:
> On Wed, Dec 6, 2017 at 3:53 PM, Jacob Keller wrote:
>> Hi,
>>
>> I'm still investigating, but thought I'd send an email. I recently
>> updated to jch branch, and found that completion for git commit does
>> not work as expected.
>>
>> If I hav
On Wed, Dec 6, 2017 at 3:53 PM, Jacob Keller wrote:
> Hi,
>
> I'm still investigating, but thought I'd send an email. I recently
> updated to jch branch, and found that completion for git commit does
> not work as expected.
>
> If I have a git repository with a modified file in a subdirectiory,
>
Hi,
I'm still investigating, but thought I'd send an email. I recently
updated to jch branch, and found that completion for git commit does
not work as expected.
If I have a git repository with a modified file in a subdirectiory,
then git commit produces the name of the subdirectory instead of
t
13 matches
Mail list logo
