Re: [PATCH] push: change needlessly ambiguous example in error

does say so and it's the actual behavior. > already and widely known? https://stackoverflow.com/questions/14031970/git-push-current-branch-shortcut 458 votes for the answer suggesting it. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] push: change needlessly ambiguous example in error

less common. It may confuse users. Or users may learn it and be happy thanks to your message. I don't know. -- Matthieu Moy https://matthieu-moy.fr/

Re: [RFC PATCH] Introduce "precious" file concept

precious files, just keep the default setting and the worse that can happen is to get your file overwritten with a bakup of the old version kept around. This would probably play better with a notion of "precious" files than with a notion of "trashable" files. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] mw-to-git/t9360: fix broken &&-chain

"jrnieder" wrote: > (+cc: some folks interested in git-remote-mediawiki) Thanks. In case it still matters, an obvious Acked-by: Matthieu Moy -- Matthieu Moy

Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

2) would actually be useful. > @@ -928,6 +931,7 @@ static int parse_branchname_arg(int argc, const char > **argv, > dash_dash_pos = -1; > for (i = 0; i < argc; i++) { > if (!strcmp(argv[i], "--")) { > + opts->discard_changes = 1; > dash_dash_pos = i; Wouldn't "dash_dash_pos != -1" be enough to know whether there's a --? -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults

"Eckhard Maaß" <eckhard.s.ma...@googlemail.com>: > On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote: > > That init_diff_ui_defaults() should indeed have been before > > git_config() from the beginning. My bad, I'm the one who > > misplaced it

Re: [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults

O. I'm not 100% sure it's a good change actually. break_opt is normally controlled by "-B/--break-rewrites". I'm not sure why it was set to 0. -- Matthieu Moy https://matthieu-moy.fr/

Re: multimail/p4: issues identified by lgtm.com

ling the superclass's constructor while we actually call the "next in the method resolution order list"), but also probably valid concerns. I've set up a separate project for git-multimail: https://lgtm.com/projects/g/git-multimail/git-multimail/alerts/?mode=list I'll have a d

Re: [PATCH 5/8] perl: update our copy of Mail::Address

"Jonathan Nieder" <jrnie...@gmail.com> wrote: > Ævar Arnfjörð Bjarmason wrote: > > > Update our copy of Mail::Address from 2.19 (Aug 22, 2017) to 2.20 (Jan > > 23, 2018). This should be a trivial update[1] but it seems the version > > Matthieu Moy imported

Re: GSoC 2018 Org applications. Deadline = January 23, 2018 at 18:00 (CET)

"Christian Couder" <christian.cou...@gmail.com> wrote: > Hi, > > On Fri, Jan 5, 2018 at 12:18 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> Hi, >> >> On Fri, 5 Jan 2018, Matthieu Moy wrote: >> >>> If

[PATCH v3 3/3] send-email: add test for Linux's get_maintainer.pl

script names (probably to allow --cc-cmd="executable --option"), while --smtp-server needs to be absolute. Patch-edited-by: Matthieu Moy <g...@matthieu-moy.fr> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- Chang

[PATCH v3 2/3] Remove now useless email-address parsing code

We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- No change since v2. perl/Git.pm | 71 t/t9000-addresses.s

[PATCH v3 1/3] send-email: add and use a local copy of Mail::Address

not be an issue, and will certainly be less burden than maintaining our own parse_mailboxes. Another option would be to consider Mail::Address as a hard dependency, but it's easy enough to save the trouble of extra-dependency to the end user or packager. Signed-off-by: Matthieu Moy <g...@matth

Re: [PATCH v2 3/3] send-email: add test for Linux's get_maintainer.pl

Eric Sunshine <sunsh...@sunshineco.com> writes: > On Fri, Jan 5, 2018 at 1:36 PM, Matthieu Moy <g...@matthieu-moy.fr> wrote: >> From: Alex Bennée <alex.ben...@linaro.org> >> >> We had a regression that broke Linux's get_maintainer.pl. Using >>

[PATCH v2 2/3] Remove now useless email-address parsing code

We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- perl/Git.pm | 71 t/t9000-addresses.sh | 27 t

[PATCH v2 3/3] send-email: add test for Linux's get_maintainer.pl

From: Alex Bennée <alex.ben...@linaro.org> We had a regression that broke Linux's get_maintainer.pl. Using Mail::Address to parse email addresses fixed it, but let's protect against future regressions. Patch-edited-by: Matthieu Moy <g...@matthieu-moy.fr> Signed-off-by: Alex Benn

[PATCH v2 1/3] send-email: add and use a local copy of Mail::Address

not be an issue, and will certainly be less burden than maintaining our own parse_mailboxes. Another option would be to consider Mail::Address as a hard dependency, but it's easy enough to save the trouble of extra-dependency to the end user or packager. Signed-off-by: Matthieu Moy <g...@matth

Re: [PATCH] send-email: add test for Linux's get_maintainer.pl

ect_success $PREREQ 'cc trailer with get_maintainer.pl output' ' - test_commit cc-trailer-getmaint && clean_fake_sendmail && git send-email -1 --to=recipi...@example.com \ --cc-cmd="./expected-cc-script.sh" \ -- Matthieu Moy https://matthieu-moy.fr/

[PATCH] send-email: add test for Linux's get_maintainer.pl

From: Alex Bennée <alex.ben...@linaro.org> We had a regression that broke Linux's get_maintainer.pl. Using Mail::Address to parse email addresses fixed it, but let's protect against future regressions. Patch-edited-by: Matthieu Moy <g...@matthieu-moy.fr> Signed-off-by: Alex Benn

Re: [RFC PATCH 2/2] Remove now useless email-address parsing code

Alex Bennée <alex.ben...@linaro.org> writes: > Matthieu Moy <g...@matthieu-moy.fr> writes: > >> We now use Mail::Address unconditionaly, hence parse_mailboxes is now >> dead code. Remove it and its tests. >> >> Signed-off-by: Matthieu Moy <

[RFC PATCH 2/2] Remove now useless email-address parsing code

We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- perl/Git.pm | 71 t/t9000-addresses.sh | 27 t

[RFC PATCH 1/2] add a local copy of Mail::Address from CPAN

not be an issue, and will certainly be less burden than maintaining our own parse_mailboxes. Another option would be to consider Mail::Address as a hard dependency, but it's easy enough to save the trouble of extra-dependency to the end user or packager. Signed-off-by: Matthieu Moy <g...@matthieu-moy

Re: [PATCH v2] doc: add triangular workflow

form's mechanism to create a fork (e.g. fork button on GitHub/GitLab's web UI). * One can create an empty PUBLISH, clone UPSTREAM, and push to PUBLISH. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH v2] doc: add triangular workflow

t to the same remote. Did you test your own document on a real-life example? If not, you should do so before anything else. You should notice this kind of issues before asking for external review. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] send-email: extract email-parsing code into a subroutine

not require to include > "headers" in the variable name. I suggested this name because $addr_pat seems to imply that this matches an address, while it matches the _name of headers_ containing address. But that's not terribly important, the meaning is clear by the context anyway. All

Re: [PATCH v2] doc: add triangular workflow

in upstream yet: git log @{upstream}.. [ part of text not re-read by lack of time ] > --- a/Documentation/gitworkflows.txt > +++ b/Documentation/gitworkflows.txt > @@ -467,6 +467,7 @@ other options. > SEE ALSO > > linkgit:gittutorial[7], > +linkgit:git-triangular-workflow.txt[1], > linkgit:git-push[1], > linkgit:git-pull[1], > linkgit:git-merge[1], I think this deserves more than just a "SEE ALSO" link. The "merge workflow" part is essentially another name for triangular workflow. There should be a proper citation of this new triangular workflow doc, i.e. a link with an explanatory sentence somewhere in the "merge workflow" part IMHO. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] send-email: extract email-parsing code into a subroutine

e commit message should be expanded to include a mention of the "duplicate headers"/"header order" potential issue. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] send-email: extract email-parsing code into a subroutine

> +my $content_type =3D ($parsed_email{'content-type'} or > +"text/plain; charset=3D$compose_encoding"); > +print $c2 "MIME-Version: 1.0\n", > + "Content-Type: $content_type\n", > + "Content-Transfer-Encoding: 8bit\n"; > +} This part is indented with spaces, please use tabs. -- Matthieu Moy https://matthieu-moy.fr/

Re: SSH port ignored when ssh:// prefix isn't specified

se for you the first option (if you replace with abcd, it clearly makes sense). -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH v4] send-email: extract email-parsing code into a subroutine

t; + qw(From Subject Date In-Reply-To Message-ID MIME-Version > + Content-Type Content-Transfer-Encoding References); > + > + foreach (split(/\n/, $lines)) { > + if (/^($pattern1):\s*(.+)$/i) { > + $parsed_line->{lc $1} = [ parse_address_line($2) ]; > + } elsif (/^($pattern2):\s*(.+)\s*$/i) { > + $parsed_line->{lc $1} = $2; > + } I don't think you need to list the possibilities in the "else" branch. Just matching /^([^:]*):\s*(.+)\s*$/i should do the trick. > + $body = $body . $body_line; Or just: $body .= $body_line; -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] doc: clarify triangular workflow

gt; that there's one maintainer at a time so we will remove the 's' from > "maintainers". Not a native speaker, but according to wikipedia (https://en.wikipedia.org/wiki/Singular_they) it's OK to write "maintainer [singular, but already neulral] may get merge conflicts when they [sinugular they] ..." -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH v3] send-email: extract email-parsing code into a subroutine

th your setting, but appears broken at least with tab-width=8. Don't mix tabs and spaces. The Git coding style is to indent with tabs. To see what I mean, open the script in Emacs and type M-x whitespace-mode RET. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] send-email: extract email-parsing code into a subroutine

one, but the From was OK) -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

he issue dealt with in this thread probably always existed, but it was present only for *some* users. -- Matthieu Moy https://matthieu-moy.fr/

Re: future of the mediawiki extension?

send patches or discuss interesting issues), I haven't received any bug report or pull-requests for a long time. But I still do maintain git-multimail and I will continue updating it in git.git. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH 2/2] send-email: quote-email quotes the message body

t; download the message body from e.g. public-inbox and do the same as for --in-reply-to=file (which doesn't have to be implemented now, but would be a nice-to-have in the future) -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH 1/2] quote-email populates the fields

il is not a patch at all (and give a proper error message instead of trying to continue with probably absurd behavior). But I agree that there's no point in being too strict here, and if that was the intension then it should be documented with a comment. -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH 1/4] remote-mediawiki: add namespace support

_tracked_namespaces(\%pages); > +} > if (!$user_defined) { > get_mw_all_pages(\%pages); > } Space Vs tabs indent issue (I have tab-width = 8, you probably have 4 and this "if" looks underindented). -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH 0/4] WIP: git-remote-media wiki namespace support

st version), nor the fun of playing with install scripts and CI systems ;-). Cheers, -- Matthieu Moy https://matthieu-moy.fr/

Re: [PATCH v2] remote-mediawiki: limit filenames to legal

at the next search for ".mw" finds this. Also, note that your solution works for using Git-Mediawiki in a read-only way, but if you start modifying and pushing such files, you'll get into trouble. It probably makes sense to issue a warnign in such case. Regards, -- Matthieu Moy https://matthieu-moy.fr/

Re: future of the mediawiki extension?

wiki, but I'm mentionning it for completeness. Regards, -- Matthieu Moy https://matthieu-moy.fr/

Re: What means "git config bla ~/"?

nd shell quoting do not need the explanations, and others probably need the example. While we're there, the formatting is also wrong ('' quoting, while we normally use `` quoting for shell commands). Sounds like a nice microproject for my students :-). A patch should follow soon. -- Matthieu Moy https://matthieu-moy.fr/

[PATCH v2 2/2] send-email: don't use Mail::Address, even if available

the stage where bugs in our parser should be fixed, not worked around. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- git-send-email.perl | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index dfd646ac5b..0

[PATCH v2 1/2] send-email: fix garbage removal after address

versions, it makes sense to continue allowing it (but we still remove any garbage after it). OTOH, when an address is given without quoting, we just take the first word and ignore everything after. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- Change since v1: removed dead code as sugges

Re: [RFC PATCH 1/2] send-email: fix garbage removal after address

Junio C Hamano <gits...@pobox.com> writes: > Matthieu Moy <g...@matthieu-moy.fr> writes: > >> +sub strip_garbage_one_address { >> +my ($addr) = @_; >> +chomp $addr; >> +if ($addr =~ /^(("[^"]*"|[^"<]*)? *<[^>]*>

Re: sequencer status

uch screen space so it makes sense to show it by default. I think it makes sense to have another command that shows the whole sequence, but perhaps it could also be just an option for "git status". Cheers, -- Matthieu Moy https://matthieu-moy.fr/

[RFC PATCH 2/2] send-email: don't use Mail::Address, even if available

the stage where bugs in our parser should be fixed, not worked around. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- git-send-email.perl | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index 33a69ffe5d..2

[RFC PATCH 1/2] send-email: fix garbage removal after address

versions, it makes sense to continue allowing it (but we still remove any garbage after it). OTOH, when an address is given without quoting, we just take the first word and ignore everything after. Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> --- Also available as: https://github.com/gi

Re: git send-email Cc with cruft not working as expected

uot;. I feel really sorry that we need so many iterations to get back to a correct behavior :-(. >> Additionally I just discovered that the behavior here changes pretty >> drastically if you have Email::Validate installed, now it splits the >> address into multiple things: (

Re: Bug with automated processing of git status results

Сергей Шестаков <s_shesta...@playrix.com> writes: > I understand that we can turn off core.safecrlf, but it's > inconvinient. Note that you can do that without actually changing the config file: git -c core.safecrlf=false status ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH v4 5/5] stash: implement builtin stash

ed since then, I'd just leave it > as is, which makes git stash with no options a little less verbose. I agree it's OK to keep is as-is, but the original logic (give a bit more advice when "stash push" was DWIM-ed) made sense too, so it can make sense to re-activate it while porting to C. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Git credential helper store flushes randomly

ould happen unless there's some non-determinism on > the server. I did see a case like this where the server was broken temporarily and rejected one login attempt. In this case the credential store deletes the entry for that user, and when the server is repaired, the store still has the entry delet

Re: Add configuration options for some commonly used command-line options

Duy Nguyen <pclo...@gmail.com> writes: > On Thu, Feb 19, 2015 at 5:32 PM, Matthieu Moy > <matthieu@grenoble-inp.fr> wrote: >> +### Add configuration options for some commonly used command-line options >> + >> +This includes: >> + >> +* git

Re: [PATCH] git-status: make porcelain more robust

lready missed these strings, and > their _() markings survive to this day. Thanks for spotting and > fixing. Yep, sounds all right to me. Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

stamp for each signed commits: https://help.github.com/articles/signing-commits-using-gpg/ It's not a Git feature but a GitHub one, but given the popularity of GitHub, this probably led some users to believe that signed commits are more convenient than signed tags. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH v2] send-email: only allow one address per body tag

Junio C Hamano <gits...@pobox.com> writes: > Matthieu Moy <matthieu@grenoble-inp.fr> writes: > >> Johan Hovold <jo...@kernel.org> writes: >> >>> --- a/git-send-email.perl >>> +++ b/git-send-email.perl >>> @@ -1563,7 +1563,7 @

Re: [PATCH v2] send-email: only allow one address per body tag

eusing the regexp parsing "..." in parse_mailbox: my $re_quote = qr/"(?:[^\"\\]|\\.)*"/; So the final regex would look like if (/^(Signed-off-by|Cc): (([^>]*|"(?:[^\"\\]|\\.)*")>?)/i) { I don't think that should block the patch inclusion, but it may be worth considering. Anyway, thanks for the patch! -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: body-CC-comment regression

ince the use of "#" for stable seem to include commit message, and they may contain commas. So, maybe Johan's patch is better indeed. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: body-CC-comment regression

localhost/ but as I explained, this removes a feature suported since several major releases and we have no idea how many users may use the "mupliple emails in one field". The approach I proposed does not suffer from this. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: body-CC-comment regression

> On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: >> Johan Hovold <jo...@kernel.org> writes: > >> The "multiple emails per Cc: field" has been there for a while already >> (b1c8a11c8024 released in 2.6.0, sept 2015), some users may have g

Re: body-CC-comment regression

push @address, @buffer; } What do you think? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 1/4 v4] revision.c: do not update argv with unknown option

Junio C Hamano <gits...@pobox.com> writes: > Matthieu Moy <matthieu@grenoble-inp.fr> writes: > >> Siddharth Kannan <kannan.siddhart...@gmail.com> writes: >> >>> handle_revision_opt() tries to recognize and handle the given argument. If >&g

Re: body-CC-comment regression

while parsing is possible, but only when we use our in-house parser (and we currently use Perl's Mail::Address when available). So, a proper fix is far from obvious, and unfortunately I won't have time to work on that, at least not before a while. OTOH, the current behavior isn't that bad. It accepts the input, and extracts a valid email out of it. Just the display name is admitedly suboptimal ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 1/4 v4] revision.c: do not update argv with unknown option

introducing a breakage to repair it later. Other that bisectability, this makes review harder: at this point the reader knows it's broken, guesses that it will be repaired later, but does not know in which patch. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 0/4 v4] WIP: allow "-" as a shorthand for "previous branch"

a test is a good hint that you thought about what could happen and to document it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

kout testing-2 && > + git checkout master && > + git log ...@{-1} > expect.first_empty && > + git log @{-1}... > expect.last_empty && > + git log ...- > actual.first_empty && > + git log -... > actual.last_empty && Nitpick: we stick the > and the filename (as you did in most places already). It may be worth adding tests for more cases like * Check what happens with suffixes, i.e. -^, -@{yesterday} and -~. * -..- -> to make sure you handle the presence of two - properly. * multiple separate arguments to make sure you handle them all, e.g. "git log - -", "git log HEAD -", "git log - HEAD". The last two may be overkill, but the first one is probably important. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"

Siddharth Kannan <kannan.siddhart...@gmail.com> writes: > Hello Matthieu, > > On 8 February 2017 at 20:10, Matthieu Moy <matthieu@grenoble-inp.fr> > wrote: >> In a previous discussion, I made an analogy with "cd -" (which is the >> source of

Re: GSoC 2017: application open, deadline = February 9, 2017

Matthieu Moy <matthieu@grenoble-inp.fr> writes: > Matthieu Moy <matthieu@grenoble-inp.fr> writes: > >> I created a Git organization and invited you + Peff as admins. I'll >> start cut-and-pasting to show my good faith ;-). > > I created this

Re: GSoC 2017: application open, deadline = February 9, 2017

Matthieu Moy <matthieu@grenoble-inp.fr> writes: > I created a Git organization and invited you + Peff as admins. I'll > start cut-and-pasting to show my good faith ;-). I created this page based on last year's: https://git.github.io/SoC-2017-Org-Application/ I filled-in the

Re: GSoC 2017: application open, deadline = February 9, 2017

at Dscho would be ok to mentor. > And I also think it's not absolutely necessary to do it before > applying as an org. Right. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: GSoC 2017: application open, deadline = February 9, 2017

Christian Couder <christian.cou...@gmail.com> writes: > On Wed, Feb 8, 2017 at 3:54 PM, Matthieu Moy > <matthieu@grenoble-inp.fr> wrote: >> Jeff King <p...@peff.net> writes: >> >>> On Mon, Jan 23, 2017 at 04:02:02PM +0100, Matthieu Moy wrote: >

Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"

ead of a file", so before enabling - for "previous branch", we need to make sure it does not introduce any ambiguity. Git does not seem to use "- for stdin" much (most commands able to read from stdin have an explicit --stdin option for that), a quick grep in the docs shows only "git blame --contents -" which is OK because a revision wouldn't make sense here anyway. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: GSoC 2017: application open, deadline = February 9, 2017

Jeff King <p...@peff.net> writes: > On Mon, Jan 23, 2017 at 04:02:02PM +0100, Matthieu Moy wrote: > >> * We need to write the application, i.e. essentially polish and update >> the text here: https://git.github.io/SoC-2016-Org-Application/ and >> up

Re: [PATCH v2 1/1] status: be prepared for not-yet-started interactive rebase

issing.")); I first was surprised not to see this "git-rebase-todo" in the output of status, but the testcase tests a missing 'done', not a missing todo, so it's normal. Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/

GSoC 2017: application open, deadline = February 9, 2017

ects : https://git.github.io/SoC-2017-Ideas/ https://git.github.io/SoC-2016-Microprojects/ Cheers, -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

s not possible, I'm not sure how valuable it is to try to find several of them. OTOH, keeping several good commits is needed to find a commit for which all parents are good and the commit is bad, i.e. distinguish Good \ Bad <-- this is the one. / Good and Good \ Bad <-- need to dig further / Bad -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: "Your branch is ahead of 'origin' by X commits"

ss is that you have a badly configured upstream. What does "git pull -v" say? What's the content of the [branch "master"] section of .git/config? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH v7 14/17] ref-filter: allow porcelain to translate messages in the output

arthik@gmail.com> >>> >>> Introduce setup_ref_filter_porcelain_msg() so that the messages used in >>> the atom %(upstream:track) can be translated if needed. This is needed >>> as we port branch.c to use ref-filter's printing API's. >>> >>> Written-

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

col. Asking the main git process to get the credentials probably has added value like the ability to prompt once and use the same for several filter processes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH v15 01/27] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

? Unfortunately, I have essentially zero-bandwidth to do that in the near future :-(. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Drastic jump in the time required for the test suite

gt; Files=759, Tests=13895, 99 wallclock secs ( 4.81 usr 1.06 sys + 39.70 cusr > 25.82 csys = 71.39 CPU) What about the same without WSL on windows? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

[PATCH 2/2] Git.pm: add comment pointing to t9000

it right. Signed-off-by: Matthieu Moy <matthieu@imag.fr> --- perl/Git.pm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/perl/Git.pm b/perl/Git.pm index 42e0895ef7..8bb2b7c7e3 100644 --- a/perl/Git.pm +++ b/perl/Git.pm @@ -870,6 +870,8 @@ Return an array of mailboxes extracted from a

[PATCH 1/2] t9000-addresses: update expected results after fix

e3fdbcc8e1 (parse_mailboxes: accept extra text after <...> address, 2016-10-13) improved our in-house address parser and made it closer to Mail::Address. As a consequence, some tests comparing it to Mail::Address now pass, but e3fdbcc8e1 forgot to update the test. Signed-off-by: Matthi

Re: Drastic jump in the time required for the test suite

Junio C Hamano writes: > Are you proposing to replace the tests written as shell scripts with > scripts in another language or framework that run equivalent > sequences of git commands that is as portable as, if not more, > Bourne shell? The language (/bin/sh) is probably not

Re: Can we make interactive add easier to use?

t add -i" ;-). To add patch hunks individually, "git add -p" jumps directly to the "patch" inner loop of "git add -i". To add whole individual files, a plain "git add" using zsh's smart completion (autocompletes only files for which "git add" is not a no-op), or globs. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Formatting problem send_mail in version 2.10.0

in 831a488b76e0 (git-send-email: remove garbage after email address, 2012-11-22). IMHO, it's OK to continue doing this: removing comments from To: and Cc: is not really a problem (and I think we've seen nobody complain about it since 2012). But after my patch, these two lines can probably safely be removed, as there can no longer be "garbage" after the email, only comments. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

[PATCH] parse_mailboxes: accept extra text after <...> address

e keep the possibility to handle comma-separated lists. Reported-by: Larry Finger <larry.fin...@lwfinger.net> Signed-off-by: Matthieu Moy <matthieu@imag.fr> --- perl/Git.pm | 13 +++-- t/t9001-send-email.sh | 29 + 2 files changed, 36 insertio

Re: Formatting problem send_mail in version 2.10.0

o # Bar" <em...@example.com> => we'd need to handle the ".*" syntax when stripping comments. And again, that wouldn't be consistent with Mail::Address. So, I ended up implementing 3., which actually isn't hard, and gives code IMHO cleaner than it used to be. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Formatting problem send_mail in version 2.10.0

.9" > has garbage " 4.8, 4.9" that needs to be stripped, while "Cc: Stable > <a...@re.ss> 4.8, torva...@linux-foundation.org" has two valid > addresses that need to be CC'ed and " 4.8" is the only thing that is > unwanted? We clearly can't guess, but we can be consistent with Mail::Address, so that git's behavior depends less on its availability. Patch follows doing that. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Formatting problem send_mail in version 2.10.0

Larry Finger <larry.fin...@lwfinger.net> writes: > On 10/12/2016 02:36 AM, Matthieu Moy wrote: >> Larry Finger <larry.fin...@lwfinger.net> writes: >> >>> On 10/11/2016 11:18 AM, Matthieu Moy wrote: >>>> Larry Finger <larry.fin...@lwfinger.net>

Re: Formatting problem send_mail in version 2.10.0

Larry Finger <larry.fin...@lwfinger.net> writes: > On 10/12/2016 02:36 AM, Matthieu Moy wrote: >> Larry Finger <larry.fin...@lwfinger.net> writes: >> >>> On 10/11/2016 11:18 AM, Matthieu Moy wrote: >>>> Larry Finger <larry.fin...@lwfinger.net>

Re: Formatting problem send_mail in version 2.10.0

Larry Finger <larry.fin...@lwfinger.net> writes: > On 10/11/2016 11:18 AM, Matthieu Moy wrote: >> Larry Finger <larry.fin...@lwfinger.net> writes: >> >>> That added information at the end is intended to be passed on to the >>> stable group. In this

Re: Formatting problem send_mail in version 2.10.0

; will call "format-patch" which won't remove it). Not an objection to patching send-email anyway, but if there's a simple and RFC-compliant way to do what you're looking for, we can as well use it (possibly in addition to patching). -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: Formatting problem send_mail in version 2.10.0

quot;. What is this [4.8+] supposed to mean? The guilty function is parse_mailboxes in perl/Git.pm. It should be rather easy to modify it but I need to understand the spec before I can try to implement anything. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Matthieu, > > On Fri, 7 Oct 2016, Matthieu Moy wrote: > >> Another possibility: !(nocd), which leaves room >> for !(keyword1,keyword2,...) if needed later. Also, it is consistent >>

Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

a new alias type with a > leading symbol. This just occurred to me, however, what do you think > about a new config group for it? With can have something like > externalAlias.* (or some other name) that lives in parallel with > alias.*. Then we don't need '!' (or '!!') at all. Another possibility: !(nocd), which leaves room for !(keyword1,keyword2,...) if needed later. Also, it is consistent with the :(word) syntax of pathspecs. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH] push: Re-include "push.default=tracking" in the documentation

upstream branch + (`tracking` is a deprecated synonym for this). ) I agree that doing the same thing is the best option. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH] push: Re-include "push.default=tracking" in the documentation

ll > + support for backwards compatibility with existing configuration > + files. Nit: I think the doc normally doesn't use "we" this way (we = the Git developers or the Git tool). Hence my s/which we still support/still supported/ above. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 1/4] config: allow customizing /etc/gitconfig location

variable" something that came from POSIX world? I don't know who invented the concept, but environment variables have been there in the windows world since it exists I think (it existed in MS-DOS). -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

ould keep these few columns of screen real-estate. That said, I can certainly live without these 5 columns, don't take my message as an objection to setting to 12 right away. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

  1   2   3   4   5   6   7   8   9   10   >