ITS ALL ABOUT FACEBOOK
Hello, Facebook is given out 14,000,000.USD (Fourteen Million Dollars) its all about 14 Please, respond with your Unique Code (FB/BF14-13M5250UD) using your registration email, to the Verification Department at; dustinmoskovitz.facebo...@gmail.com Dustin Moskovitz Facebook Team Copyright © 2018 Facebook Int'l
Re: [PATCH] completion: add option completion for most builtin commands
On Wed, Mar 21, 2018 at 9:59 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> These commands can take options and use parse-options so it's quite
>> easy to allow option completion. This does not pollute the command
>> name completion though. "git " will show you the same set as
>> before. This only kicks in when you type the correct command name.
>>
>> Some other builtin commands are not still added because either they
>> don't use parse-options, or they are deprecated, or they are those
>> -helper commands that are used to move some logic back in C for
>> sh-based commands.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> contrib/completion/git-completion.bash | 276 +
>> 1 file changed, 276 insertions(+)
>
> Wow, just wow. It however looks a lot of boilerplates, e.g. looking
> at these, we notice ...
>
>> +_git_blame() {
>> + case "$cur" in
>> + --*)
>> + __gitcomp_builtin blame
>> + return
>> + ;;
>> + esac
>> +}
>> +
>>
>> +_git_cat_file() {
>> + case "$cur" in
>> + --*)
>> + __gitcomp_builtin cat-file
>> + return
>> + ;;
>> + esac
>> +}
>> +
>> +_git_check_attr() {
>> + case "$cur" in
>> + --*)
>> + __gitcomp_builtin check-attr
>> + return
>> + ;;
>> + esac
>> +}
>
> ... the only thing we need for the above three is a table that says
> "use blame for blame, cat-file for cat_file, and check-attr for
> check_attr".
>
> And that pattern repeats throughout the patch. I wonder if we can
> express the same a lot more concisely by updating the caller that
> calls these command specific helpers?
>
Yeah. I almost went to just generate and eval these functions. But we
still need to keep a list of "bultin with --git-completion-helper"
support somewhere, and people may want to complete arguments without
double dashes (e.g. read-tree should take a ref...) which can't be
helped by --git-completion-helper.
--
Duy
Re: [PATCH v2] routines to generate JSON data
On Wed, Mar 21, 2018 at 07:28:26PM +, g...@jeffhostetler.com wrote: > It includes a new "struct json_writer" which is used to guide the > accumulation of JSON data -- knowing whether an object or array is > currently being composed. This allows error checking during construction. > > It also allows construction of nested structures using an inline model (in > addition to the original bottom-up composition). > > The test helper has been updated to include both the original unit tests and > a new scripting API to allow individual tests to be written directly in our > t/t*.sh shell scripts. Thanks for all of this. The changes look quite sensible to me (I do still suspect we could do the "first_item" thing without having to allocate, but I really like the assertions you were able to put in). > So I think for our uses here, defining this as "JSON-like" is probably the > best answer. We write the strings as we received them (from the file system, > the index, or whatever). These strings are properly escaped WRT double > quotes, backslashes, and control characters, so we shouldn't have an issue > with decoders getting out of sync -- only with them rejecting non-UTF-8 > sequences. Yeah, I think I've come to the same conclusion. My main goal in raising it now was to see if there was some other format we might use before we go too far down the JSON road. But as far as I can tell there really isn't another good option. > WRT binary data, I had not intended using this for binary data. And without > knowing what kinds or quantity of binary data we might use it for, I'd like > to ignore this for now. Yeah, I don't have any plans here either. I was thinking more about things like author names and file paths. -Peff
