* Git completion - contributing to git.git @ 2010-07-01 1:05 Nicolas Sebrecht 2010-07-01 8:00 ` Nikolai Weibull 2010-07-01 8:19 ` Frank Terbeck 0 siblings, 2 replies; 13+ messages in thread From: Nicolas Sebrecht @ 2010-07-01 1:05 UTC (permalink / raw) To: zsh-users; +Cc: Nicolas Sebrecht, Clint Adams, Doug Kearns, Peter Stephenson 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 1:05 Git completion - contributing to git.git Nicolas Sebrecht @ 2010-07-01 8:00 ` Nikolai Weibull 2010-07-01 8:13 ` Richard Hartmann ` (3 more replies) 2010-07-01 8:19 ` Frank Terbeck 1 sibling, 4 replies; 13+ messages in thread From: Nikolai Weibull @ 2010-07-01 8:00 UTC (permalink / raw) To: Nicolas Sebrecht; +Cc: zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:00 ` Nikolai Weibull @ 2010-07-01 8:13 ` Richard Hartmann 2010-07-01 8:18 ` Nikolai Weibull 2010-07-01 8:33 ` Nicolas Sebrecht ` (2 subsequent siblings) 3 siblings, 1 reply; 13+ messages in thread From: Richard Hartmann @ 2010-07-01 8:13 UTC (permalink / raw) To: Nikolai Weibull Cc: Nicolas Sebrecht, zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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? ;) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:13 ` Richard Hartmann @ 2010-07-01 8:18 ` Nikolai Weibull 0 siblings, 0 replies; 13+ messages in thread From: Nikolai Weibull @ 2010-07-01 8:18 UTC (permalink / raw) To: Richard Hartmann Cc: Nicolas Sebrecht, zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:00 ` Nikolai Weibull 2010-07-01 8:13 ` Richard Hartmann @ 2010-07-01 8:33 ` Nicolas Sebrecht 2010-07-01 9:15 ` Nikolai Weibull 2010-07-01 9:35 ` Richard Hartmann 2010-07-04 5:50 ` Doug Kearns [not found] ` <AANLkTin9y2_EtnBDYfdG1ctEHP3GkiStbXFMvf3GX3gp__29002.7882242159$1278224383$gmane$org@mail.gmail.com> 3 siblings, 2 replies; 13+ messages in thread From: Nicolas Sebrecht @ 2010-07-01 8:33 UTC (permalink / raw) To: Nikolai Weibull Cc: Nicolas Sebrecht, zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:33 ` Nicolas Sebrecht @ 2010-07-01 9:15 ` Nikolai Weibull 2010-07-01 9:32 ` Frank Terbeck 2010-07-01 9:35 ` Richard Hartmann 1 sibling, 1 reply; 13+ messages in thread From: Nikolai Weibull @ 2010-07-01 9:15 UTC (permalink / raw) To: Nicolas Sebrecht; +Cc: zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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?! ;-) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 9:15 ` Nikolai Weibull @ 2010-07-01 9:32 ` Frank Terbeck 0 siblings, 0 replies; 13+ messages in thread From: Frank Terbeck @ 2010-07-01 9:32 UTC (permalink / raw) To: Nikolai Weibull; +Cc: zsh-users 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. :-) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:33 ` Nicolas Sebrecht 2010-07-01 9:15 ` Nikolai Weibull @ 2010-07-01 9:35 ` Richard Hartmann 1 sibling, 0 replies; 13+ messages in thread From: Richard Hartmann @ 2010-07-01 9:35 UTC (permalink / raw) To: Nicolas Sebrecht Cc: Nikolai Weibull, zsh-users, Clint Adams, Doug Kearns, Peter Stephenson 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 8:00 ` Nikolai Weibull 2010-07-01 8:13 ` Richard Hartmann 2010-07-01 8:33 ` Nicolas Sebrecht @ 2010-07-04 5:50 ` Doug Kearns [not found] ` <AANLkTin9y2_EtnBDYfdG1ctEHP3GkiStbXFMvf3GX3gp__29002.7882242159$1278224383$gmane$org@mail.gmail.com> 3 siblings, 0 replies; 13+ messages in thread From: Doug Kearns @ 2010-07-04 5:50 UTC (permalink / raw) To: zsh-users; +Cc: Nicolas Sebrecht 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <AANLkTin9y2_EtnBDYfdG1ctEHP3GkiStbXFMvf3GX3gp__29002.7882242159$1278224383$gmane$org@mail.gmail.com>]
* Re: Git completion - contributing to git.git [not found] ` <AANLkTin9y2_EtnBDYfdG1ctEHP3GkiStbXFMvf3GX3gp__29002.7882242159$1278224383$gmane$org@mail.gmail.com> @ 2010-07-04 8:45 ` Štěpán Němec 2010-07-04 9:58 ` Simon Ruderich [not found] ` <20100704095831.GA14152__37531.721746973$1278237962$gmane$org@ruderich.org> 0 siblings, 2 replies; 13+ messages in thread From: Štěpán Němec @ 2010-07-04 8:45 UTC (permalink / raw) To: Doug Kearns; +Cc: zsh-users, Nicolas Sebrecht 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-04 8:45 ` Štěpán Němec @ 2010-07-04 9:58 ` Simon Ruderich [not found] ` <20100704095831.GA14152__37531.721746973$1278237962$gmane$org@ruderich.org> 1 sibling, 0 replies; 13+ messages in thread From: Simon Ruderich @ 2010-07-04 9:58 UTC (permalink / raw) To: zsh-users [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20100704095831.GA14152__37531.721746973$1278237962$gmane$org@ruderich.org>]
* Re: Git completion - contributing to git.git [not found] ` <20100704095831.GA14152__37531.721746973$1278237962$gmane$org@ruderich.org> @ 2010-07-04 12:09 ` Štěpán Němec 0 siblings, 0 replies; 13+ messages in thread From: Štěpán Němec @ 2010-07-04 12:09 UTC (permalink / raw) To: Simon Ruderich; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Git completion - contributing to git.git 2010-07-01 1:05 Git completion - contributing to git.git Nicolas Sebrecht 2010-07-01 8:00 ` Nikolai Weibull @ 2010-07-01 8:19 ` Frank Terbeck 1 sibling, 0 replies; 13+ messages in thread From: Frank Terbeck @ 2010-07-01 8:19 UTC (permalink / raw) To: Nicolas Sebrecht Cc: zsh-users, Clint Adams, Doug Kearns, Peter Stephenson, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-07-04 12:10 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-01 1:05 Git completion - contributing to git.git Nicolas Sebrecht 2010-07-01 8:00 ` Nikolai Weibull 2010-07-01 8:13 ` Richard Hartmann 2010-07-01 8:18 ` Nikolai Weibull 2010-07-01 8:33 ` Nicolas Sebrecht 2010-07-01 9:15 ` Nikolai Weibull 2010-07-01 9:32 ` Frank Terbeck 2010-07-01 9:35 ` Richard Hartmann 2010-07-04 5:50 ` Doug Kearns [not found] ` <AANLkTin9y2_EtnBDYfdG1ctEHP3GkiStbXFMvf3GX3gp__29002.7882242159$1278224383$gmane$org@mail.gmail.com> 2010-07-04 8:45 ` Štěpán Němec 2010-07-04 9:58 ` Simon Ruderich [not found] ` <20100704095831.GA14152__37531.721746973$1278237962$gmane$org@ruderich.org> 2010-07-04 12:09 ` Štěpán Němec 2010-07-01 8:19 ` Frank Terbeck
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).