I made a list of modules where options shown in output of `equery _module_ --help` and output of `equery _module_ -<TAB><TAB>` are different. 1. belongs 2. check 3. depends 4. depgraph 5. files 6. list 7. size 8. uses 9. which Options of 'uses' and 'which' modules are updated in my patch for #350179 Now there is a question about conflict between options from gentoolkit-0.2.* and gentoolkit-0.3.*. Maybe this is the time to distribute gentoolkit completion file with gentoolkit package?
(In reply to comment #0) > I made a list of modules where options shown in output of `equery _module_ > --help` and output of `equery _module_ -<TAB><TAB>` are different. > > 1. belongs > 2. check > 3. depends > 4. depgraph > 5. files > 6. list > 7. size > 8. uses > 9. which > > Options of 'uses' and 'which' modules are updated in my patch for #350179 > > Now there is a question about conflict between options from gentoolkit-0.2.* > and gentoolkit-0.3.*. Maybe this is the time to distribute gentoolkit > completion file with gentoolkit package? > It is always better if "upstream" maintains their own bash-completion file. I'm fine with either way but rely on contributors for the gentoo-bashcomp package, so it lags in quality.
How about making a branch for gentoolkit-0.2.* and telling gentoolkit guys to grab completion file from trunk or this branch (depending on gentoolkit version of course) before each release? It would be perfect if both gentoolkit and gentoo-bashcomp would be version-controlled with git — submodules support is there very nice (example: Flaggie and completion file for it: http://github/mgorny/flaggie).
(In reply to comment #1) Another approach is to: 1. make a branch in gentoo-bashcomp for gentoolkit-0.2.* 2. commit fixes in completion for 0.2.* line there 3. continue to release this branch as stable one 4. commit fixes and updates for gentoolkit-0.3.* to trunk 5. make gentoo-bashcomp-999999999.ebuild
Jacek, fine and dandy idea but I've become the defacto sole committer to gentoo-bashcomp and I don't want to create more work :)
(In reply to comment #4) > Jacek, fine and dandy idea but I've become the defacto sole committer to > gentoo-bashcomp and I don't want to create more work :) Alright, gentoolkit-0.3* is stable now. How about updating gentoo-bashcomp? I've forked repo from git.overlys... and did some work at: https://github.com/mruwek/gentoo-bashcomp Take a look.
Great. Attach some git format patches and I will apply them all.
(In reply to comment #6) > Great. Attach some git format patches and I will apply them all. I thought that it will be easier to just pull those changesets from my repo, but as You wish ;)
I just can't envision a good workflow from github -> gentoo to be honest. What would you do to merge the changes?
Created attachment 309917 [details, diff] Update options completion for majority of equery modules modules updated: belongs, check, depends, depgraph, files, list, size.
Created attachment 309919 [details, diff] Fix completion for `equery belongs` 1. Remove -c and --category options as they are not present in `equery belongs --help` output. 2. Make code indentation more readable. 3. "Only complete if the previous entry on the command line is not a file name." now works properly also with options.
Created attachment 309921 [details, diff] Completion for `equery changes` 1. There is inconsitency in output of `equery changes --help`: * "Usage" and "examples" give different order of args. * In "Usage" it is: [options] pkgspec * In "examples" it is: pkgspec [options] 2. I chose "examples" approach so: * `equery c <TAB><TAB>` will complete pkgspec * `equery c -<TAB><TAB>` will complete -h and --help * `equery c pkgspec <TAB><TAB>` will complete other options
(In reply to comment #8) > I just can't envision a good workflow from github -> gentoo to be honest. Current gentoo-bashcomp repo is powered by git. Isn't it? Can't You just pull to your local repo and from there push to the git://git.overlays.gentoo.org/proj/gentoo-bashcomp.git ?
Created attachment 309923 [details, diff] Update equery module list drop 'glsa' and 'stats' add 'has' and 'keywords
Created attachment 309925 [details, diff] Completion for `equery has` options
Created attachment 309927 [details, diff] Preliminary support for `equery keywords`
Created attachment 309929 [details, diff] Proper calling of _pkgname() in `equery list`
Created attachment 309931 [details, diff] Check options in `equery list` further than just in $prev
Ok. Thanks. I pushed your updates, I don't see anything wrong if you have tested everything that you wrote.
(In reply to comment #18) > Ok. Thanks. I pushed your updates, I don't see anything wrong if you have > tested everything that you wrote. Yes, I've tested it. First two changes are really old (Dec 2010). Just out of curiosity: how did you push? I've noticed that commit messages have spaces instead of newlines now and SHAs are now different from original ones. If I can fix something in my vcs workflow with next submissions (they're coming really soon) jut tell me and I'll try :)
Well, by no means am I an expert at git. Here is what I did: 1) Clone your github repo 2) git format-patch -9 3) cd into git.overlays repo 4) git am .../github/000* 5) Reviewed git log then git pushed. Any advice?
When I plan on merging all of the changes I do the following: $ git checkout master $ git remote add <remote> <remote url> $ git fetch <remote> $ git merge <remote> $ git push origin master I find the help at github to be quite useful when trying to figure out the best way to do this stuff. One of the things I really like about git is as long as I don't do the git push, I can always start over if I mess anything up :)
