ms have no immediate side effect, but only
s/pesudo/pseudo/. But if you are to rename these atoms to "modifier
atoms", you should get rid of this "pseudo" here.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe g
If you have other higher-priorities task, leave a temporary comment
/* FIXME: ... */ or /* TODO: ... */ and make sure you have no such
comment when you drop the "RFC" in the subject of your emails.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: sen
nd only this one. Similarly to what I suggested for
padright, I'd suggest
--format="%(refname:short)%(colornext:green)|%(refname:short)|%(refname:short)|"
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eset)]||foo1.6
> +EOF
> +
> +test_expect_success 'check `ifexists` with `colornext` format option' '
> + git for-each-ref
> --format="%(ifexists:[%s])%(colornext:green)%(refname:short)||%(refname:short)"
> | grep "foo" >actual &&
> +
; detached = (detached && (kinds & REF_LOCAL_BRANCH));
> if (detached && match_patterns(pattern, "HEAD"))
> - show_detached(&ref_list);
> + show_detached(&ref_list, maxwidth);
This hunks could ideally go in a prepara
**argv, const char
> *prefix)
> die(_("branch name required"));
> return delete_branches(argc, argv, delete > 1, kinds, quiet);
> } else if (list) {
> - int ret = print_ref_list(kinds, detached, verbose, abbrev,
> +
is the current branch", and the Boolean is turned
into presentation directives in a separate piece of code.
I'd write
char c;
int current = 0;
...
if (...)
current = 1;
...
case REF_DETACHED_HEAD:
current = 1;
...
and keep the last hunk.
(IOW, turn current from a parameter into a local variable)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to display the whole ref_array could
help. It would avoid having each caller write the 'for' loop)
Ideally, you could also have a modifier atom %(alignleft) that would
not need an argument and that would go through the ref_array to find the
maxwidth, and do the alignment. That would
F_LOCAL_BRANCH, "refs/heads/" },
> + { REF_REMOTE_BRANCH, "refs/remotes/" },
> + };
Nit: I would swap the order of fields, to make it a bit clearer that
this is a kind of dictionary key -> value (I think it's more common to
write it in this order tha
s[array->nr - 1];
>> + REALLOC_ARRAY(array->items, array->nr + 1);
>> + array->items[array->nr++] = ref;
>> +}
>
> This function belongs more to ref-filter.{c,h}...
The function disapears in the next commit, but I also think that this
function
expect_failure 'git branch does not show badly named ref' '
I'm not sure what's the convention, but I think the test description
should give the expected behavior even with test_expect_failure.
And please help the reviewers by saying what's the status wrt this test
(any plan on how to fix it?).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
allow a simple escaping like
\# this is a line starting with #
\\ this is a line starting with \
# this is a comment
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Actually, is there any reason why we do not allow a simple escaping like
>>
>> \# this is a line starting with #
>> \\ this is a line starting with \
>> # this is a comment
>
> What are we trying to ach
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 7:05 PM, Matthieu Moy
> wrote:
>
>> Ideally, you could also have a modifier atom %(alignleft) [...]
>
> This could work for refname, as each ref_array_item holds the refname,
> But other atoms are only filled in after a cal
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 6:31 PM, Matthieu Moy
> wrote:
>>
>>> -static void show_detached(struct ref_list *ref_list, int maxwidth)
>>> -{
>>> - struct commit *head_commit =
>>> lookup_commit_reference_gentl
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 6:39 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> We check if given ref is the current branch in print_ref_list(). Move
>>> this check to print_ref_item() where it is checked right before
>
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 7:18 PM, Matthieu Moy
> wrote:
>> Christian Couder writes:
>>
>>> On Tue, Jul 28, 2015 at 8:56 AM, Karthik Nayak
>>> wrote:
>>>
>>>> +static void ref_array_append(struct ref_array *ar
line that comes from the payload that begins with the
> core.commentchar or a backslash with a backslash.
That's it, probably the hardest part. No Git time budget for now, but
I'm adding this here in case I get time or a student to work on it:
http://git.wiki.kernel.org/index.php/SmallProj
Duy Nguyen writes:
> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy
> wrote:
>>> If the user wants whatever she types in the resulting commit
>>> literally, there is the "--cleanup=" option, no?
>>
>> $ GIT_EDITOR=touch git commit --cleanup=verbatim
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 7:47 PM, Matthieu Moy
> wrote:
>
>>> - qsort(array.items, index, sizeof(struct ref_array_item *), ref_cmp);
>>> + if (!sorting) {
>>> + def_sorting.next = NULL;
>>> +
Signed-off-by: Matthieu Moy
---
This is meant to be applied on top of kn/for-each-ref.
ref-filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 43502a4..3fbbbeb 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -868,8 +868,8 @@ static
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 7:47 PM, Matthieu Moy
> wrote:
>>
>> I'm not sure what's the convention, but I think the test description
>> should give the expected behavior even with test_expect_failure.
>>
>> And please help the
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Duy Nguyen writes:
>>
>>> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy
>>> wrote:
>>>>> If the user wants whatever she types in the resulting commit
>>>>> literally, ther
th a resend as
it should make it easier for new reviewers.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Karthik Nayak writes:
> On Wed, Jul 29, 2015 at 9:34 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> Ah, I hate making grammatical errors, Even though I check it always gets
>>> away.
>>> Anyways waiting for Junio and others to reply on
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Signed-off-by: Matthieu Moy
>> ---
>> This is meant to be applied on top of kn/for-each-ref.
>
> Hmm, as 2.5 is already out and we can rewind 'next' in the coming
> couple of days, I am tempted to squ
ince the content of the if/endif is a format string like the
others, it can use the same escaping rules (IIRC, %% to escape a %).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d format that
the user can't reproduce with the --format option, since it means you
can't easily make a small variation on it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next:blue)%(ifexists:[%s]) to color only the replacement of %s
and not the [].
But I now think that this would be more elegantly solved by Junio's
%(if) %(endif) idea:
%(if:atom) [ %(color:blue)%(atom)%(color:reset) ] %(endif)
(I added spaces for clarity)
--
Matthieu Moy
http://www-verim
set (currently true I
think), to avoid the risk of forgetting one value to reset.
I'm fine with the other way around too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Karthik Nayak writes:
> On Wed, Jul 29, 2015 at 9:26 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> On Tue, Jul 28, 2015 at 7:47 PM, Matthieu Moy
>>> wrote:
>>>>
>>>> I'm not sure what's the convention, but I
orgetting to reset, as
"use" and "reset" would be next to each other in the code.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
SV/...) and pipe it to a formatter written in a real
programming language. It will always be more powerful than having to
chose in a limited set of %(atoms).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;pencils down' date" is August 17th. The
"Firm 'pencils down date'" is on 21th, so things should stabilize.
On the "unify ref-listing commands" side, the big code movement is in
kn/for-each-ref which should hit master soon, but there are other less
in
mbiguous parsing of abbreviated options, bundled short
options, separate form options and to provide consistent usage help, use
git-rev-parse --parseopt for option parsing. With this, simplify the
option parsing code.
Signed-off-by: Paul Tan
Signed-off-by: Junio C Hamano
The previous code broke for example
git pull --upload-pack 'echo --foo'
Reported-by: Joey Hess
Fix-suggested-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
Junio wrote:
> ${upload_pack+"$upload_pack"} or something.
Indeed, we need to pass nothing, not the empty
think the test would be better with padright:15 for example, to
show that some lines are aligned and some go beyond the 15 columns.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Using a linked list of sorts where whenever a new modifier atom is
>encountered
>a new state is created, and once %(end) is encountered we can pop that
>state
>into the previous state.
Good, but keep in mind that this is not needed to port tag/branch, and your
GSoC end soon. So keep your
x8
>#define FILTER_REFS_DETACHED_HEAD 0x16
You meant 0x10, not 0x16 I guess.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ll
version, but that would probably deserve an additional test to enforce
the "Hopefully there will be no regressions" part of your message.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
Paul Tan writes:
> On Tue, Aug 18, 2015 at 5:36 PM, Matthieu Moy
> wrote:
>> I don't remember the details of the regression we had with the shell
>> version, but that would probably deserve an additional test to enforce
>> the "Hopefully there will be no
tag" and "git branch" are meant to be
simple commands, and the scary swiss-army-knife should remain "git
for-each-ref".
I am still (slightly) in favor of adding --format to tag and branch, as
long as it does not make the commands too scary.
--
Matthieu Moy
http://ww
a supporting atom"));
You error out on %(end) without %(align), but not on %(align) without
%(end).
You should probably check that the stack is empty at the end and error
out otherwise.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsub
f_filter *filter)
in ref-filter.c, since for-each-ref, branch and tag will eventually have
the same set of constraints on the options.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mv->handler)
atomv->handler(atomv, &state);
- append_atom(atomv, state);
+ else
+ append_atom(atomv, state);
}
if (*cp) {
sp = cp + strlen(cp);
Unless I missed something, this s
at the end "so that it
can be printed first.").
Perhaps "... so that it can be printed and removed first.".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs. This variable is not require as in
s/is not require/&d/
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line &q
stances always have the same value?
There's nothing to be pushed or poped with quote_style, so having it in
the stack is confusing to the reader (one has to infer the property "all
instances have the same value" by reading the code instead of having
just one variable), and error-p
Karthik Nayak writes:
> On Thu, Jul 30, 2015 at 12:59 PM, Matthieu Moy
> wrote:
>
>> IIRC, historicaly Git allowed some weirdly named refs which made some
>> commands ambiguous (e.g. a branch named after an option like '-d').
>> We're forbidding their
lly necessary, but it doesn't harm and it
makes sense since the escape sequence contains a '[' which is a shell
metacharacter.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
without a blank line:
foo: do something
Signed-off-by: Matthieu Moy
This breaks the convention "One summary line, one blank line, and then
body", and shows my sign-off in the output of "git log --oneline" :-(.
I think the behavior "don't insert a newline if the
r)
echo %(refname)
%(end)
'
I'm not sure what's best, but if both can make sense, perhaps we should
just keep the simplest to implement, i.e. the current behavior.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscrib
ubject line in `git log --oneline`. My command above
with a commit-msg hook outputs:
[master 86f32d5] place of: code: change we made Signed-off-by: Matthieu Moy
(on a single line)
I do not care deeply, but you may want to let interpret-trailers deal
with this case too.
Thanks,
--
Matth
The object that the new tag will refer to, usually a commit.
> Defaults to HEAD.
>
> +::
Shouldn't this be --format , not just ? We usually use
the named argument in the SYNOPSIS for positional arguments, but not for
arguments following an option.
--
Matthieu Moy
http://ww
d %(end) is quoted.
There's no --quote, there are --shell, --python, ... (well, actually, I
would have prefered to have a single --quote=language option, but that's
not how it is now).
I had already commented on a preliminary version of this series
off-list. I think all my previous comme
Karthik Nayak writes:
> On Mon, Aug 24, 2015 at 1:26 AM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> --- a/Documentation/git-tag.txt
>>> +++ b/Documentation/git-tag.txt
>>> @@ -13,7 +13,8 @@ SYNOPSIS
>>>[ | ]
>
Karthik Nayak writes:
> On Mon, Aug 24, 2015 at 1:30 AM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> diff --git a/Documentation/git-for-each-ref.txt
>>> b/Documentation/git-for-each-ref.txt
>>> index 1997657..06d468e 100644
>>&
stand if you made append_atom() the handler for a
> non-magic atoms, which would let you do the above without any if/else
> and just a single unconditional
I can't decide between "ah, very elegant" and "no, too much magic" ;-).
I lean towards the former.
--
Matthie
ut that will not work if the difference between local and remote
> format is not merely textual (e.g. paint them in different color).
Hmm, yes, colors would be difficult to get with this solution. Perhaps a
%(refname:autoprefix,autocolor) that would pick the color and do the
textual renderin
the line above.
# Everything below will be removed.
diff --git a/git-multimail/README b/git-multimail/README
index f41906b..93d4751 100644
Signed-off-by: Matthieu Moy
--- a/git-multimail/README
+++ b/git-multimail/README
Either commit-msg should be called after stripping the diff
.git/refs/heads/symref
$ git branch -a
* branch
master
symref -> branch
The only remaining difference I see are the "remotes/" prefix and
colors.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
)%(end)%(then)Empty%(else)Not
> Empty%(end)
> would print non-empty, I guess the documentation holds in that case.
> Not sure if we require it to print non-empty.
You don't want the %(if) condition to depend on whether
--shell/--python/... is used. Since %(if:empty)%(align)%(end)%
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>>> For the current code %(if:empty)%(align)%(end)%(then)Empty%(else)Not
>>>> Empty%(end)
>>>> would print non-empty, I guess the documentation holds in that c
es doesn't work" (that's how I considered it for a while,
it took me a few commits to notice the correlation between "-v" and lack
of sign-off).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
contents:lines=1)"
> >actual &&
> + test_cmp expect actual
> +'
Nit: I would find it more readable with an actual separator (anything
but a space) between %(refname) and %(contents).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--format
'x=%(if)%(align:10)%(end)%(then)%(align:10)XXX%(end)%(else)%(end)' --shell
zsh: segmentation fault
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
been there for a while and unless I missed a discussion,
nothing happened. While I agree that Michael's idea is good and makes
this series less useful, I think this topic also makes sense.
I'd be in favor of merging it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubs
have.
But no one stepped in to implement it until now ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ies was a tough one for this, so I'm not
even sure my advice would have been applicable ^^.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hes IMHO.
The patch works for me, thanks.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Couder writes:
> This first patch is already in master. That's why I only sent the
> second one. But yeah I could have explained that after the three
> dashes.
OK, my bad, I should have "git fetch"ed.
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> * ad/bisect-terms (2015-08-03) 4 commits
>>> - bisect: allow setting any user-specified in 'git bisect start'
>>> - bisect: add 'git bisect terms
pectation.
It's a bit worse than it seems: without this change, using --format
'%(align)%(end)' results in Git complaining about %(end) without
matching atom, which is really confusing since you do have a %(align) (I
got it for real while testing a preliminary version).
> T
die(_("format: usage %%(align:,)"));
> else
> valp++;
> ..
>
> }
Checking the string's correctness as you read it seems good to me, yes.
But as you say, you should make this a bit more generic, for example by
putting yo
is GSoC as a great success and a pleasant experience.
Congratulation to Paul and Karthik, and a warm "thank you" to everybody
who contributed: administrators, mentors, reviewers, and obviously
Junio! (not to mention Google, who made all this possible)
Thanks all!
--
Matthieu Moy
http://www-
odd/spot |
> + | double-tag |
> + | four |
> + |one |
> + | signed-tag |
> + | three |
> + |two |
> + EOF
ler for
the same thing.
> + if (state.stack->prev)
> + die(_("format: `end` atom missing"));
Perhaps spell it %(end) instead of just end.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
const char *sp, *eol;
> + size_t len;
> +
> + if ((sp = strstr(buf, "\n\n")) && (sp <= buf + size))
> + size += 2;
Why is this "size += 2" needed?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the
Nice :-).
(I'd cut the string argument to xstrfmt after "%(end)" to avoid long
line)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
es as such.
>
> Wouldn't it be something that would be caught in the same codepath
> as what catches %(unrecognized) in the format string?
After thinking about it, I agree with Karthik: if we get the same
codepath to complain about %(nosuchatom) and %(align), then we won't be
able t
Karthik Nayak writes:
> On Wed, Sep 2, 2015 at 2:15 PM, Matthieu Moy
>>> @@ -754,6 +816,42 @@ static void populate_value(struct ref_array_item *ref)
>>> else
>>> v->s = " ";
>>>
Karthik Nayak writes:
> On Wed, Sep 2, 2015 at 2:37 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> --- a/builtin/tag.c
>>> +++ b/builtin/tag.c
>>> @@ -185,6 +185,10 @@ static enum contains_result contains(struct commit
>>> *can
ign:16,left)%(refname:short) %(end)";
I actually found the other more readable, as it reads "display the
refname aligned on 15 columns, and then a space", while this one reads
as "append a space to the refname, then align the result", which is
equivalent but requires more effort t
comment.
I don't really have a better proposal either. What we really mean is
"%(end) requires an atom that requires to be paired with %(end)", but
that wouldn't really help. I prefer "supporting" to "modifier":
To me, %(color:red) can be called a "mod
eliminate the signature if existing also.
Indeed. I thought body did not include the signature.
I'd write it as
bodylen + bodypos - siglen - subpos
or even
char *contents_end = bodylen + bodypos - siglen;
...
append_lines(&s, subpos, contents_end - subpos, ...);
to make i
ly, we're already making the assumption that the buffer for the
whole tag object is null-terminated (and contains no '\0') for
%(contents):
else if (!strcmp(name, "contents"))
v->s = xstrdup(subpos);
(But I agree that even if the assumption is
r is there, but after the signature. buf + size points
before the signature.
Anyway, all this should go away if Karthik applies my suggestion, which
I like even more after this discussion ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "uns
the amount of change from iteration to iteration.
I'd add one item:
* We limited the number of slots. A successful GSoC has to be a lot of
work for many people (student, mentor, reviewer, maintainer). We have
a limited bandwidth to deal with the GSoC, and I think that focusing
on a smal
ll --format="refname is
> %(align:30,middle)${sq}%(refname:short)${sq}%(end)|" >actual &&
> + git for-each-ref --shell --format='|%(align:30,middle)%(refname:short)|
> %(authorname)%(end)|' >actual &&
> test_cmp expect actual
> -'
nse to me to leave the series as-is and to move some of the
explanations in a general section in the next series (that will
introduce %(if) or another opening atom).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
"%%(contents:lines=%d)",
>>> filter->lines);
>>
>> This line still looks overlong. Would it help to stop spelling this
>> as a double "a = b = overlong expression" assignment?
>>
>
> I'm not sure, I get what you mean.
I guess
f
ns-by: Elijah Newren
Signed-off-by: Matthieu Moy
---
This patch is not meant to be merged in master, but it probably makes
sense to get it in pu to give it some exposure and allow people to
provide feedback before the final release.
I'm tagging this as "Alpha" because the UI may still
ite a test for the same.
>
> Mentored-by: Christian Couder
> Mentored-by: Matthieu Moy
> Thanks-to: Junio C Hamano
> Signed-off-by: Karthik Nayak
> ---
> ref-filter.c | 23 +--
> t/t6302-for-each-ref-filter.sh | 4
> 2 files changed,
ing ',' */ here would really help the
reader IMHO.
> + strbuf_setlen(s[0], s[0]->len - 1);
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ggest ;-) ) that you reply to
them by re-sending only individual patches that changed (replying to the
original patch) so that we can check the new patches individually. I
think we can do the finishing touches for each patch in a subthread of
this patch.
--
Matthieu Moy
http://www-verimag.imag.fr/
gt; is correct *ONLY* when name is "refname" or "refname:" followed by
> something, and it should skip "refnamex" when such a new atom is
> added to valid_atom[] list, i.e. a bug waiting to happen. I think
> the new helper is designed to prevent such a bug fr
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> OTOH, you are now accepting %(atom:) as a synonym to %(atom), and it's
>> not clear whether this is a deliberate decition.
>
> I would say so. When the caller wants to reject %(atom:), the
> caller can tell i
John Keeping writes:
> John Keeping (2):
> rebase: support --no-autostash
> Documentation/git-rebase: fix --no-autostash formatting
Looks good to me, thanks.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git&quo
Karthik Nayak writes:
> On Thu, Sep 10, 2015 at 10:27 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> This is part of the series of unifying the code used by
>>> "git tag -l, git branch -l, git for-each-ref".
>>>
ning?
In any case, that remark is not an objection on your patch, but I'd like
to understand.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 2167 matches
Mail list logo
