ssage is not sufficient: there
is a behavioral change. I'm OK with it, but the commit message shouldn't
claim that there isn't.
Porting to ref-filter drops the commit before we get an opportunity to
complain, so we stop complaining because it's not worth the trouble.
BTW, this looks like an fsck bu
return 1;
>>> + }
>>> strbuf_add(>buf, target, end - target);
>>> return 1;
>>> }
>>>
>>> What do you think?
>
> I think we should return (the hex repr. of) nsha1 instead of resolving
> HEAD at its current state
Karthik Nayak <karthik@gmail.com> writes:
> On Mon, Sep 21, 2015 at 12:30 AM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> --- a/t/t3203-branch-output.sh
>>> +++
tem is the current ref */
This relies on the fact that sorting (qsort above) did not move HEAD
from its first position. This is OK, as we don't have a --sort option
yet. Good.
--
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
It may make sense to split the commit into several smaller ones, so that
you can give a precise commit message for each error reporting you
remove (error(_("branch '%s' does not point at a commit") and
error(_("some refs could not be read"))).
--
Matthieu Moy
http://www-verima
ing about it, I think
this is actually sensible. After all, if we ever allow FETCH_HEAD, then
keeping the alphabetical order still makes sense.
So, your code is OK, but a bit too subtle to my taste: you should add a
comment explaining why sorting according to refname is sufficient (I
would use a c
ctsize=167.
So, the previous code was hardcoding "detached HEAD always comes first",
but we now sort the whole list, including detached HEAD, so branch-two
comes first.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git&
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-cherry-pick.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-merge.txt | 2 +-
Documentation/git-revert.txt | 6 +++---
Documentation/git-tag.txt | 18 +--
gn between the option and its argument.
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-am.txt | 4 +++-
Documentation/git-cherry-pick.txt | 4 +++-
Documentation/git-commit-tree.txt | 4 +++-
Documentation/git-commit.txt | 4 +++-
Documentation/git-gre
nal
argument is not specified.
Matthieu Moy (3):
Documentation: use 'keyid' consistently, not 'key-id'
Documentation/grep: fix documentation of -O
Documentation: explain optional arguments better
Documentation/git-am.txt | 4 +++-
Documentation/git-cherry-pick.txt |
Since the argument of -O, --open-file-in-pager is optional, it must be
stuck to the command. Reflect this in the documentation.
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-grep.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documen
Jeff King <p...@peff.net> writes:
> On Thu, Sep 17, 2015 at 04:27:39PM +0200, Matthieu Moy wrote:
>
>> > Therefore I would argue that -u is behaving differently from other
>> > arguments (especially when considered across all git subcommands)
>>
>>
this option:
>>
>> The `commit` may be omitted if this is the final argument.
>
> "may be omitted" must be followed by a description of what happens
> when omitted (i.e. "defaults to ...").
Then:
The `commit` may be omitted and defaults to HEAD
John Keeping <j...@keeping.me.uk> writes:
> On Fri, Sep 18, 2015 at 09:10:08AM +0200, Matthieu Moy wrote:
>
>> The `commit` may be omitted and defaults to HEAD if this is the final
>> argument.
>
> I find that slightly confusing, although that might just be me.
Stefan Beller <sbel...@google.com> writes:
> On Fri, Sep 18, 2015 at 10:23 AM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Jacob Keller <jacob.kel...@gmail.com> writes:
>>
>>> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
>>>
n optional argument: they are the most error prone since there is no '='
sign between the option and its argument.
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-am.txt | 3 ++-
Documentation/git-cherry-pick.txt | 3 ++-
Documentation/git-commit-tree.txt | 3 ++
Since the argument of -O, --open-file-in-pager is optional, it must be
stuck to the command. Reflect this in the documentation.
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-grep.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documen
ved sha1 here before, but I'm getting the same with latest Git in
master and Git 2.0, so it doesn't seem to be new.
I'm getting it even if there's a tag and/or a branch pointing to the
same commit.
Any idea what's going on?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this
The first patch is essentially to make the last one look good. The
second is a real documentation bug. The last one may be controversial
as it re-documents something already documented in gitcli, but I think
it's a good thing.
Matthieu Moy (3):
Documentation: use 'keyid' consistantly, not 'key
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
Documentation/git-cherry-pick.txt | 4 ++--
Documentation/git-revert.txt | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index 1
Subject: ... use 'keyid' consistantly
Sorry, should s/consistantly/consistently/. Will resend.
--
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 inf
Karthik Nayak <karthik@gmail.com> writes:
> On Fri, Sep 18, 2015 at 8:49 PM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> Not sure this is much of a problem with regards to "-
no-foo" is equivalent to "git command".
Here, --no-merged=some-ref does not _cancel_ the effect but introduce a
new behavior that was not the default. So it may make sense to explain
this more clearly.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send
Karthik Nayak <karthik@gmail.com> writes:
> About the issue at hand, we should probably squash this in
Looks good to me.
--
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
Jacob Keller <jacob.kel...@gmail.com> writes:
> On Fri, Sep 18, 2015 at 9:59 AM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> I'm getting it even if there's a tag and/or a branch pointing to the
>> same commit.
>>
>> Any idea what's goin
does nothing. Unfortunately, strtoul silently accepts negative
values, and as a result strtoul_ui("-1", ...) raised no error.
This patch catches negative values before it's too late, i.e. before
calling strtoul.
Reported-by: Max Kirillov <m...@max630.net>
Signed-off-by: Matthi
jects any string that contain the character '-', regardless of
trailing spaces.
>> ul = strtoul(s, , base);
>> if (errno || *p || p == s || (unsigned int) ul != ul)
>> return -1;
>
> Hmm, but we check *p here, so IIUC it's an error if the string has any
Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu@grenoble-inp.fr> writes:
>
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> So either we could introduce a new atom for sorting something like
>>> `branch_sort
ot;unsigned int".
Reported-by: Max Kirillov <m...@max630.net>
Signed-off-by: Matthieu Moy <matthieu@imag.fr>
---
So, here's a proper patch (I mean, a band-aid patch, but properly
send ;-) ).
It should be merged before Kartik's series (or inserted at the start
of the series) so tha
rt authorname"
would not use this new atom, hence the HEAD would be sorted like the
others. I don't know if this is good or bad.
--
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...@
source correctly, the only options accepting a short
version and an optional string argument are "{merge,am,commit,revert}
-S", "grep -O" and "status -u", which behave consistantly.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the
Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu@grenoble-inp.fr> writes:
>
>> But that's still workable: struct ref_sorting could contain a flag
>> "head_first" that would be set by ref_default_sorting() and only it, and
>> the
Max Kirillov <m...@max630.net> writes:
> On Tue, Sep 15, 2015 at 08:50:03AM +0200, Matthieu Moy wrote:
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -814,6 +814,9 @@ static inline int strtoul_ui(char const *s, int base,
>> unsigne
[ Cc-ing Michael Haggerty who wrote the numparse module ]
Max Kirillov <m...@max630.net> writes:
> On Mon, Sep 14, 2015 at 08:30:54AM +0200, Matthieu Moy wrote:
>>> Fix it by changing the last check to trigger earlier, as soon as it
>>> becomes bigger than INT_MA
emove
> the ^ and it will work as expected
I think the test is correct.
In grep, ^ can have two meanings:
'^foo' means "foo at the start of a line"
'[^abc]' means "one character but not a, b or c"
The Signed-off-by: trailer is meant to be at the start of a line, hence
the
ibute to a project like Git.
--
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
n't need to know if it was a real message or a collective
hallucination ;-).
--
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
nterval ]2^63, 2^64].
The other option would be to look for a leading '-' before calling
strtoul.
(Actually, this makes me wonder why strtoul happily returns a big
positive when fed with the string "-1", but we can't change it)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To uns
g?
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
Karthik Nayak <karthik@gmail.com> writes:
> Happy to explain.
Thanks for the clarification.
--
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 majo
uboptimal (but still acceptable to me at least).
--
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
elatively clear that this makes the code closer to the
shape expected by ref-filter, but if you imagine someone bisecting or
blaming and finding this commit in another context, that person may
appreciate more explanation.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
int current = !detached && (ref_list.list[i].kind ==
> REF_LOCAL_BRANCH) &&
> !strcmp(ref_list.list[i].name, head);
> print_ref_item(_list.list[i], maxwidth, verbose,
> abbrev, current, remot
Karthik Nayak <karthik@gmail.com> writes:
> On Sun, Sep 13, 2015 at 5:56 PM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> /* Print detached HEAD before sorting an
Karthik Nayak <karthik@gmail.com> writes:
> On Thu, Sep 10, 2015 at 10:27 PM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> This is part of the series of unifying the code used by
>
John Keeping <j...@keeping.me.uk> 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 li
> atom. Write a test for the same.
>
> Mentored-by: Christian Couder <christian.cou...@gmail.com>
> Mentored-by: Matthieu Moy <matthieu@grenoble-inp.fr>
> Thanks-to: Junio C Hamano <gits...@pobox.com>
> Signed-off-by: Karthik Nayak <karthik
',' */ 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
e new helper is designed to prevent such a bug from happening.
I fully agree, but I also think that this should be a separate topic.
--
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
suggested of-list to suggest ;-) ) 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
h
Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu@grenoble-inp.fr> 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. Wh
ions-by: Paul Sokolovsky <paul.sokolov...@linaro.org>
Contributions-by: Vadim Zeitlin <va...@zeitlins.org>
Contributions-by: Edward d'Auvergne <edw...@nmr-relax.com>
Contributions-by: Elijah Newren <new...@palantir.com>
Signed-off-by: Matthieu Moy <matthieu@imag.fr&
%(end) pair, so it
makes sense 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 &
;
> I'm not sure, I get what you mean.
I guess
format = xstrfmt("%%(align:15,left)%%(refname:short)%%(end)
%%(contents:lines=%d)",
filter->lines);
to_free = format;
(still 83 columns + indentation, but that's a bit shorter than your
version).
--
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
&&
> + git for-each-ref --shell --format='|%(align:30,middle)%(refname:short)|
> %(authorname)%(end)|' >actual &&
> test_cmp expect actual
> -'
> +"
The new test is indeed easier to read, but you're not testing anymore
the consequence of a single-quote with
elped too. I was
amazed by 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 tha
.lines);
>
> We need to 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(, subpos, contents_end - subpos, ...);
to
.
The null character 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
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 correct, it should be made
expl
.) is simpler 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
t i;
> + 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
|
> + | four |
> + |one |
> + | signed-tag |
> + | three |
> + |two |
> + EOF
> + git for-each-ref
> --format="|%(align:30,left)%(align:15
rmat, 0);
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
; without any
>> subvalues 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
up with a good wording ;-). That is why the message was Cc'ed to
> the list for others to 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 "suppor
t)%(refname:short)%(end)";
> +format = "%(align: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, th
Karthik Nayak <karthik@gmail.com> 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 <karthik@gmail.com> writes:
> On Wed, Sep 2, 2015 at 2:37 PM, Matthieu Moy
> <matthieu@grenoble-inp.fr> wrote:
>> Karthik Nayak <karthik@gmail.com> writes:
>>
>>> --- a/builtin/tag.c
>>> +++ b/builtin/tag.c
>>
C 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-verima
ting your "if/else" in a helper function, that other atoms could use.
--
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
rt) %(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 lis
: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
Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gits...@pobox.com> writes:
>>
>>> * ad/bisect-terms (2015-08-03) 4 commits
>>> - bisect: allow setting any user-specifie
s may indeed be a good idea, however,
> the current behavior isn't a huge problem since user discovers the
> error when the output fails to match his expectation.
It's a bit worse than it seems: without this change, using --format
'%(align)%(end)' results in Git complaining about %
ould be simpler to resend both patches 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
based one we currently 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
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
ss 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 unsubscribe from this list: send the line "uns
Christian Couder <christian.cou...@gmail.com> 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
h
.
# Everything below will be removed.
diff --git a/git-multimail/README b/git-multimail/README
index f41906b..93d4751 100644
Signed-off-by: Matthieu Moy matthieu@imag.fr
--- a/git-multimail/README
+++ b/git-multimail/README
Either commit-msg should be called after stripping the diff from
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr 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 case
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
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
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
, you should check for emptyness before (or actually without)
doing the quoting. I guess this is what you're doing, and if so, I think
it's The Right Thing.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
unconditional
I can't decide between ah, very elegant and no, too much magic ;-).
I lean towards the former.
--
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
.
but 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 rendering?
--
Matthieu
Karthik Nayak karthik@gmail.com writes:
On Mon, Aug 24, 2015 at 1:30 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 1997657..06d468e 100644
Karthik Nayak karthik@gmail.com writes:
On Mon, Aug 24, 2015 at 1:26 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -13,7 +13,8 @@ SYNOPSIS
tagname [commit
lines.
The object that the new tag will refer to, usually a commit.
Defaults to HEAD.
+format::
Shouldn't this be --format format, not just format? We usually use
the named argument in the SYNOPSIS for positional arguments, but not for
arguments following an option.
--
Matthieu
.
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
--oneline`. My command above
with a commit-msg hook outputs:
[master 86f32d5] place of: code: change we made Signed-off-by: Matthieu Moy
matthieu@imag.fr
(on a single line)
I do not care deeply, but you may want to let interpret-trailers deal
with this case too.
Thanks,
--
Matthieu Moy
http
%(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 unsubscribe git in
the body of a message
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
:
foo: do something
Signed-off-by: Matthieu Moy matthieu@imag.fr
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 last line looks like
a trailer should
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...@vger.kernel.org
More majordomo info
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-prone for the author: you already got
it wrong once.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list
+ append_atom(atomv, state);
}
if (*cp) {
sp = cp + strlen(cp);
Unless I missed something, this second patch is sensible anyway and
should be squashed into [PATCH v12 05/13]: you don't need to call
append_atom() when you have a handler, right?
--
Matthieu Moy
http
Karthik Nayak karthik@gmail.com writes:
On Thu, Jul 30, 2015 at 12:59 PM, Matthieu Moy
matthieu@grenoble-inp.fr 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
Karthik Nayak karthik@gmail.com 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
));
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 unsubscribe git in
the body
501 - 600 of 2040 matches
Mail list logo
