o "pull
--set-upstream" too:
* "git remote add" is ran once for a remote, "git pull --set-upstream"
can be run several times for several branches.
* In practice, even when "remote add" supports "--set-upstream", I'll
very likely forget it, and by the time I run "git pull", it'll be too
late to add --set-upstream to my "remote add" command.
--
Matthieu Moy
https://matthieu-moy.fr/
feel more
natural for people using a hosting system which allows forking from
the web UI.
This functionality is analog to "git push --set-upstream".
Signed-off-by: Corentin BOMPARD
Signed-off-by: Nathan BERBEZIER
Signed-off-by: Pablo CHABANNE
Signed-off-by: Matthieu Moy
Patch-edi
remote-tracking branch"));
>> +} else if (starts_with(source_ref->name, "refs/tags/"))
>> {
>> +warning(_("not setting upstream for a remote
>> tag"));
>> +} else {
>> +warning(_("unknown branch type"));
>> +}
>
> No need to wrap single line if statements in braces.
Fixed.
>> +#tests for fetch --set-upstream
>
> Add a space after the '#'. Same in other comments below.
Fixed.
Thanks. Version 2 fixing all these follows.
--
Matthieu Moy
https://matthieu-moy.fr/
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> From: Corentin BOMPARD
>>
>> Add the --set-upstream option to git pull/fetch
>> which lets the user set the upstream configuration
>> (branch..merge and
>> branch..remote) for the current branch.
: Pablo CHABANNE
Signed-off-by: Matthieu Moy
Patch-edited-by: Matthieu Moy
---
This is a followup on
https://public-inbox.org/git/86zhoil3yw@univ-lyon1.fr/. It's
initially a student project, but students didn't get time to complete
it. Still, I think the feature is interesting, and I f
not depend on what has
been executed previously. There are several places where you really need
it. It probably makes sense to use it at the start of every tests for
consistency and future-proof-ness.
> +test_expect_success 'fetch --set-upstream http://nosuchdomain.example.com
> fails with the bad url' '
> + test_must_fail git fetch --set-upstream http://nosuchdomain.example.com
> &&
> + check_config master upstream refs/heads/other &&
> + check_config_empty other &&
> + check_config_empty other2
> +'
It would probably make sense to check what happens when running
git fetch --set-upstream
i.e. use a URL instead of a named remote.
--
Matthieu Moy
https://matthieu-moy.fr/
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> -u::
>> --set-upstream::
>> For every branch that is up to date or successfully pushed, add
>> upstream (tracking) reference, used by argument-less
>> linkgit:git-pull[1] and other command
quot;You need to specify excatly one branch with
the set-upstream option."));
?
--
Matthieu Moy
https://matthieu-moy.fr/
to say "It is OK for the variable to be missing, and
> it also is OK for the variable to have an empty string as its value;
> all other cases are unacceptable",
Actually, I don't think the "present but empty" case makes sense here,
so just test_must_fail git config "$1" should do the trick.
I agree with all other remarks.
--
Matthieu Moy
https://matthieu-moy.fr/
x27;
> +
> +
Style: you sometimes leave 2 blank lines, sometimes 1 between tests. Try
to be consistent.
> +test_expect_success 'pull --set-upstream upstream other sets branch other' '
Test title and content say the opposite of each other.
> + git pull --set-upstream
In patch 2/2, there's a 'man curl' which probably ought to be
> converted to `man curl` (per paragraph updated by patch 1/2), but
> perhaps that's outside the scope of this patch series
Yes, I have no objection in fixing it but I'd rather limit the scope of
the patch
Corentin BOMPARD writes:
> Applying CodingGuidelines about monospace on pathnames and URLs.
>
> See Documentation/CodingGuidelines.txt for more information.
>
> Signed-off-by: Corentin BOMPARD
> Signed-off-by: Nathan BERBEZIER
> Signed-off-by: Pablo CHABANNE
> Sig
ing tree::
> The tree of actual checked out files. The working tree normally
[...]
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 72daa20e7..92b1d5638 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -23,2
ely un-interested way, but
once you start getting the benefits of your own patches in the way _you_
use Git, it's really rewarding !
Cheers,
--
Matthieu Moy
https://matthieu-moy.fr/
t;works with
dash" as a heuristic for "should word on any shell", but it doesn't
always work).
If -x doesn't work in some setups, it may be a good reason to wait a bit
before trashing test_path_is_*, but if it's clear enough that the vast
majority of platforms get -x, then why not trash these wrappers indeed.
--
Matthieu Moy
https://matthieu-moy.fr/
format = CMIT_FMT_ONELINE;
> - rev.use_terminator = 1;
> + if (cfg_have_pretty != 0) {
I'd write just "if (cfg_have_pretty)".
> rev.always_show_header = 1;
> +
> cmd_log_init_finish(argc, argv, prefix, &rev, &opt);
Avoid adding unrelated whitespace changes like this one.
Regards,
--
Matthieu Moy
https://matthieu-moy.fr/
expect more than just
microprojects).
You may suggest ideas by editting the wiki page, or just by replying to
this email (I'll point my students to the thread). Don't hesitate to
remove entries (or ask me to do so) on the wiki page if you think they
are not relevant anymore.
Thanks in advance,
--
Matthieu Moy
https://matthieu-moy.fr/
Changes are described in CHANGES.
Contributions-by: Matthieu Moy
Contributions-by: William Stewart
Contributions-by: Ville Skyttä
Contributions-by: Dirk Olmes
Contributions-by: Björn Kautler
Contributions-by: Konstantin Ryabitsev
Contributions-by: Gareth Pye
Contributions-by: David Lazar
push.default, but it
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/
is IMHO 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/
verwrite it.
* If you don't know about 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/
"jrnieder" wrote:
> (+cc: some folks interested in git-remote-mediawiki)
Thanks.
In case it still matters, an obvious Acked-by: Matthieu Moy
--
Matthieu Moy
27;t think step 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/
"Eckhard Maaß" :
> 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 apparently :-(.
> Should I have d
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/
sumes we're calling 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/?
"Jonathan Nieder" 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 in bd869f67b9 ("send
"Christian Couder" wrote:
> Hi,
>
> On Fri, Jan 5, 2018 at 12:18 PM, Johannes Schindelin
> wrote:
>> Hi,
>>
>> On Fri, 5 Jan 2018, Matthieu Moy wrote:
>>
>>> If we go for it, we need:
>>>
>>> * Admins
>>>
>>
obably to allow --cc-cmd="executable
--option"), while --smtp-server needs to be absolute.
Patch-edited-by: Matthieu Moy
Signed-off-by: Alex Bennée
Signed-off-by: Matthieu Moy
---
Change since v2:
* Mention relative Vs absolute path in commit message.
* Remove useless "chmo
We now use Mail::Address unconditionaly, hence parse_mailboxes is now
dead code. Remove it and its tests.
Signed-off-by: Matthieu Moy
---
No change since v2.
perl/Git.pm | 71
t/t9000-addresses.sh | 27
t/t9000
d 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
---
Eric Sunshine writes:
> On Fri, Jan 5, 2018 at 1:36 PM, Matthieu Moy wrote:
>> From: Alex Bennée
>>
>> We had a regression that broke Linux's get_maintainer.pl. Using
>> Mail::Address to parse email addresses fixed it, but let's protect
>> agains
We now use Mail::Address unconditionaly, hence parse_mailboxes is now
dead code. Remove it and its tests.
Signed-off-by: Matthieu Moy
---
perl/Git.pm | 71
t/t9000-addresses.sh | 27
t/t9000/test.pl | 67
From: Alex Bennée
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
Signed-off-by: Alex Bennée
Signed-off-by: Matthieu Moy
---
Change since
d 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
---
Ch
(moderated list:THIS THING
(FOO/bar))'
@@ -186,7 +185,6 @@ test_expect_success $PREREQ 'setup fake get_maintainer.pl
script for cc trailer'
"
test_expect_success $PREREQ 'cc trailer with get_maintainer.pl output' '
- test_commit cc-trailer-getmaint &&
From: Alex Bennée
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
Signed-off-by: Alex Bennée
Signed-off-by: Matthieu Moy
---
t/t9001-sen
Alex Bennée writes:
> Matthieu Moy writes:
>
>> We now use Mail::Address unconditionaly, hence parse_mailboxes is now
>> dead code. Remove it and its tests.
>>
>> Signed-off-by: Matthieu Moy
>> ---
>> perl/Git.pm | 71
>> --
We now use Mail::Address unconditionaly, hence parse_mailboxes is now
dead code. Remove it and its tests.
Signed-off-by: Matthieu Moy
---
perl/Git.pm | 71
t/t9000-addresses.sh | 27
t/t9000/test.pl | 67
ot 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
---
I loo
ase of a triangular workflow, if the project already exists,
> PUBLISH will already exist too.
No.
If the project already exists, then UPSTREAM exists, and the contributor
will create his or her own PUBLISH. There's generally two ways to do it:
* On platforms supporting this, use the platform'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/
te.
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/
t; "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 my previous remarks have been taken into account. This is now
Reviewed-by: Matthieu Moy
Thanks,
--
Matthieu Moy
https://matthieu-moy.fr/
me to see what commits I have which aren't
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/
ommit message should be expanded to include a mention of the
"duplicate headers"/"header order" potential issue.
--
Matthieu Moy
https://matthieu-moy.fr/
ype'})" part, and plug the "elseif" directly
after the "if ($parsed_email{'mime-version'})". That's what I
suggested in my earlier email.
> +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/
e first option
(if you replace 2222 with abcd, it clearly makes sense).
--
Matthieu Moy
https://matthieu-moy.fr/
hift;
> + my $pattern1 = join "|", qw(To Cc Bcc);
> + my $pattern2 = join "|",
> + 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/
e 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/
with 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/
missing the first line From: ... @..univ-lyon1.fr in your
message.
See how you did it:
https://public-inbox.org/git/20171012091727.30759-1-second.pa...@gmail.com/
(The sign-off was wrong in this one, but the From was OK)
--
Matthieu Moy
https://matthieu-moy.fr/
with in this thread probably
always existed, but it was present only for *some* users.
--
Matthieu Moy
https://matthieu-moy.fr/
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/
e 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/
ng error as a patch, that is not something you care about
> (and it is something you received, so catching this late won't save
> the sender from embarrassment anyway).
I think the intention was to detect cases when $quote_email is not a
patch at all (and give a proper error message inste
;
> +}
> 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/
fun of playing
with install scripts and CI systems ;-).
Cheers,
--
Matthieu Moy
https://matthieu-moy.fr/
h&replace
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/
sn't mean there can't be any
interaction with this list. Requests for reviews for separate projects
are usually welcome even though they don't happen often here.
There's also a hybrid solution used by git-multimail: have a copy of the
code in git.git, but do the development
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/
reached the stage where bugs in our parser should be fixed, not worked
around.
Signed-off-by: Matthieu Moy
---
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..0061dbfab9 100755
--- a
wing 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
---
Change since v1: removed dead code as suggested by Junio.
git-send-email.perl | 22 ++
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> +sub strip_garbage_one_address {
>> +my ($addr) = @_;
>> +chomp $addr;
>> +if ($addr =~ /^(("[^"]*"|[^"<]*)? *<[^>]*>).*/) {
>> +# "Foo Bar&qu
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/
reached the stage where bugs in our parser should be fixed, not worked
around.
Signed-off-by: Matthieu Moy
---
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..2208dcc213 100755
--- a
wing 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
---
Also available as: https://github.com/git/git/pull/398
git-send-email.perl | 26 ++
he behavior here changes pretty
>> drastically if you have Email::Validate installed, now it splits the
>> address into multiple things:
(I'm assuming you mean Email::Address, there's also Email::Valid but I
don't think it would modify the behavior)
Hmm, I think we reached the point where we should just stop using
Email::Address.
Patch series follows and should address both points.
--
Matthieu Moy
http://matthieu-moy.fr
Сергей Шестаков 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/
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/
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 deleted.
--
Duy Nguyen writes:
> On Thu, Feb 19, 2015 at 5:32 PM, Matthieu Moy
> wrote:
>> +### Add configuration options for some commonly used command-line options
>> +
>> +This includes:
>> +
>> +* git am -3
>> +
>> +* git am -c
>> +
>> +Some
to this day. Thanks for spotting and
> fixing.
Yep, sounds all right to me. Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
d 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/
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Johan Hovold writes:
>>
>>> --- a/git-send-email.perl
>>> +++ b/git-send-email.perl
>>> @@ -1563,7 +1563,7 @@ foreach my $t (@files) {
>>> # Now parse the messag
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/
r 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/
ained, 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/
> On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote:
>> Johan Hovold 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 got
>> used to it.
h @address, @buffer;
}
What do you think?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Siddharth Kannan writes:
>>
>>> handle_revision_opt() tries to recognize and handle the given argument. If
>>> an
>>> option was unknown to it, it used to add the option to unkv[(*unkc)++].
>&
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/
er.
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/
int that you
thought about what could happen and to document it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
rk when one end is
> left empty' '
> + git checkout 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/
Matthieu Moy writes:
> Matthieu Moy 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-O
Siddharth Kannan writes:
> Hello Matthieu,
>
> On 8 February 2017 at 20:10, Matthieu Moy
> wrote:
>> In a previous discussion, I made an analogy with "cd -" (which is the
>> source of inspiration of this shorthand AFAIK): "-" did not magically
&g
Matthieu Moy 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 "org profile".
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/
Christian Couder writes:
> On Wed, Feb 8, 2017 at 3:54 PM, Matthieu Moy
> wrote:
>> Jeff King 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 up
stead 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/
Jeff King 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
>> update the list of project
ot 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/
d
update the list of project ideas and microprojects :
https://git.github.io/SoC-2017-Ideas/
https://git.github.io/SoC-2016-Microprojects/
Cheers,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
tive
side in "^Good bad-A bad-B", so having more bad commits mean having a
larger DAG to explore (which is a bit counter-intuitive: without
thinking about it I'd have said "more info => less commits to explore").
So, if finding all guilty commits is 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/
ster'.
My guess 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/
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-by: Matthieu Moy
>>> Mentored-by: Christian C
s 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/
essentially zero-bandwidth to do that in the near
future :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
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/
right.
Signed-off-by: Matthieu Moy
---
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 string.
=cut
+# Very
1 - 100 of 2167 matches
Mail list logo
