On Fri, Jul 31, 2015 at 11:48 PM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote: > On Thu, Jul 30, 2015 at 2:57 AM, Matthieu Moy > <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> Karthik Nayak <karthik.188@xxxxxxxxx> writes: >> >>> What I was thinking of was something like this : >>> >>> struct strbuf format = STRBUF_INIT; >>> char c = ' '; >>> if (current) >>> c = '*'; >>> strbuf_addf(&format, "%c....", c, other format options...); >>> show_ref_array_item(item, format.buf, quote_style, 0); >>> strbuf_release(&format); >> >> I think that would interact badly with verify_ref_format(). Usually, you >> have just one format string and call verify_ref_format() on it, not a >> different format string for each ref_array_item. That would probably be >> solvable. >> > > Good point! I just was wondering if we need another atom just to print a star. > But your points certainly are valid. I'll implement this. Thanks :) > >>> This would remove the need of making the printing of the "*" to be >>> needed by ref-filter. As this is only needed in branch.c >>> >>> If going on what you're saying we could have a "%(starifcurrent)" atom or >>> something, but I don't see a general use for this. >> >> To have a really customizeable format, you would want to allow e.g. >> >> git branch --format '%(starifcurrent) %(objectname) %(refname)' >> >> if the user wants to get the sha1 before the refname, and still have the >> star in front. It's a bit frustrating to have a hardcoded format that >> the user can't reproduce with the --format option, since it means you >> can't easily make a small variation on it. >> > > Agreed. will have a "starifcurrent" atom :) > > -- Wonder if there is some sort of more "generic" atom that would work? I can't think of anything obvious at all though... it may be worth having this even though it definitely seems less useful generically, as the reason above where --format should be at least as expressive as the builtin formatting. Regards, Jake -- 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