On Mon, Oct 19, 2015 at 1:42 PM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> I personally would suggest whichever order you feel more comfortable
>> and less error-prone.
>
> This is a good summary, and I fully agree with it.
Well then, I'm working on the parsing part of it before this ser
Junio C Hamano writes:
> I personally would suggest whichever order you feel more comfortable
> and less error-prone.
This is a good summary, and I fully agree with it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Karthik Nayak writes:
> ... While doing so I realized I was moving a lot of code around
> and this had me thinking it's perhaps easier to do the cleaning up
> first as Junio suggested.
>
> Maybe then it'd be simpler to do implement this rather than move
> code around now and then move code aroun
On Tue, Oct 13, 2015 at 12:37 AM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> If you design a new infrastructure to help refactoring early
>> (i.e. before adding many copies of code that need to be cleaned up
>> later), it would make the work of reviewing of the design of the
>> helper and
Junio C Hamano writes:
> If you design a new infrastructure to help refactoring early
> (i.e. before adding many copies of code that need to be cleaned up
> later), it would make the work of reviewing of the design of the
> helper and refactoring using that helper smaller, not larger.
But most o
Matthieu Moy writes:
> Karthik Nayak writes:
>
>> On Mon, Oct 12, 2015 at 6:06 AM, Junio C Hamano wrote:
>>> Karthik Nayak writes:
>>>
On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano wrote:
...
Also does it make sense to integrate these changes here? Or would you like
to
Karthik Nayak writes:
> On Mon, Oct 12, 2015 at 6:06 AM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>
>>> On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano wrote:
>>> ...
>>> Also does it make sense to integrate these changes here? Or would you like
>>> to
>>> have another series on this?
On Mon, Oct 12, 2015 at 6:06 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano wrote:
>> ...
>> Also does it make sense to integrate these changes here? Or would you like to
>> have another series on this?
>
> I do not think you would want to
Karthik Nayak writes:
> On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano wrote:
> ...
> Also does it make sense to integrate these changes here? Or would you like to
> have another series on this?
I do not think you would want to ask that question, as my answer
would most likely be "The most pre
On Mon, Oct 12, 2015 at 1:02 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Sun, Oct 11, 2015 at 9:51 PM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
Also does it make sense to integrate these changes here? Or would you like
to
have another series on this?
>>>
Karthik Nayak writes:
> On Sun, Oct 11, 2015 at 9:51 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> Also does it make sense to integrate these changes here? Or would you like
>>> to
>>> have another series on this?
>>
>> To me, the important in this series is to avoid introducing du
On Sun, Oct 11, 2015 at 9:51 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Also does it make sense to integrate these changes here? Or would you like to
>> have another series on this?
>
> To me, the important in this series is to avoid introducing duplicated
> and inconsistent code, becau
Karthik Nayak writes:
> Also does it make sense to integrate these changes here? Or would you like to
> have another series on this?
To me, the important in this series is to avoid introducing duplicated
and inconsistent code, because it would make further refactoring harder.
But this series st
On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Then used_atom[] could become something like
>>>
>>> struct {
>>> const char *str; /* e.g. "align:position=left,32" */
>>> struct {
>>> const char *part0; /
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Then used_atom[] could become something like
>>
>> struct {
>> const char *str; /* e.g. "align:position=left,32" */
>> struct {
>> const char *part0; /* everything before '=' */
>> const char *part1; /*
Junio C Hamano writes:
> Then used_atom[] could become something like
>
> struct {
> const char *str; /* e.g. "align:position=left,32" */
> struct {
> const char *part0; /* everything before '=' */
> const char *part1; /* optional */
> } *modifi
Karthik Nayak writes:
> No i mean I could follow up with the way we use it in align, but I don't see
> how I can make a function out of this.
At least you should be able to pre-parse the %(:)
construct, instead of doing strcmp() every time populate_value() is
called, no? Then your parser would
Karthik Nayak writes:
> On Thu, Oct 8, 2015 at 10:40 PM, Matthieu Moy
> wrote:
>
>> This particular piece of code is so important and I won't fight for a
>> better factored one, but in general "there are only two instances" is a
>> dubious argument to avoid refactoring.
>>
>> Still, I find it we
On Thu, Oct 8, 2015 at 10:40 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Thu, Oct 8, 2015 at 5:57 PM, Matthieu Moy
>> wrote:
+ unsigned int nobracket = 0;
+
+ if (!strcmp(valp, ",nobracket"))
+
Karthik Nayak writes:
> On Thu, Oct 8, 2015 at 5:57 PM, Matthieu Moy
> wrote:
>>> + unsigned int nobracket = 0;
>>> +
>>> + if (!strcmp(valp, ",nobracket"))
>>> + nobracket = 1;
>>
>> The code to parse co
On Thu, Oct 8, 2015 at 5:57 PM, Matthieu Moy
wrote:
>> + unsigned int nobracket = 0;
>> +
>> + if (!strcmp(valp, ",nobracket"))
>> + nobracket = 1;
>
> The code to parse comma-separated values is different
On Thu, Oct 8, 2015 at 5:57 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> +An example to show the usage of %(if)...%(then)...%(else)...%(end).
>> +This prefixes the current branch with a star.
>> +
>> +
>> +#!/bin/sh
>> +
>> +git for-each-ref --format="%(if)%(HEAD)%(then)* %(el
Karthik Nayak writes:
> +An example to show the usage of %(if)...%(then)...%(else)...%(end).
> +This prefixes the current branch with a star.
> +
> +
> +#!/bin/sh
> +
> +git for-each-ref --format="%(if)%(HEAD)%(then)* %(else)
> %(end)%(refname:short)" refs/heads/
I don't think the
This is part of unification of the commands 'git tag -l, git branch -l
and git for-each-ref'. This ports over branch.c to use ref-filter's
printing options. The previous version of the patch can be found at:
http://article.gmane.org/gmane.comp.version-control.git/278926
Karthik Nayak (10):
ref-f
24 matches
Mail list logo
