Git completion - contributing to git.git

Git completion - contributing to git.git

[Nicolas Sebrecht]

Hi,

As a user of Git, I'd like to have Git completion in sync with the Git
project itself rather than with zsh. I don't update zsh as much as Git.

I'm not saying that having completion in the zsh project doesn't make
sense but that it's more relevant to have latest version of the
completion in the Git project.

What about starting contributing to Git ('contrib/completion' looks like
a good path) ?  Could Git completion contributors send their patches to
the Git project too ?

PS: I know the Git mailing list doesn't need subscription to post.  Does
the zsh lists ask for subscribing ?

-- 
Nicolas Sebrecht

Re: Git completion - contributing to git.git

[Nikolai Weibull]

On Thu, Jul 1, 2010 at 03:05, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:

(Why am I not included in the Cc?  I am the original and principal
author, after all.  The minuscule amount of attribution it would have
provided would have been nice. ;-)

> What about starting contributing to Git ('contrib/completion' looks like
> a good path) ?  Could Git completion contributors send their patches to
> the Git project too ?

I’d rather not, to be honest.  It’s always a pain to have two files,
as they can become out of sync when patches are sent to one repository
and not the other, users don’t know which version to use, and so on.

Re: Git completion - contributing to git.git

[Richard Hartmann]

On Thu, Jul 1, 2010 at 10:00, Nikolai Weibull <now@bitwi.se> wrote:

> I’d rather not, to be honest.  It’s always a pain to have two files,
> as they can become out of sync when patches are sent to one repository
> and not the other, users don’t know which version to use, and so on.

Is there a chance to sync files on a git level? I.e. that as soon as a
commit is pushed to either repo, the other is notified in some way.

If that's not possible, split brain problems will probably outweigh any
benefits.


Richard

PS: Yes, I am aware that git works on a changeset, not a file level.
Still asking does not hurt, does it? ;)

Re: Git completion - contributing to git.git

[Nikolai Weibull]

On Thu, Jul 1, 2010 at 10:13, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:

> Is there a chance to sync files on a git level? I.e. that as soon as a
> commit is pushed to either repo, the other is notified in some way.

You could probably write a post-commit hook that would mail the patch
to the Git mailing list, but that wouldn’t work for people not using
the Zsh Git repository.

Re: Git completion - contributing to git.git

[Nicolas Sebrecht]

On Thu, Jul 01, 2010 at 10:00:42AM +0200, Nikolai Weibull wrote:
> 
> (Why am I not included in the Cc?  I am the original and principal
> author, after all.  The minuscule amount of attribution it would have
> provided would have been nice. ;-)

I'm sorry for that. I did a command like

  git blame -- path/to/_git | cut -d' ' -f2,3 | sort | uniq

on my Git's zsh repository which is obviously not approppriate. :-/

> I’d rather not, to be honest.  It’s always a pain to have two files,
> as they can become out of sync when patches are sent to one repository
> and not the other, users don’t know which version to use, and so on.

I believe this could easily be solved by versionning the file (yes,
by adding a "# vXYZ"). Perhaps a more explicit header could help :

  # vXYZ

  # If you intend to contribute to maintaining this file, please
  # increase the version number and fill the patches to both zsh and git
  # projects at <addresses>. Thanks!

The worst cases for me would be to either
  have two unrelated zsh completion files in each project
or
  maintaining a public (possibly sent to the Git project) completion
  file downstream to the zsh one
.

Thoughts?

-- 
Nicolas Sebrecht

Re: Git completion - contributing to git.git

[Nikolai Weibull]

On Thu, Jul 1, 2010 at 10:33, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:
> On Thu, Jul 01, 2010 at 10:00:42AM +0200, Nikolai Weibull wrote:

>> (Why am I not included in the Cc?  I am the original and principal
>> author, after all.  The minuscule amount of attribution it would have
>> provided would have been nice. ;-)
>
> I'm sorry for that. I did a command like
>
>  git blame -- path/to/_git | cut -d' ' -f2,3 | sort | uniq

Argh!  Can’t I even be blamed for it?!  ;-)

Re: Git completion - contributing to git.git

[Frank Terbeck]

Nikolai Weibull wrote:
> Nicolas Sebrecht wrote:
>>  git blame -- path/to/_git | cut -d' ' -f2,3 | sort | uniq
>
> Argh!  Can’t I even be blamed for it?!  ;-)

Git may not know. But we know full well, that you're to blame. :-)

Re: Git completion - contributing to git.git

[Richard Hartmann]

On Thu, Jul 1, 2010 at 10:33, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:

> The worst cases for me would be to either
>  have two unrelated zsh completion files in each project
> or
>  maintaining a public (possibly sent to the Git project) completion
>  file downstream to the zsh one

Who will take care of this? Will you still reliably follow through on
doing this in half a year? A year? Five years?

Unless you _really_ want to do that, we will end up with a split brain
at some point.


This is why I asked for automated stuff. You write it once and, unless
things change significantly, it keeps on working.


Richard


PS: Automation could be as easy as sending a full list of differing
commits to the other dev list every time something changes. Though that
should be OK'ed by pws for the git list and no idea who on git's side.

Re: Git completion - contributing to git.git

[Doug Kearns]

On Thu, Jul 1, 2010 at 6:00 PM, Nikolai Weibull <now@bitwi.se> wrote:
> On Thu, Jul 1, 2010 at 03:05, Nicolas Sebrecht
> <nicolas.s-dev@laposte.net> wrote:
>
> (Why am I not included in the Cc?  I am the original and principal
> author, after all.  The minuscule amount of attribution it would have
> provided would have been nice. ;-)

We know who wrote it.  I'm scared to touch it lest you yell at me.

>> What about starting contributing to Git ('contrib/completion' looks like
>> a good path) ?  Could Git completion contributors send their patches to
>> the Git project too ?
>
> I’d rather not, to be honest.  It’s always a pain to have two files,
> as they can become out of sync when patches are sent to one repository
> and not the other, users don’t know which version to use, and so on.

+1

There's nothing special about Git either.  What of the other 500 odd
completion functions and 'associated' projects?

Regards,
Doug

Re: Git completion - contributing to git.git

[Štěpán Němec]

Doug Kearns <dougkearns@gmail.com> writes:

> On Thu, Jul 1, 2010 at 6:00 PM, Nikolai Weibull <now@bitwi.se> wrote:
>> On Thu, Jul 1, 2010 at 03:05, Nicolas Sebrecht
>> <nicolas.s-dev@laposte.net> wrote:
>>
>> (Why am I not included in the Cc?  I am the original and principal
>> author, after all.  The minuscule amount of attribution it would have
>> provided would have been nice. ;-)
>
> We know who wrote it.  I'm scared to touch it lest you yell at me.
>
>>> What about starting contributing to Git ('contrib/completion' looks like
>>> a good path) ?  Could Git completion contributors send their patches to
>>> the Git project too ?
>>
>> I’d rather not, to be honest.  It’s always a pain to have two files,
>> as they can become out of sync when patches are sent to one repository
>> and not the other, users don’t know which version to use, and so on.
>
> +1
>
> There's nothing special about Git either.  What of the other 500 odd
> completion functions and 'associated' projects?

What's special about Git is that new options are added and various
tweaks done _very_ often. The Zsh Git completion, apart from being
buggy/unfinished (some of the problems were fixed recently), is also
out of sync, because nobody really follows Git development and updates
it accordingly.

IMO having _git inside the Git tree is a good idea. The Bash completion
is also maintained together with Git, by the Git developers, and I
wouldn't be surprised if it were much better than the Zsh one (rather,
I'd be surprised if it weren't ;-).)

The only problem I see is whether there are really enough Zsh users
following Git development and at the same time able and willing to
maintain the completion script.

Štěpán

Re: Git completion - contributing to git.git

[Simon Ruderich]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

On Sun, Jul 04, 2010 at 10:45:13AM +0200, Štěpán Němec wrote:
>>> I’d rather not, to be honest.  It’s always a pain to have two files,
>>> as they can become out of sync when patches are sent to one repository
>>> and not the other, users don’t know which version to use, and so on.
>>
>> +1
>>
>> There's nothing special about Git either.  What of the other 500 odd
>> completion functions and 'associated' projects?
>
> What's special about Git is that new options are added and various
> tweaks done _very_ often. The Zsh Git completion, apart from being
> buggy/unfinished (some of the problems were fixed recently), is also
> out of sync, because nobody really follows Git development and updates
> it accordingly.

I'm not very actively following Git's development (always running
latest release though), but I don't think that's the case for the
"normal" user. I consider myself an intermediate/advanced git
user and use _git from the current zsh CVS checkout and I've
never felt _git was missing something important (sometimes file
completion could be even smarter - and maybe faster, but it's
already very good). Sometimes one option or another is missing,
but I don't think that's a big problem as I can just add it (or
ignore it, as I don't need all of git's options anyway).

Thanks by the way for the great work the developers of _git have
done.

> [snip]
>
> The only problem I see is whether there are really enough Zsh users
> following Git development and at the same time able and willing to
> maintain the completion script.

I don't see the difference between maintaining the _git file in
zsh's CVS or in git's git repository regarding the speed of
development of _git.

If an active git developer (or anybody else) wants to update it
in zsh's CVS he only needs to send the patches here and they are
applied quickly.

The only difference is, as others have already mentioned, that
maintaining a file in two places is a very bad thing. And as user
I have to look in many different places (and I even have to know
that the completion exists) to get my completion functions.
That's not a very good idea.

> Štěpán

IMHO moving _git to git's repository only increase the work in
maintaining it, sometimes which could be spend much better in
improving it.

Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Git completion - contributing to git.git

[Štěpán Němec]

Simon Ruderich <simon@ruderich.org> writes:

> On Sun, Jul 04, 2010 at 10:45:13AM +0200, Štěpán Němec wrote:
>>>> I’d rather not, to be honest.  It’s always a pain to have two files,
>>>> as they can become out of sync when patches are sent to one repository
>>>> and not the other, users don’t know which version to use, and so on.
>>>
>>> +1
>>>
>>> There's nothing special about Git either.  What of the other 500 odd
>>> completion functions and 'associated' projects?
>>
>> What's special about Git is that new options are added and various
>> tweaks done _very_ often. The Zsh Git completion, apart from being
>> buggy/unfinished (some of the problems were fixed recently), is also
>> out of sync, because nobody really follows Git development and updates
>> it accordingly.
>
> I'm not very actively following Git's development (always running
> latest release though), but I don't think that's the case for the
> "normal" user. I consider myself an intermediate/advanced git
> user and use _git from the current zsh CVS checkout and I've
> never felt _git was missing something important (sometimes file
> completion could be even smarter - and maybe faster, but it's
> already very good). Sometimes one option or another is missing,
> but I don't think that's a big problem as I can just add it (or
> ignore it, as I don't need all of git's options anyway).

I didn't mean to imply _git was not "good enough". Obviously it is
sufficient for the people that are using it, otherwise there would be
much more work being done on it than currently is. But that doesn't mean
it can't and shouldn't be improved.

>> The only problem I see is whether there are really enough Zsh users
>> following Git development and at the same time able and willing to
>> maintain the completion script.
>
> I don't see the difference between maintaining the _git file in
> zsh's CVS or in git's git repository regarding the speed of
> development of _git.
>
> If an active git developer (or anybody else) wants to update it
> in zsh's CVS he only needs to send the patches here and they are
> applied quickly.

Maybe. I've seen some _git patches lying on this list for several weeks
before being applied, but recently that seems to be an exception. So
yeah, if someone from the Git side gets more involved and sends patches
every now and then and they get applied in reasonable time, there might
be no difference.

> The only difference is, as others have already mentioned, that
> maintaining a file in two places is a very bad thing. And as user
> I have to look in many different places (and I even have to know
> that the completion exists) to get my completion functions.
> That's not a very good idea.

AIUI the "maintaining a file in two places" idea was conditioned by some
kind of synchronization scheme, i.e. you could use either of the versions,
because they would just be the same most of the time.

Failing that, it seems to me (having been following both zsh-workers and
the Git list for some time) that having _git in Git (given there are
people who'd work on it, see my previous mail), and possibly just using
this list for getting advice when they're stuck or want to discuss
something with more Zsh users, might be more effective, esp. on the
synchronization front (the Bash completion changes often get committed
immediately after the corresponding Git feature is added).

> IMHO moving _git to git's repository only increase the work in
> maintaining it, sometimes which could be spend much better in
> improving it.

I don't see how it would increase the work.

Štěpán

Re: Git completion - contributing to git.git

[Frank Terbeck]

Nicolas Sebrecht wrote:
> As a user of Git, I'd like to have Git completion in sync with the Git
> project itself rather than with zsh. I don't update zsh as much as Git.

It's actually fairly trivial to update a single completion without
updating the main shell:
  <http://zshwiki.org/home/config/functions>

> I'm not saying that having completion in the zsh project doesn't make
> sense but that it's more relevant to have latest version of the
> completion in the Git project.
>
> What about starting contributing to Git ('contrib/completion' looks like
> a good path) ?  Could Git completion contributors send their patches to
> the Git project too ?

IMHO it doesn't matter so much *where* a completion is maintained. It's
much more important that it is maintained and updated at all. It would
be great to see more people contributing to `_git'; because frankly,
it's huge and needs more man power. It'd be great to see more people
trying to get it in sync with git's master branch. Personally I'm only
touching it if there's a serious itch I feel, that needs relief. But
most of the time, the completion just works fine for me.

And FWIW, I like it that the zsh repository is the central source of
completion functions. No searching for where to get a completion; no
thinking about which version is right.

Also, maintaining something in two places is a pain in the ass. :)

> PS: I know the Git mailing list doesn't need subscription to post.  Does
> the zsh lists ask for subscribing ?

I don't think you need to be subscribed here either.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925