Since there hasn't been any movement on the alternative solutions mentioned
here, would it be reasonable to accept this patch in the meantime?
--
Keith Smiley
> On Jan 17, 2018, at 01:48, Duy Nguyen wrote:
>
>> On Wed, Jan 17, 2018 at 1:17 PM, Kevin Daudt wrote:
>>> On Wed, Jan 17, 2018 at
Duy Nguyen writes:
> Looks good. If we want to be more careful, we can follow up with
> something even more annoying like this before removing 'rm'
>
> -- 8< --
> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
> index 577b969c1b..0a544703e6 100644
>
On Wed, Jan 17, 2018 at 1:17 PM, Kevin Daudt wrote:
> On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:
>> PS. This also makes me thing about supporting subcommand aliases, so
>> that people can add back 'git remote rm' if they like (or something
>> like 'git r rm' when
On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:
> On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:
> > Duy Nguyen writes:
> >
> > > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:
> > >> So it sounds like either we should
On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:
> >> So it sounds like either we should deprecate rm, or I should update the
> >> patch to the suggested method
Duy Nguyen writes:
> On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:
>> So it sounds like either we should deprecate rm, or I should update the
>> patch to the suggested method where we just complete remotes, but not rm in
>> the list of completions.
>
>
On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:
> So it sounds like either we should deprecate rm, or I should update the patch
> to the suggested method where we just complete remotes, but not rm in the
> list of completions.
I vote for deprecation. I could send a patch to
So it sounds like either we should deprecate rm, or I should update the patch
to the suggested method where we just complete remotes, but not rm in the list
of completions.
Thoughts?
--
Keith Smiley
On Wed, Jan 3, 2018, at 11:24, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason
Ævar Arnfjörð Bjarmason writes:
> On Sat, Dec 30 2017, Todd Zullinger jotted:
>
>> And I think that should also apply to
>> not offering completion for commands/subcommands/options
>> which are only kept for backward compatibility.
>
> Yeah I think it makes sense to at some
On Fri, Dec 29, 2017 at 11:19 AM, Keith Smiley wrote:
> It looks like that was just about preferring remove in documentation and the
> like, I think it would still make sense to have both for completion since rm
> is still supported.
'rm' should be deprecated. But because I did
I'm definitely happy to update this patch for now to just complete the
remote names, and not add rm to the list of subcommand completions if
we're all ok with that!
--
Keith Smiley
On 12/30, Ævar Arnfjörð Bjarmason wrote:
On Sat, Dec 30 2017, Todd Zullinger jotted:
Ævar Arnfjörð Bjarmason
On Sat, Dec 30 2017, Todd Zullinger jotted:
> Ævar Arnfjörð Bjarmason wrote:
>>> I think adding 'rm' to completion definitely counts as advertisement.
>>> It doesn't have much practical use, after all: typing 'rm' with
>>> completion is actually one more keystroke than without (rm vs. rm).
>>
>>
Ævar Arnfjörð Bjarmason wrote:
>> I think adding 'rm' to completion definitely counts as advertisement.
>> It doesn't have much practical use, after all: typing 'rm' with
>> completion is actually one more keystroke than without (rm vs. rm).
>
> This is only one use of the completion interface,
On Fri, Dec 29 2017, SZEDER Gábor jotted:
>> Keith Smiley wrote:
>> > It looks like that was just about preferring remove in documentation
>> > and the like, I think it would still make sense to have both for
>> > completion since rm is still supported.
>>
>> I read it as a first step in a long
The goal of this fix isn't to complete rm itself (although that is a
side effect), it's to complete the remote names after you type rm.
Without this patch doing this:
git remote rm
Attempts to complete the options for `git remote` instead of the remote
names.
--
Keith Smiley
On 12/29,
> Keith Smiley wrote:
> > It looks like that was just about preferring remove in documentation
> > and the like, I think it would still make sense to have both for
> > completion since rm is still supported.
>
> I read it as a first step in a long process to eventually
> remove 'remote rm', but
Keith Smiley wrote:
> It looks like that was just about preferring remove in documentation
> and the like, I think it would still make sense to have both for
> completion since rm is still supported.
I read it as a first step in a long process to eventually
remove 'remote rm', but if that's never
Sorry about that! Patch below.
Previously git remote rm did not complete your list of removes as remove
does.
Signed-off-by: Keith Smiley
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Dec 29, 2017 at 02:01:00AM +, Keith Smiley wrote:
> From: Keith Smiley
>
> Previously git remote rm did not complete your list of removes as remove
> does.
Your signed-off-by[1] is missing, could you please add that?
[1]:
It looks like that was just about preferring remove in documentation and
the like, I think it would still make sense to have both for completion
since rm is still supported.
--
Keith Smiley
On 12/28, Todd Zullinger wrote:
Hi Keith,
Keith Smiley wrote:
Previously git remote rm did not
Hi Keith,
Keith Smiley wrote:
> Previously git remote rm did not complete your list of removes as remove
> does.
Looking through the history, the rm subcomand completion was
explicitly removed in e17dba8fe1 ("remote: prefer subcommand
name 'remove' to 'rm'", 2012-09-06).
--
Todd
From: Keith Smiley
Previously git remote rm did not complete your list of removes as remove
does.
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
22 matches
Mail list logo