On Fri, Mar 13, 2015 at 4:28 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >>> static struct pathspec pathspec; >>> static const char *prefix; >>> @@ -22,7 +23,7 @@ static void add_one(struct string_list *result, const char *name) >>> struct strbuf sb = STRBUF_INIT; >>> struct string_list_item *item; >>> >>> - strbuf_addstr(&sb, name); >>> + quote_path_relative(name, prefix_length ? prefix : NULL, &sb); >>> item = string_list_append(result, strbuf_detach(&sb, NULL)); >>> item->util = (char *)name; >>> } >> >> Hmph, wouldn't it make it more cumbersome and problematic to do >> things like this here in add_one() phase? I am imagining that the >> endgame of this program will be >> >> - populate_cached_entries() reads from the data source (at this >> step, there is just "the index"), calling add_one() whose >> responsibility is to record the paths that are interesting >> to an in-core structure; >> >> - perform some interesting filtering, annotating, ordering, >> etc. (at this step, there is none) yet to come; >> >> - display() will iterate over the result and then format the >> result. >> >> For example, if you do the "quote" thing too early, don't codepaths >> in the later phases have to worry about item->string not matching >> the original pathname anymore? If you want to do something like >> "/bin/ls -t", you may have to lstat() the paths for each item, but >> if these store a path relative to the prefix, wouldn't you have to >> prepend the prefix again before running lstat()? >> >> I am just wondering if this prefix-stripping and quoting belongs to >> the output phase, not the input phase. > > Hmph, another interpretation of this patch is that your item->string > are not the true filenames but the result of applying some > interesting processing to the filenames and the true filenames are > kept in item->util. Is that what is going on? Exactly. We would need to sort and stuff later on, so true filenames are preserved in util->item. A cleaner way is perhaps carry all metadata in item->util and item->string remains true filename, then do all the formatting, coloring for all strings just before displaying. It seems a lot varying data to carry around. > If that is the case, it sort of makes sense to me, even though it > would feel a bit unusual way to use the string-list. > > Thanks. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html