Re: [PATCH/RFC 00/10] ref-filter: use parsing functions

On Fri, Dec 11, 2015 at 5:49 PM, Junio C Hamano wrote: > Karthik Nayak writes: >> ref-filter: introduce a parsing function for each atom in valid_atom >> ref-filter: introduce struct used_atom >> ref-fitler: bump match_atom() name to the top >>

Re: [PATCH/RFC 08/10] ref-filter: introduce remote_ref_atom_parser()

On Sun, Dec 13, 2015 at 1:02 AM, Karthik Nayak wrote: > On Sun, Dec 13, 2015 at 6:23 AM, Eric Sunshine > wrote: >> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >>> + if (!num_ours && !num_theirs) >>>

Re: [PATCH/RFC 10/10] ref-filter: introduce objectname_atom_parser()

On Wed, Nov 25, 2015 at 8:44 AM, Karthik Nayak wrote: > Introduce objectname_atom_parser() which will parse the > '%(objectname)' atom and store information into the 'used_atom' > structure based on the modifiers used along with the atom. > > Signed-off-by: Karthik Nayak

Re: [PATCH/RFC 08/10] ref-filter: introduce remote_ref_atom_parser()

On Sun, Dec 13, 2015 at 6:23 AM, Eric Sunshine wrote: > On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >> Introduce remote_ref_atom_parser() which will parse the '%(upstream)' >> and '%(push)' atoms and store information into the 'used_atom'

Re: [PATCH/RFC 09/10] ref-filter: introduce contents_atom_parser()

On Sat, Dec 12, 2015 at 10:10 PM, Eric Sunshine wrote: > On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >> +void contents_atom_parser(struct used_atom *atom) >> +{ >> + const char * buf; >> + >> + if (match_atom_name(atom->str,

Re: [PATCH/RFC 05/10] ref-filter: introduce color_atom_parser()

On Thu, Dec 3, 2015 at 8:35 AM, Karthik Nayak wrote: > On Wed, Dec 2, 2015 at 4:57 AM, Eric Sunshine wrote: >> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: >>> @@ -833,11 +846,10 @@ static void populate_value(struct

Re: [PATCH 2/8] update-index: use enum for untracked cache options

On Fri, Dec 11, 2015 at 6:44 PM, Junio C Hamano wrote: > Christian Couder writes: > >>> As you know I am bad at bikeshedding; the only suggestion in the >>> above is to have common UC_ prefix ;-) Don't take what follow UC_ >>> as my suggestion. >>

Re: [PATCH/RFC 01/10] ref-filter: introduce a parsing function for each atom in valid_atom

On Sat, Dec 12, 2015 at 3:48 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >>> This problem will go away if you introduce the 'valid_atom' field in >>> the patch which actually needs it (as suggested above) rather than in >>> this patch. >> >> Yup,

Re: [PATCH/RFC 06/10] strbuf: introduce strbuf_split_str_without_term()

On Sat, Dec 12, 2015 at 4:01 AM, Junio C Hamano wrote: > Karthik Nayak writes: > diff --git a/ref-filter.c b/ref-filter.c @@ -892,14 +892,11 @@ static void populate_value(struct ref_array_item *ref) * TODO:

[No Subject]

Currently funding business and personal loans: * At superb rates; starting from 2.09%. * Flexible repayment period; up to 30 years. For more info and application, kindly contact me back via this email: bkrenfi...@gmail.com To un-subscribe please reply with "un-subscribe" as subject. -- To

[PATCH] refs: mark some symbols static

Signed-off-by: Ramsay Jones --- Hi David, If you need to re-roll your 'dt/refs-backend-lmdb' branch, could you please squash the relevant parts of this patch into yours. [yes, I didn't reference the movement of the external declaration in the commit message! :-D ]

What's "wrong" with this fast-import?

Hello! I'm trying to track down an issue with the Fossil SCM, specifically the export feature that can produce the fast-import files consumed by Git. The symptom of the bug seems to be that if a branch B is created from branch A, files committed to B, and then B merged with A, the committed

Re: [PATCH/RFC 09/10] ref-filter: introduce contents_atom_parser()

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: > Introduce contents_atom_parser() which will parse the '%(contents)' > atom and store information into the 'used_atom' structure based on the > modifiers used along with the atom. > > Signed-off-by: Karthik Nayak

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:57 PM, Edmundo Carmona Antoranz wrote: > --progress can't be used with --incremental or > porcelain formats. > > git-annotate inherits the option as well > > Helped-by: Eric Sunshine > Signed-off-by: Edmundo Carmona

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:17 PM, Eric Sunshine wrote: > Right here below the "---" line would be a good place to explain what > changed since the previous version. As an aid for reviewers, it's also > helpful to provide a link to the previous round, like this[1]. > > [1]:

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 7:30 PM, Edmundo Carmona Antoranz wrote: > On Sat, Dec 12, 2015 at 6:17 PM, Eric Sunshine > wrote: >> The 'show_progress = 0' seems unnecessary. What if you did something >> like this instead? >> >> if (show_progress > 0

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:30 PM, Edmundo Carmona Antoranz wrote: >> >> The 'show_progress = 0' seems unnecessary. What if you did something >> like this instead? >> >> if (show_progress > 0 && (incremental || >> (output_option & OUTPUT_PORCELAIN))) >>

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:37 PM, Eric Sunshine wrote: >> >> Because, if the user didn't provide --[no-]progress option, then the >> value in show_progress will move forward being -1 and then in >> assign_blame, there will be progress output if you chose --incremental >>

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 7:36 PM, Edmundo Carmona Antoranz wrote: > On Sat, Dec 12, 2015 at 6:30 PM, Edmundo Carmona Antoranz > wrote: > H if the code in assign_blame changed to this, it would be > possible to allow the -1 to go through: > > if

[PATCH v7] blame: add support for --[no-]progress option

--progress can't be used with --incremental or porcelain formats. git-annotate inherits the option as well Helped-by: Eric Sunshine Signed-off-by: Edmundo Carmona Antoranz --- Documentation/blame-options.txt | 7 +++

Re: [PATCH/RFC 08/10] ref-filter: introduce remote_ref_atom_parser()

On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak wrote: > Introduce remote_ref_atom_parser() which will parse the '%(upstream)' > and '%(push)' atoms and store information into the 'used_atom' > structure based on the modifiers used along with the corresponding > atom. > >

Re: What's "wrong" with this fast-import?

> The symptom of the bug seems to be that if a branch B is created from > branch A, files committed to B, and then B merged with A, the committed > files are not present in the head of A. fast-import's 'merge' command doesn't actually perform a merge, it merely records that the new commit has one

Re: [PATCH] completion: fix completing unstuck email alias arguments

Quoting Jacob Keller : On Fri, Dec 11, 2015 at 4:18 PM, SZEDER Gábor wrote: Completing unstuck form of email aliases doesn't quite work: $ git send-email --to alice bob cecil $ git send-email --to a alice bob cecil Woops. Is it

[PATCH v6] blame: add support for --[no-]progress option

--progress can't be used with --incremental or porcelain formats. git-annotate inherits the option as well Helped-by: Eric Sunshine Signed-off-by: Edmundo Carmona Antoranz --- Documentation/blame-options.txt | 7 +++

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 5:57 PM, Edmundo Carmona Antoranz wrote: > + if (incremental || (output_option & OUTPUT_PORCELAIN)) { > + if (show_progress > 0) > + die("--progress can't be used with --incremental or > porcelain formats"); >