pocket size selfie stick bt foldable monopod,only $2.7/pc now
Dear Good day Pocket size mini foldable monopod selfie stick with bt shutter button on stick, now only $2.7/pc ,only from us,the arcpeaks factory,2kpcs in stock now http://arcpeaks.en.alibaba.com/product/60228194355-801021588/2015_original_factory_foldable_bluetooth_monopod_mini_selfie_stick.html Please feel free to contact me for more details Thanks Best Regards Ray arcpeaks.en.alibaba.com Skype:sixiwenzhi MOBIL:+86 18924649532 We will attend Hong kong Electronics Fair(Autumn Edition) On Oct 13th to 16th,2015 Our booth located at ED-D26 at Expo Drive Hall Welcome
Re: Draft of Git Rev News edition 6
Hi Thomas.
On 3 August 2015 at 08:52, Thomas Ferris Nicolaisen wrote:
>
> Hi,
>
> A draft of Git Rev News edition 6 is available here:
>
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-6.md
>
> Everyone is welcome to contribute in any section, either by editing the
> above page on GitHub and sending a pull request, or by commenting on
> this GitHub issue:
>
> https://github.com/git/git.github.io/issues/89
>
> You can also reply to this email.
I did a quick read through and it looks like another interesting
edition, thank you! I couldn't see any obvious issues with it.
There is quite a lot of discussion in the support section, which I
really like. The following sections pack a lot in, but I think could
warrant a little more discussion themselves.
For example, I think it would be good to add a brief discussion about
the 2.5 release. This seems important/interesting enough to provide a
bit more context in the edition itself. Perhaps something like the
following?
--8<--
## Releases
* Git 2.5 is out! The project maintainer, Junio C. Hamano, has [shared
his thoughts on the release at his
blog](http://git-blame.blogspot.de/2015/07/git-25.html). Git 2.5 is
packed full of new features, and includes contributions from 21 new
contributors. In his post, Junio describes how `git help` has changed:
> One interesting change is to git help. We now list commands, grouped by the
> situation in which you would want to use them. This came from discussion on
> usability, inspired by one of the talks at GitMerge conference we had in
> spring.
He goes on to talk about some of his favourite new features included
in the release, such as a new short hand `branch@{push}` that "denotes
the remote-tracking branch that tracks the branch at the remote the
branch would be pushed to", and a new option `--ws-error-highlight`
that can be used with `git diff` and friends to show whitespace
breakages in deleted and context lines.
Be sure to see the post for more on the new features, or checkout the
[release notes in the
source](https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt)
for all the nitty gritty details.
--8<--
I'll copy this over to a pull request so you have it there if you
think it's useful.
Again, thanks for the edition, love reading these each month!
Regards,
Andrew Ardill
--
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
Re: [PATCH v2 00/10] object_id part 2
On 06/14/2015 12:16 AM, brian m. carlson wrote: > This is another series of conversions to struct object_id. > > This series converts more of the refs code and struct object to use > struct object_id. It introduces an additional helper function, > has_object_file, which is the equivalent of has_sha1_file. The name was > chosen to be slightly more logical than has_oid_file, although it can be > changed if desired. > > The next-to-last patch in this series is the conversion of struct object > to use struct object_id. This is a necessarily large patch because of > the large number of places this code is used. That patch will most > likely be too large to make it through to the list, so this series is > available in the object-id-part2 branch from: FWIW I've skimmed patches 01-08 inclusive and nothing jumped out at me. Brian, what was your experience when writing these patches? Did they tend to work as soon as they compiled without errors (i.e., not super risky) or did you often have test suite failures that you had to go back and fix (i.e., risky)? If the latter, what kinds of code patterns tended to be problematic? Your answers might help reviewers decide how much diligence is needed when reviewing these patches and what kind of changes to inspect extra carefully. Because doing a thorough review of all of the patches would be quite a bit of work. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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
Draft of Git Rev News edition 6
Hi, A draft of Git Rev News edition 6 is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-6.md Everyone is welcome to contribute in any section, either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub issue: https://github.com/git/git.github.io/issues/89 You can also reply to this email. Me and Nicola are planning to ship this edition on Wednesday 5th of August (as Christian C. is away on vacation these days). Note that I did not cc everyone involved in the discussed threads, which were: * "git log fails to show all changes for a file" * "Git tag: pre-receive hook issue" Cheers, -Thomas -- 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
Re: [PATCH/RFC 0/9] Pseudorefs
On 07/24/2015 06:45 AM, David Turner wrote: > This series is another chunk of the pluggable refs backend work. The > major reason it is listed as "PATCH/RFC" is beacuse it breaks > t9300-fast-import.sh, because fast-import wants to create a ref called > TEMP_TAG, which would now be a pseudoref. The commit that introduces > this test says that cvs2svn creates a tag called TAG_FIXUP "as a branch > name for temporary work needed to cleanup the tree prior to creating > an annotated tag object." > > It appears that cvs2svn still does this. So I'm not quite sure what to > do about this particular case. > > As we discussed earlier, the motivation for this series is that refs > backends other than the files-based backend need to treat per-worktree > refs (HEAD) and pseudorefs (FETCH_HEAD) differently from other refs; > other refs are per-repo rather than per-worktree. Sorry, I missed this email while on vacation. cvs2git needs to create a temporary reference for cobbling together tagged commits. Originally I was going to use the name `TAG_FIXUP`, as suggested by git-fast-import(1) [1]. But that functionality turned out to be buggy in `git fast-import` at the time. So I reported the bug but changed cvs2git to use `refs/heads/TAG.FIXUP` [2]. The bug in `git fast-import` was fixed, including the test case that you found, but I never changed cvs2git back to using the originally-planned name. The fact that the test case uses a name different than `TAG_FIXUP` probably means that Shawn thought that any references named similarly should be allowed. Summary: support for a reference named `TAG_FIXUP` is not needed by cvs2git. However, its use is a documented recommendation of `git fast-import`, so it is quite possible that other importers are using this name. I expect that such importers would slightly prefer that this reference be worktree-specific, but I doubt that anybody really cares that much. It seems unlikely that people will run `git fast-import` in multiple worktrees simultaneously. Michael [1] http://git-scm.com/docs/git-fast-import#_use_tag_fixup_branches [2] https://github.com/mhagger/cvs2svn/blob/master/cvs2svn_lib/git_output_option.py#L502-L509 -- Michael Haggerty mhag...@alum.mit.edu -- 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
Re: [PATCH v2] send-email: provide whitelist of SMTP AUTH mechanisms
On Sun, Aug 2, 2015 at 12:42 PM, Jan Viktorin wrote:
> When sending an e-mail, the client and server must
> agree on an authentication mechanism. Some servers
> (due to misconfiguration or a bug) deny valid
> credentials for certain mechanisms. In this patch,
> a new option --smtp-auth and configuration entry
> smtpauth are introduced. If smtp_auth is defined,
> it works as a whitelist of allowed mechanisms for
> authentication selected from the ones supported by
> the installed SASL perl library.
Nit: This would read a bit more nicely if wrapped to 70-72 columns.
> Signed-off-by: Jan Viktorin
> ---
> diff --git a/Documentation/git-send-email.txt
> b/Documentation/git-send-email.txt
> index 7ae467b..c237c80 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -171,6 +171,14 @@ Sending
> +--smtp-auth=::
> + Specify allowed SMTP-AUTH mechanisms. This setting forces using only
> + the listed mechanisms. Separate allowed mechanisms by a whitespace.
Perhaps:
Whitespace-separated list of allowed SMTP-AUTH mechanisms.
> + Example: PLAIN LOGIN GSSAPI. If at least one of the specified
> mechanisms
> + matchs those advertised by the SMTP server and it is supported by the
> SASL
s/matchs/matches/
> + library we use, it is used for authentication. If neither of
> 'sendemail.smtpAuth'
> + or '--smtp-auth' is specified, all mechanisms supported on client can
> be used.
s/neither of/neither/
s/or/nor/
> diff --git a/git-send-email.perl b/git-send-email.perl
> index ae9f869..ebc1e90 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -75,6 +75,9 @@ git send-email [options] options >
> Pass an empty string to disable
> certificate
> verification.
> --smtp-domain * The domain name sent to HELO/EHLO
> handshake
> +--smtp-auth * Space separated list of allowed AUTH
> methods.
s/Space separated/Space-separated/
> + This setting forces to use one of the
> listed methods.
> + Supported: PLAIN LOGIN CRAM-MD5
> DIGEST-MD5.
Since you're no longer checking explicitly for these mechanisms, you
probably want to drop the "Supported:" line.
> --smtp-debug<0|1> * Disable, enable Net::SMTP debug.
>
>Automating:
> @@ -1136,6 +1141,10 @@ sub smtp_auth_maybe {
> Authen::SASL->import(qw(Perl));
> };
>
> + if($smtp_auth !~ /^(\b[A-Z0-9-_]{1,20}\s*)*$/) {
> + die "invalid smtp auth: '${smtp_auth}'";
> + }
Style: space after 'if'
> # TODO: Authentication may fail not because credentials were
> # invalid but due to other reasons, in which we should not
> # reject credentials.
> @@ -1148,6 +1157,20 @@ sub smtp_auth_maybe {
> 'password' => $smtp_authpass
> }, sub {
> my $cred = shift;
> +
> + if($smtp_auth) {
Style: space after 'if'
> + my $sasl = Authen::SASL->new(
> + mechanism => $smtp_auth,
> + callback => {
> + user => $cred->{'username'},
> + pass => $cred->{'password'},
> + authname => $cred->{'username'},
> + }
> + );
> +
> + return !!$smtp->auth($sasl);
> + }
> +
> return !!$smtp->auth($cred->{'username'},
> $cred->{'password'});
> });
>
> --
> 2.5.0
--
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
Re: [PATCH v1] send-email: provide whitelist of SMTP AUTH mechanisms
Jan Viktorin writes:
> Authen::SASL gives:
>
> No SASL mechanism found
> at /usr/share/perl5/vendor_perl/Authen/SASL.pm line 77.
> at /usr/share/perl5/core_perl/Net/SMTP.pm line 207.
>
> The SASL library does not check validity of mechanisms'
> names (or I did not find it). It just tries to load one
> that matches both the ours and the server side ones.
> ...
> I would like to include the regex check based on RFC 4422
> as I've already mentioned. at least, it filters out the
> unwanted characters like '/', '.', etc.
Hmm, is there a way to ask Authen::SASL what SASL mechanism the
installed system supports? If so, the enhancement you are adding
could be
my @to_use;
if ($smtp_auth_whitelist is supplied) {
my @installed = Authen::SASL::list_mechanisms();
for (@installed) {
if ($_ is whitelisted) {
push @to_use, $_;
}
}
}
and @to_use can later be supplied when we open the connection as the
list of mechanisms we allow the library to pick.
Just my $.02
--
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
Re: [PATCH/RFC 0/2] bisect per-worktree
Michael Haggerty writes: > Hmm, ok, so you are thinking of a remote database with high latency. I > was thinking more of something like LMDB, with latency comparable to > filesystem storage. Not necessarily. The comment was more from conceptual point: "Why share what needs not to be shared?" > These worktree-specific references might be ephemeral, but they also > imply reachability, which means that they need to be visible at least > during object pruning. True, but for bisect in particular, that is moot. You are in sightseer mode, marking various (older) points in time of an existing history that is already anchored by branches and tags. > Moreover, if the references don't live in the > same database with the rest of the references, then we have to deal with > races due to updating references in different places without atomicity. Does that still hold true in the context of bisection? You do not even want atomicity to get in the way when you found this old commit is bad and are about to mark the next one for testing by checking it out. You still want to mark the "bad" one (as it being bad is already an established fact after testing), even if the subsequent checkout of another commit (i.e. update to "HEAD") fails. But these two comments above do take advantage of the fact that we are discussing "bisect" and nothing else. As a set of points to consider in a more general context, I do agree that there are refs and ref-like things that are per-worktree but still has to be part of reachability, which "HEAD" is the prime example ;-), and some of them may want to be part of a transaction. I however think what David has been calling pseudo-refs falls more in the "ephemeral and unnecessary to participate in reachabliity or transaction" category (e.g. CHERRY_PICK_HEAD). And I think the refs used during bisection falls into the same category. > For each worktree, we could then create a different view of the > references by splicing parts of the full reference namespace together. > ... > "git prune" would see the whole namespace as it really is so that it can > compute reachability correctly. I really like this as a mechanism to include refs/ hierarchy, some part of which is shared and some part of which is private. I do not think bisect or pseudorefs needs that, though. -- 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
Re: [PATCH v1] send-email: provide whitelist of SMTP AUTH mechanisms
Eric Sunshine writes:
> What I was really asking was whether this sort of checking really
> belongs in git-send-email or if it is better left to Net::SMTP (and
> Authen::SASL) to do so since they are in better positions to know what
> is valid and what is not. If the Perl module(s) generate suitable
> diagnostics for bad input, then it makes sense to leave the checking
> to them. If not, then I can understand your motivation for
> git-send-email doing the checking instead in order to emit
> user-friendly diagnostics.
>
> So, that's what I meant when I asked 'What are the consequences of not
> limiting the input to this "approved" list?'.
>
> The other reason I asked was that it increases maintenance costs for
> us to maintain a list of "approved" mechanisms, since the list needs
> to be updated when new ones are implemented (and, as brian pointed
> out, some may already exist which are not in your list).
Both are very good points. I do not think we should be limiting the
user input; instead, we (1) either let the Perl module emit proper
diagnosis (e.g. it may say "There is no valid auth method in the
list you gave me, which was 'PLIAN LOGIN CROM-MD5'") and do nothing,
or (2) catch the error from the Perl module and then guess what
happened after the fact (e.g. the module may say in its die() message
something that is understandable by the program but not by the user,
and "eval { ... module call ... }; if ($@) { ... HERE ... }" would
massage what it can learn in HERE from $@ into what the end user
would understand. It may be that it is sufficient to have something
as simple as this:
my $msg = "$@"
if ($smtp_auth is used to customize) {
$msg .= "\nYour customized <$smtp_auth> might be misspelt?"
}
die $msg;
in "HERE" above.
> ...
> Maybe. This leads back to my original question of whether it's really
> git-send-email's responsibility to do validation or if that can be
> left to Net::SMTP/Authen::SASL. If the Perl module(s) emit suitable
> diagnostics for bad input, then validation can be omitted from
> git-send-email.
Yes, exactly. What happens if we go the route of doing nothing
here? What are the horrible diagnostic message the end user would
not understand?
--
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
Re: [RFC/PATCH 07/11] branch: move 'current' check down to the presentation layer
Karthik Nayak writes:
>> Even more generic would be an %(ifeq:x:y) conditional and a
>> %(currentbranch) atom:
>>
>> %(ifeq:refname:currentbranch)*%(endif)
>>
>> Those are just a couple ideas. Other variations are possible and
>> likely preferable to the specialized %(starifcurrent).
>
> This makes sense, thanks. But implementing something like
> "%(if:)" seems to not be as easy as I thought it would be.
>
> First we need to parse that inner atom, but the used_atom_cnt is based
> on how many atoms there are initially, which doesn't count this inner atom.
>
> Although we could have a way around that, we'd need to again call
> populate_value
> from itself to get that inner atom's value. This causes more problems.
> Either ways
> I'm looking at ways around this.
> A simple solution would be to do :
>
> %(if)%(atom)%(then).%(endif)
>
> or just
>
> %(if)%(atom).%(endif)
My knee-jerk reaction to the former was "Eeww, the users is forced
to keep verbosely typing unnecessarily '%(', ')%(then)' forever,
only because the implementor was too lazy to do the job properly in
parse_atom()". I do not think the latter a good idea at all.
But I think the former is worth considering, as it will later allow
us to extend it to various forms, e.g.
%(if:notempty)%(atom)%(then)...%(end)
%(if)%(atom)%(then)...%(elif)%(atom1)%(atom2)%(then)...%(end)
Two points being
(1) the default "string is not empty" does not have to be the only
test criteria, by leaving the door to add %(if:)
later;
(2) what is tested does not have to be a single atom (that is why
I do not think the one without %(then) good at all) but can be
a string that can later be interpreted.
And syntactically, something like this even may want to be
introduced later:
%(if:expr)master == %(refname:short)%(then)...%(end)
--
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
Re: [PATCH v7 0/11] port tag.c to use ref-filter APIs
Karthik Nayak writes: > +test_expect_success 'no padding when `padright` length is smaller than atom > length' ' > +cat >expect <<-\EOF && > +refs/heads/master| > +refs/heads/side| > +refs/odd/spot| > +refs/tags/double-tag| > +refs/tags/four| > +refs/tags/one| > +refs/tags/signed-tag| > +refs/tags/three| > +refs/tags/two| > +EOF > +git for-each-ref --format="%(padright:5)%(refname)|" >actual && > test_cmp expect actual > ' Nit: I 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
Re: [PATCH v1] send-email: provide whitelist of SMTP AUTH mechanisms
Authen::SASL gives:
No SASL mechanism found
at /usr/share/perl5/vendor_perl/Authen/SASL.pm line 77.
at /usr/share/perl5/core_perl/Net/SMTP.pm line 207.
The SASL library does not check validity of mechanisms'
names (or I did not find it). It just tries to load one
that matches both the ours and the server side ones.
I can see one possible weakness of this, however I doubt
whether there exists a successful attack vector. Imagine
that somebody gives me a malicious .gitconfig with
smtpauth = ~/ATTACK and redirects me to a fake mail
server that advertises ~/ATTACK as a working mechanism.
This might lead to an unwanted execution of ~/ATTACK.pm.
Should we consider this to be a threat?
Another thing that confuses me (I mentioned it in the
previous e-mail). I forced to use CRAM-MD5, however, it
dies with the above errors. The CRAM-MD5 is installed:
/usr/share/perl5/vendor_perl/Authen/SASL/CRAM_MD5.pm
/usr/share/perl5/vendor_perl/Authen/SASL/Perl/CRAM_MD5.pm
The same for DIGEST-MD5. On different PC with the same
set of libraries, OS, the CRAM-MD5 just works. Why? LOGIN
and PLAIN are OK. Environment? (I doubt.)
I would like to include the regex check based on RFC 4422
as I've already mentioned. at least, it filters out the
unwanted characters like '/', '.', etc.
Regards
Jan
On Sun, 2 Aug 2015 05:41:29 -0400
Eric Sunshine wrote:
> On Sat, Aug 1, 2015 at 2:19 PM, Jan Viktorin
> wrote:
> > On Sat, 1 Aug 2015 05:33:28 -0400 Eric Sunshine
> > wrote:
> >> On Fri, Jul 31, 2015 at 7:33 PM, Jan Viktorin
> >> wrote:
> >> At the very least, you will also want to update the documentation
> >> (Documentation/git-send-email.txt) and, if possible, add new tests
> >> (t/t9001-send-email.sh).
> >
> > I will update the documentation when it is clear, how the smtp-auth
> > works.
> >
> > I have no idea, how to test the feature. I can see something like
> > fake.sendmail in the file. How does it work? I can image a test
> > whether user inserts valid values. What more?
>
> That's what I was thinking. You could test if the die() is triggered
> or if it emits warnings for bad values (assuming you implement that
> feature). As for testing the actual authentication, I'm not sure you
> can (and don't see any such testing in the script).
>
> >> > diff --git a/git-send-email.perl b/git-send-email.perl
> >> > index ae9f869..b00ed9d 100755
> >> > --- a/git-send-email.perl
> >> > +++ b/git-send-email.perl
> >> > @@ -1129,6 +1134,16 @@ sub smtp_auth_maybe {
> >> > return 1;
> >> > }
> >> >
> >> > + # Do not allow arbitrary strings.
> >>
> >> Can you explain why this restriction is needed. What are the
> >> consequences of not limiting the input to this "approved" list?
> >
> > This is more a check of an arbitrary user input then a check
> > of an "approved list". It should be also used to inform user
> > about invalid methods (however, I didn't implemented it yet).
>
> What I was really asking was whether this sort of checking really
> belongs in git-send-email or if it is better left to Net::SMTP (and
> Authen::SASL) to do so since they are in better positions to know what
> is valid and what is not. If the Perl module(s) generate suitable
> diagnostics for bad input, then it makes sense to leave the checking
> to them. If not, then I can understand your motivation for
> git-send-email doing the checking instead in order to emit
> user-friendly diagnostics.
>
> So, that's what I meant when I asked 'What are the consequences of not
> limiting the input to this "approved" list?'.
>
> The other reason I asked was that it increases maintenance costs for
> us to maintain a list of "approved" mechanisms, since the list needs
> to be updated when new ones are implemented (and, as brian pointed
> out, some may already exist which are not in your list).
>
> (...)
>
> >> Also, don't you want to warn the user about tokens that don't match
> >> one of the accepted (PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5), rather
> >> than dropping them silently?
> >
> > Yes, this would be great (as I've already mentioned). It's a
> > question whether to include the check for the mechanisms or whether
> > to leave the $smtp_auth variable as it is... Maybe just validate by
> > a regex?
> >
> > The naming rules are defiend here:
> > https://tools.ietf.org/html/rfc4422#page-8
> > So, this looks to me as a better way.
>
> Maybe. This leads back to my original question of whether it's really
> git-send-email's responsibility to do validation or if that can be
> left to Net::SMTP/Authen::SASL. If the Perl module(s) emit suitable
> diagnostics for bad input, then validation can be omitted from
> git-send-email.
--
Jan ViktorinE-mail: vikto...@rehivetech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech Phone: +420 606 201 868
Brno, Czech Republic
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
[PATCH v2] send-email: provide whitelist of SMTP AUTH mechanisms
When sending an e-mail, the client and server must
agree on an authentication mechanism. Some servers
(due to misconfiguration or a bug) deny valid
credentials for certain mechanisms. In this patch,
a new option --smtp-auth and configuration entry
smtpauth are introduced. If smtp_auth is defined,
it works as a whitelist of allowed mechanisms for
authentication selected from the ones supported by
the installed SASL perl library.
Signed-off-by: Jan Viktorin
---
Changes v1 -> v2:
- check user input by regex
- added documentation
- still missing a test
Documentation/git-send-email.txt | 8
git-send-email.perl | 25 -
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 7ae467b..c237c80 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -171,6 +171,14 @@ Sending
to determine your FQDN automatically. Default is the value of
'sendemail.smtpDomain'.
+--smtp-auth=::
+ Specify allowed SMTP-AUTH mechanisms. This setting forces using only
+ the listed mechanisms. Separate allowed mechanisms by a whitespace.
+ Example: PLAIN LOGIN GSSAPI. If at least one of the specified mechanisms
+ matchs those advertised by the SMTP server and it is supported by the
SASL
+ library we use, it is used for authentication. If neither of
'sendemail.smtpAuth'
+ or '--smtp-auth' is specified, all mechanisms supported on client can
be used.
+
--smtp-pass[=]::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
diff --git a/git-send-email.perl b/git-send-email.perl
index ae9f869..ebc1e90 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -75,6 +75,9 @@ git send-email [options]
Pass an empty string to disable
certificate
verification.
--smtp-domain * The domain name sent to HELO/EHLO
handshake
+--smtp-auth * Space separated list of allowed AUTH
methods.
+ This setting forces to use one of the
listed methods.
+ Supported: PLAIN LOGIN CRAM-MD5
DIGEST-MD5.
--smtp-debug<0|1> * Disable, enable Net::SMTP debug.
Automating:
@@ -208,7 +211,7 @@ my ($cover_cc, $cover_to);
my ($to_cmd, $cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
my ($smtp_authuser, $smtp_encryption, $smtp_ssl_cert_path);
-my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
+my ($identity, $aliasfiletype, @alias_files, $smtp_domain, $smtp_auth);
my ($validate, $confirm);
my (@suppress_cc);
my ($auto_8bit_encoding);
@@ -239,6 +242,7 @@ my %config_settings = (
"smtppass" => \$smtp_authpass,
"smtpsslcertpath" => \$smtp_ssl_cert_path,
"smtpdomain" => \$smtp_domain,
+"smtpauth" => \$smtp_auth,
"to" => \@initial_to,
"tocmd" => \$to_cmd,
"cc" => \@initial_cc,
@@ -310,6 +314,7 @@ my $rc = GetOptions("h" => \$help,
"smtp-ssl-cert-path=s" => \$smtp_ssl_cert_path,
"smtp-debug:i" => \$debug_net_smtp,
"smtp-domain:s" => \$smtp_domain,
+ "smtp-auth=s" => \$smtp_auth,
"identity=s" => \$identity,
"annotate!" => \$annotate,
"no-annotate" => sub {$annotate = 0},
@@ -1136,6 +1141,10 @@ sub smtp_auth_maybe {
Authen::SASL->import(qw(Perl));
};
+ if($smtp_auth !~ /^(\b[A-Z0-9-_]{1,20}\s*)*$/) {
+ die "invalid smtp auth: '${smtp_auth}'";
+ }
+
# TODO: Authentication may fail not because credentials were
# invalid but due to other reasons, in which we should not
# reject credentials.
@@ -1148,6 +1157,20 @@ sub smtp_auth_maybe {
'password' => $smtp_authpass
}, sub {
my $cred = shift;
+
+ if($smtp_auth) {
+ my $sasl = Authen::SASL->new(
+ mechanism => $smtp_auth,
+ callback => {
+ user => $cred->{'username'},
+ pass => $cred->{'password'},
+ authname => $cred->{'username'},
+ }
+ );
+
+ return !!$smtp->auth($sasl);
+ }
+
return !!$smtp->auth($cred->{'username'}, $cred->{'password'});
});
--
2.5.0
--
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
Re: [PATCH 1/1] po/README: split out the different contribution types
2015-08-02 21:42 GMT+08:00 Philip Oakley : > Separate out the three different contribution styles for existing, new, > and wider mis-translation contributions, with suitable headings for easy > reference. > > In particular highlight the appropriate action should a Git > mis-translation be from a different distribution. i.e. initially report > to that usptream, but also consider if it could be coordinated here. > > While here, add surrounding headings, and reference the lanaguage codes. > > Signed-off-by: Philip Oakley > --- > po/README | 24 > 1 file changed, 24 insertions(+) > > diff --git a/po/README b/po/README > index d8c9111..b54b3c6 100644 > --- a/po/README > +++ b/po/README > @@ -10,19 +10,43 @@ coordinates our localization effort in the l10 > coordinator repository: > > https://github.com/git-l10n/git-po/ > > +The two character language translation codes are defined by ISO_639-1, as > +stated in the gettext(1) full manual, appendix A.1, Usual Language Codes. > + > + > +Contributing to an existing translation > +--- > As a contributor for a language XX, you should first check TEAMS file in > this directory to see whether a dedicated repository for your language XX > exists. Fork the dedicated repository and start to work if it exists. > > + > +Creating a new language translation > +--- > If you are the first contributor for the language XX, please fork this > repository, prepare and/or update the translated message file po/XX.po > (described later), and ask the l10n coordinator to pull your work. > > + > +Reporting mis-translations > +-- > +First, confirm that your language translation is managed by this group. > +Initially any translation mistake should be reported to the appropriate > +upstream team. If not managed by this group, and the translation has a > +suitable licence, consider suggesting that the translation could be > +included here (see 'new language translation' above). > + First, find the right place to report. If there is a YourLanguage.po here, and you can find the bug in it, then here is the right place for you to report. But if not, maybe your Git distribution (such as from Ubuntu) may have its own l10n workflow, and not work well with our git upstream. For this case, you should report bug to them... (I'm not a native English speaker, so correct me) > + > +Forming a Team > +-- > If there are multiple contributors for the same language, please first > coordinate among yourselves and nominate the team leader for your > language, so that the l10n coordinator only needs to interact with one > person per language. > > + > +Translation Process Flow > + > The overall data-flow looks like this: > > +---++--+ > -- > 2.3.1 > -- Jiang Xin -- 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
Re: [PATCH 0/1] handling mistranslation reports (resend)
2015-08-02 21:42 GMT+08:00 Philip Oakley : > [Resent as first email was not picked up by vger, apologies for any > duplicates] > > Hi Jiang, > > Recently, on the 'Git for human beings' list, a user reported a > mistranslation and asked if/what could be done, with a suggested > alternate text [1]. > > I pointed the user at the po/README for general guidance. > Unfortunately the user was noting a Spanish (es) translation error which > is not held in your tree, but the README does include how to start a new > translation. This led to a misunderstanding with regard to which aspect > of the README was being referred to (private discussion with Junio). > Some linux distribution, such as Ubuntu, has its own l10n workflow for each package (including git.git), and not works well with the upstream. For example, Ubuntu makes a one-time import from our Git translations (from some obsoleted version) into their l10n databases, and their contributors will start to translate using their web UI, and never sync with our upstream again. They ubuntu may have more languages support, but they may also have more bugs. Sometime, their bugs will be reported to our upstream, for example: * http://thread.gmane.org/gmane.comp.version-control.git/239130/focus=239130 We could add some clues for this case if the user can not find the resource to contribute. -- Jiang Xin -- 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
[PATCH] git-p4: fix faulty paths for case insensitive systems
From: Lars Schneider
PROBLEM:
We run P4 servers on Linux and P4 clients on Windows. For an unknown
reason the file path for a number of files in P4 does not match the
directory path with respect to case sensitivity.
E.g. `p4 files` might return
//depot/path/to/file1
//depot/PATH/to/file2
If you use P4/P4V then these files end up in the same directory, e.g.
//depot/path/to/file1
//depot/path/to/file2
If you use git-p4 then all files not matching the correct file path
(e.g. `file2`) will be ignored.
SOLUTION:
Identify files that are different with respect to case sensitivity.
If there are any then run `p4 dirs` to build up a dictionary
containing the correct cases for each path. Upon `clone` this
dictionary is used to fix the paths. All this is only applied if the
git config "core.ignorecase" is set.
Signed-off-by: Lars Schneider
---
git-p4.py | 81 +++
1 file changed, 77 insertions(+), 4 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 549022e..692f1f4 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1859,7 +1859,7 @@ class View(object):
(self.client_prefix, clientFile))
return clientFile[len(self.client_prefix):]
-def update_client_spec_path_cache(self, files):
+def update_client_spec_path_cache(self, files, fixPathCase = None):
""" Caching file paths by "p4 where" batch query """
# List depot file paths exclude that already cached
@@ -1878,6 +1878,8 @@ class View(object):
if "unmap" in res:
# it will list all of them, but only one not unmap-ped
continue
+if fixPathCase:
+res['depotFile'] = fixPathCase(res['depotFile'])
self.client_spec_path_cache[res['depotFile']] =
self.convert_client_path(res["clientFile"])
# not found files or unmap files set to ""
@@ -1973,7 +1975,8 @@ class P4Sync(Command, P4UserMap):
files = []
fnum = 0
while commit.has_key("depotFile%s" % fnum):
-path = commit["depotFile%s" % fnum]
+path = commit["depotFile%s" % fnum]
+path = self.fixPathCase(path)
if [p for p in self.cloneExclude
if p4PathStartsWith(path, p)]:
@@ -2037,7 +2040,9 @@ class P4Sync(Command, P4UserMap):
branches = {}
fnum = 0
while commit.has_key("depotFile%s" % fnum):
-path = commit["depotFile%s" % fnum]
+path = commit["depotFile%s" % fnum]
+path = self.fixPathCase(path)
+
found = [p for p in self.depotPaths
if p4PathStartsWith(path, p)]
if not found:
@@ -2164,6 +2169,10 @@ class P4Sync(Command, P4UserMap):
if marshalled["code"] == "error":
if "data" in marshalled:
err = marshalled["data"].rstrip()
+
+if "depotFile" in marshalled:
+marshalled['depotFile'] = self.fixPathCase(marshalled['depotFile'])
+
if err:
f = None
if self.stream_have_file_info:
@@ -2238,6 +2247,7 @@ class P4Sync(Command, P4UserMap):
# do the last chunk
if self.stream_file.has_key('depotFile'):
+self.stream_file['depotFile'] =
self.fixPathCase(self.stream_file['depotFile'])
self.streamOneP4File(self.stream_file, self.stream_contents)
def make_email(self, userid):
@@ -2295,7 +2305,8 @@ class P4Sync(Command, P4UserMap):
sys.stderr.write("Ignoring file outside of prefix: %s\n" %
f['path'])
if self.clientSpecDirs:
-self.clientSpecDirs.update_client_spec_path_cache(files)
+self.clientSpecDirs.update_client_spec_path_cache(
+files, lambda x: self.fixPathCase(x))
self.gitStream.write("commit %s\n" % branch)
#gitStream.write("mark :%s\n" % details["change"])
@@ -2759,6 +2770,63 @@ class P4Sync(Command, P4UserMap):
print "IO error with git fast-import. Is your git version recent
enough?"
print self.gitError.read()
+def fixPathCase(self, path):
+if self.caseCorrectedPaths:
+components = path.split('/')
+filename = components.pop()
+dirname = '/'.join(components).lower() + '/'
+if dirname in self.caseCorrectedPaths:
+path = self.caseCorrectedPaths[dirname] + filename
+return path
+
+def generatePathCaseDict(self, depotPaths):
+# Query all files and generate a list of all used paths
+# e.g. this files list:
+# //depot/path/to/file1
+# //depot/PATH/to/file2
+#
+# result in this path list:
+# //depot/
+# //depot/PATH/
+# //depot/path/
+# //depot/PATH/to/
+# //depot/path/to/
+p4_paths = set()
+for p in depotPaths:
+for f in p4CmdList(["files", p+"..."]
[PATCH] git-p4: fix faulty paths for case insensitive systems
From: Lars Schneider Hi, I want to propose this patch as it helped us to migrate a big source code base successfully from P4 to Git. I am sorry that I don't provide a test case, yet. I would like to get advise on the patch and on the best strategy to provide a test. Do you only run git-p4 integration tests in "t/t98??-git-p4-*.sh"? If yes, which version of "start_p4d" should I use? Thanks, Lars Lars Schneider (1): git-p4: fix faulty paths for case insensitive systems git-p4.py | 81 +++ 1 file changed, 77 insertions(+), 4 deletions(-) -- 1.9.5 (Apple Git-50.3) -- 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
Re: [RFC/PATCH 07/11] branch: move 'current' check down to the presentation layer
On Sat, Aug 1, 2015 at 2:33 PM, Eric Sunshine wrote: > On Sat, Aug 1, 2015 at 2:48 AM, Karthik Nayak wrote: >> On Thu, Jul 30, 2015 at 2:57 AM, Matthieu Moy >> wrote: >> Good point! I just was wondering if we need another atom just to print a >> star. >> But your points certainly are valid. I'll implement this. Thanks :) >> This would remove the need of making the printing of the "*" to be needed by ref-filter. As this is only needed in branch.c If going on what you're saying we could have a "%(starifcurrent)" atom or something, but I don't see a general use for this. >>> >>> To have a really customizeable format, you would want to allow e.g. >>> >>> git branch --format '%(starifcurrent) %(objectname) %(refname)' >>> >>> if the user wants to get the sha1 before the refname, and still have the >>> star in front. It's a bit frustrating to have a hardcoded format that >>> the user can't reproduce with the --format option, since it means you >>> can't easily make a small variation on it. >> >> Agreed. will have a "starifcurrent" atom :) > > Please don't. It's better to avoid these highly specialized solutions > and instead seek general purpose ones. For instance, utilizing the > %(if:) atom suggested elsewhere, you might add an %(iscurrentbranch) > which would allow a format like this: > > %(if:iscurrentbranch)*%(endif) > > Even more generic would be an %(ifeq:x:y) conditional and a > %(currentbranch) atom: > > %(ifeq:refname:currentbranch)*%(endif) > > Those are just a couple ideas. Other variations are possible and > likely preferable to the specialized %(starifcurrent). This makes sense, thanks. But implementing something like "%(if:)" seems to not be as easy as I thought it would be. First we need to parse that inner atom, but the used_atom_cnt is based on how many atoms there are initially, which doesn't count this inner atom. Although we could have a way around that, we'd need to again call populate_value from itself to get that inner atom's value. This causes more problems. Either ways I'm looking at ways around this. A simple solution would be to do : %(if)%(atom)%(then).%(endif) or just %(if)%(atom).%(endif) -- Regards, Karthik Nayak -- 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
[PATCH v3 0/4] notes: add support for notes.merge option
From: Jacob Keller This series incorporates the feedback from both Johan and Eric. In addition, I included an RFC implementing suggestion from Johan regarding per-ref merge strategies. I split the tests for --merge/--commit/--strategy out into their own patch to help review and keep the "one commit = one change" logic. I am not certain the RFC is ready yet, but the first 3 patches (now based on next) should be ready to go. Jacob Keller (4): notes: document cat_sort_uniq rewriteMode notes: add tests for --commit/--abort/--strategy exclusivity notes: add notes.merge option to select default strategy notes: add per-ref configuration of merge strategy Documentation/config.txt | 18 +++- Documentation/git-notes.txt | 23 - builtin/notes.c | 167 ++ notes-merge.h | 16 ++-- t/t3309-notes-merge-auto-resolve.sh | 79 t/t3310-notes-merge-manual-resolve.sh | 12 +++ 6 files changed, 288 insertions(+), 27 deletions(-) -- 2.5.0.482.gfcd5645 -- 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
[PATCH v3 1/4] notes: document cat_sort_uniq rewriteMode
From: Jacob Keller Teach documentation about the cat_sort_uniq rewriteMode that got added at the same time as the equivalent merge strategy. Signed-off-by: Jacob Keller Cc: Johan Herland Cc: Michael Haggerty Cc: Eric Sunshine --- Documentation/config.txt| 4 ++-- Documentation/git-notes.txt | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 3f1c17814ceb..4ce5c553e50f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1939,8 +1939,8 @@ notes.rewriteMode:: When copying notes during a rewrite (see the "notes.rewrite." option), determines what to do if the target commit already has a note. Must be one of - `overwrite`, `concatenate`, or `ignore`. Defaults to - `concatenate`. + `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. + Defaults to `concatenate`. + This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` environment variable. diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 851518d531b5..674682b34b83 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -331,7 +331,8 @@ environment variable. notes.rewriteMode:: When copying notes during a rewrite, what to do if the target commit already has a note. Must be one of `overwrite`, - `concatenate`, and `ignore`. Defaults to `concatenate`. + `concatenate`, `cat_sort_uniq`, or `ignore`. Defaults to + `concatenate`. + This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` environment variable. -- 2.5.0.482.gfcd5645 -- 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
[PATCH v3 3/4] notes: add notes.merge option to select default strategy
From: Jacob Keller
Teach git-notes about a new configuration option "notes.merge" for
selecting the default notes merge strategy. Document the option in
config.txt and git-notes.txt
Add tests for use of the configuration option. Include a test to ensure
that --strategy correctly overrides the configured setting.
Signed-off-by: Jacob Keller
Cc: Johan Herland
Cc: Michael Haggerty
Cc: Eric Sunshine
---
Documentation/config.txt| 7 +
Documentation/git-notes.txt | 14 +-
builtin/notes.c | 56 ++---
notes-merge.h | 16 ++-
t/t3309-notes-merge-auto-resolve.sh | 29 +++
5 files changed, 98 insertions(+), 24 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 4ce5c553e50f..0fa88a29dd65 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1911,6 +1911,13 @@ mergetool.writeToTemp::
mergetool.prompt::
Prompt before each invocation of the merge resolution program.
+notes.merge::
+ Which merge strategy to choose by default when resolving notes
+ conflicts. Must be one of `manual`, `ours`, `theirs`, `union`,
+ or `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE
+ STRATEGIES" section of linkgit:git-notes[1] for more information
+ on each strategy.
+
notes.displayRef::
The (fully qualified) refname from which to show notes when
showing commit messages. The value of this variable can be set
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 674682b34b83..9c4f8536182f 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -101,7 +101,7 @@ merge::
any) into the current notes ref (called "local").
+
If conflicts arise and a strategy for automatically resolving
-conflicting notes (see the -s/--strategy option) is not given,
+conflicting notes (see the "NOTES MERGE STRATEGIES" section) is not given,
the "manual" resolver is used. This resolver checks out the
conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`),
and instructs the user to manually resolve the conflicts there.
@@ -183,6 +183,7 @@ OPTIONS
When merging notes, resolve notes conflicts using the given
strategy. The following strategies are recognized: "manual"
(default), "ours", "theirs", "union" and "cat_sort_uniq".
+ This option overrides the "notes.merge" configuration setting.
See the "NOTES MERGE STRATEGIES" section below for more
information on each notes merge strategy.
@@ -247,6 +248,9 @@ When done, the user can either finalize the merge with
'git notes merge --commit', or abort the merge with
'git notes merge --abort'.
+Users may select an automated merge strategy from among the following using
+either -s/--strategy option or configuring notes.merge accordingly:
+
"ours" automatically resolves conflicting notes in favor of the local
version (i.e. the current notes ref).
@@ -310,6 +314,14 @@ core.notesRef::
This setting can be overridden through the environment and
command line.
+notes.merge::
+ Which merge strategy to choose by default when resolving notes
+ conflicts. Must be one of `manual`, `ours`, `theirs`, `union`,
+ or `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE
+ STRATEGIES" section above for more information on each strategy.
++
+This setting can be overridden by passing the `--strategy` option.
+
notes.displayRef::
Which ref (or refs, if a glob or specified more than once), in
addition to the default set by `core.notesRef` or
diff --git a/builtin/notes.c b/builtin/notes.c
index 63f95fc55439..de0caa00df1b 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -92,6 +92,8 @@ static const char * const git_notes_get_ref_usage[] = {
static const char note_template[] =
"\nWrite/edit the notes for the following object:\n";
+static enum notes_merge_strategy merge_strategy;
+
struct note_data {
int given;
int use_editor;
@@ -737,6 +739,24 @@ static int merge_commit(struct notes_merge_options *o)
return ret;
}
+static int parse_notes_strategy(const char *arg, enum notes_merge_strategy
*strategy)
+{
+ if (!strcmp(arg, "manual"))
+ *strategy = NOTES_MERGE_RESOLVE_MANUAL;
+ else if (!strcmp(arg, "ours"))
+ *strategy = NOTES_MERGE_RESOLVE_OURS;
+ else if (!strcmp(arg, "theirs"))
+ *strategy = NOTES_MERGE_RESOLVE_THEIRS;
+ else if (!strcmp(arg, "union"))
+ *strategy = NOTES_MERGE_RESOLVE_UNION;
+ else if (!strcmp(arg, "cat_sort_uniq"))
+ *strategy = NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ;
+ else
+ return -1;
+
+ return 0;
+}
+
static int merge(int argc, const char **argv, const char *prefix)
{
struct strbuf remote_ref = STRBUF_INIT, msg = STRBU
[PATCH v3 2/4] notes: add tests for --commit/--abort/--strategy exclusivity
From: Jacob Keller Add new tests to ensure that --commit, --abort, and --strategy are mutually exclusive. Signed-off-by: Jacob Keller --- t/t3310-notes-merge-manual-resolve.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t3310-notes-merge-manual-resolve.sh b/t/t3310-notes-merge-manual-resolve.sh index 195bb97f859d..d5572121da69 100755 --- a/t/t3310-notes-merge-manual-resolve.sh +++ b/t/t3310-notes-merge-manual-resolve.sh @@ -314,6 +314,18 @@ y and z notes on 1st commit EOF +test_expect_success 'do not allow mixing --commit and --abort' ' + test_must_fail git notes merge --commit --abort +' + +test_expect_success 'do not allow mixing --commit and --strategy' ' + test_must_fail git notes merge --commit --strategy theirs +' + +test_expect_success 'do not allow mixing --abort and --strategy' ' + test_must_fail git notes merge --abort --strategy theirs +' + test_expect_success 'finalize conflicting merge (z => m)' ' # Resolve conflicts and finalize merge cat >.git/NOTES_MERGE_WORKTREE/$commit_sha1
[PATCH RFC 4/4] notes: add per-ref configuration of merge strategy
From: Jacob Keller
Teach git-notes about a new configuration option
"notes..merge" which selects the merge strategy for a
particular ref. This allows selection of merge strategy different for
each note reference, in addition to the default strategy for all
references.
Signed-off-by: Jacob Keller
Cc: Johan Herland
Cc: Michael Haggerty
Cc: Eric Sunshine
---
Documentation/config.txt| 7 +++
Documentation/git-notes.txt | 6 ++
builtin/notes.c | 115 +++-
t/t3309-notes-merge-auto-resolve.sh | 50
4 files changed, 176 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0fa88a29dd65..c53ec4538cd3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1918,6 +1918,13 @@ notes.merge::
STRATEGIES" section of linkgit:git-notes[1] for more information
on each strategy.
+notes..merge::
+ Which merge strategy to choose if the local ref for a notes merge
+ matches . Is overridden by notes.merge and takes the same
+ values. may be fully qualified or just under refs/notes/.
+ See "NOTES MERGE STRATEGIES" section in linkgit:git-notes[1] for more
+ information on each strategy.
+
notes.displayRef::
The (fully qualified) refname from which to show notes when
showing commit messages. The value of this variable can be set
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 9c4f8536182f..1e001807f9d9 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -322,6 +322,12 @@ notes.merge::
+
This setting can be overridden by passing the `--strategy` option.
+notes..merge::
+ Which strategy to choose when merging into . Uses the same
+ values as notes.merge. may be either a fully qualified ref
+ or the shortname under "refs/notes/". See "NOTES MERGE STRATEGIES"
+ section above for more information about each strategy.
+
notes.displayRef::
Which ref (or refs, if a glob or specified more than once), in
addition to the default set by `core.notesRef` or
diff --git a/builtin/notes.c b/builtin/notes.c
index de0caa00df1b..b0174d1024dc 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -92,6 +92,10 @@ static const char * const git_notes_get_ref_usage[] = {
static const char note_template[] =
"\nWrite/edit the notes for the following object:\n";
+static struct note_ref **note_refs;
+static int note_refs_alloc;
+static int note_refs_nr;
+static struct hashmap note_refs_hash;
static enum notes_merge_strategy merge_strategy;
struct note_data {
@@ -757,12 +761,87 @@ static int parse_notes_strategy(const char *arg, enum
notes_merge_strategy *stra
return 0;
}
+struct note_refs_hash_key {
+ const char *str;
+ int len;
+};
+
+struct note_ref {
+ struct hashmap_entry ent; /* must be first */
+
+ const char *name;
+ enum notes_merge_strategy merge_strategy;
+};
+
+static int note_refs_hash_cmp(const struct note_ref *a, const struct note_ref
*b, const struct note_refs_hash_key *key)
+{
+ if (key)
+ return strncmp(a->name, key->str, key->len) ||
a->name[key->len];
+ else
+ return strcmp(a->name, b->name);
+}
+
+static inline void init_note_refs_hash(void)
+{
+ if (!note_refs_hash.cmpfn)
+ hashmap_init(¬e_refs_hash,
(hashmap_cmp_fn)note_refs_hash_cmp, 0);
+}
+
+static struct note_ref *make_note_ref(const char *name, int len)
+{
+ struct note_ref *ret, *replaced;
+ struct note_refs_hash_key lookup;
+ struct hashmap_entry lookup_entry;
+
+ if (!len)
+ len = strlen(name);
+
+ init_note_refs_hash();
+ lookup.str = name;
+ lookup.len = len;
+ hashmap_entry_init(&lookup_entry, memhash(name, len));
+
+ if ((ret = hashmap_get(¬e_refs_hash, &lookup_entry, &lookup)) !=
NULL)
+ return ret;
+
+ ret = xcalloc(1, sizeof(struct note_ref));
+ ALLOC_GROW(note_refs, note_refs_nr + 1, note_refs_alloc);
+ note_refs[note_refs_nr++] = ret;
+ ret->name = xstrndup(name, len);
+
+ hashmap_entry_init(ret, lookup_entry.hash);
+ replaced = hashmap_put(¬e_refs_hash, ret);
+ assert(replaced == NULL); /* no previous entry overwritten */
+ return ret;
+}
+
+static void set_strategy_for_ref(const char *ref)
+{
+ const char *name = ref;
+ struct note_refs_hash_key lookup;
+ struct hashmap_entry lookup_entry;
+ struct note_ref *note;
+
+ skip_prefix(ref, "refs/notes/", &name);
+
+ init_note_refs_hash();
+ lookup.str = name;
+ lookup.len = strlen(name);
+
+ hashmap_entry_init(&lookup_entry, memhash(name, lookup.len));
+
+ note = hashmap_get(¬e_refs_hash, &lookup_entry, &lookup);
+ if (note != NULL)
+ merge_strategy = note->merge_strategy
Re: [PATCH v1] send-email: provide whitelist of SMTP AUTH mechanisms
On Sat, Aug 1, 2015 at 2:19 PM, Jan Viktorin wrote:
> On Sat, 1 Aug 2015 05:33:28 -0400 Eric Sunshine
> wrote:
>> On Fri, Jul 31, 2015 at 7:33 PM, Jan Viktorin
>> wrote:
>> At the very least, you will also want to update the documentation
>> (Documentation/git-send-email.txt) and, if possible, add new tests
>> (t/t9001-send-email.sh).
>
> I will update the documentation when it is clear, how the smtp-auth
> works.
>
> I have no idea, how to test the feature. I can see something like
> fake.sendmail in the file. How does it work? I can image a test whether
> user inserts valid values. What more?
That's what I was thinking. You could test if the die() is triggered
or if it emits warnings for bad values (assuming you implement that
feature). As for testing the actual authentication, I'm not sure you
can (and don't see any such testing in the script).
>> > diff --git a/git-send-email.perl b/git-send-email.perl
>> > index ae9f869..b00ed9d 100755
>> > --- a/git-send-email.perl
>> > +++ b/git-send-email.perl
>> > @@ -1129,6 +1134,16 @@ sub smtp_auth_maybe {
>> > return 1;
>> > }
>> >
>> > + # Do not allow arbitrary strings.
>>
>> Can you explain why this restriction is needed. What are the
>> consequences of not limiting the input to this "approved" list?
>
> This is more a check of an arbitrary user input then a check
> of an "approved list". It should be also used to inform user
> about invalid methods (however, I didn't implemented it yet).
What I was really asking was whether this sort of checking really
belongs in git-send-email or if it is better left to Net::SMTP (and
Authen::SASL) to do so since they are in better positions to know what
is valid and what is not. If the Perl module(s) generate suitable
diagnostics for bad input, then it makes sense to leave the checking
to them. If not, then I can understand your motivation for
git-send-email doing the checking instead in order to emit
user-friendly diagnostics.
So, that's what I meant when I asked 'What are the consequences of not
limiting the input to this "approved" list?'.
The other reason I asked was that it increases maintenance costs for
us to maintain a list of "approved" mechanisms, since the list needs
to be updated when new ones are implemented (and, as brian pointed
out, some may already exist which are not in your list).
>> > + $filtered_auth .= $_ . " ";
>>
>> Style question: Would this be more naturally expressed with
>> 'filtered_auth' as an array onto which items are pushed, rather than
>> as a string? At the point of use, the string can be recreated via
>> join().
>>
>> Not a big deal; just wondering.
>
> I am not a Perl programmer. Yesterday, I've discovered for the first
> time that Perl uses a dot for concatenation... I have no idea what
> happens when passing an array to Authen::SASL->new(). Moreover, the
> Perl arrays syntax rules scare me a bit ;).
You wouldn't pass the array to Authen::SASL, instead you would use
join() to transform the array back into a space-separated string. It's
probably moot (since you probably shouldn't be doing the filtering
manually), but the code would look something like this:
my @filtered_auth;
...
foreach (...) {
if (...) {
push @filtered_auth, $_;
}
}
...
if (@filtered_auth) {
my $sasl = Authen::SASL->new(
mechanism => join(' ', @filtered_auth),
...
>> Style: add "\n" at end in order to suppress printing of the
>> perl line number and input line number which aren't
>> very meaningful for a user error
>
> Another hidden Perl suprise, I guess...
Yes.
>> Also, don't you want to warn the user about tokens that don't match
>> one of the accepted (PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5), rather than
>> dropping them silently?
>
> Yes, this would be great (as I've already mentioned). It's a question
> whether to include the check for the mechanisms or whether to leave
> the $smtp_auth variable as it is... Maybe just validate by a regex?
>
> The naming rules are defiend here:
> https://tools.ietf.org/html/rfc4422#page-8
> So, this looks to me as a better way.
Maybe. This leads back to my original question of whether it's really
git-send-email's responsibility to do validation or if that can be
left to Net::SMTP/Authen::SASL. If the Perl module(s) emit suitable
diagnostics for bad input, then validation can be omitted from
git-send-email.
--
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
Re: [PATCH v2 2/2] notes: add notes.merge option to select default strategy
On Sun, Aug 2, 2015 at 1:01 AM, Eric Sunshine wrote: > Don't worry too much about it. Consider it something to keep in mind for > future patches. I reviewed the change and it seemed okay. I mentioned it > because one of the goals of patch submission, in addition to making an > actual change, is to ease the review process. If Junio is okay with > accepting it as is, then it's probably not worth spending more time > trying to refine it. > > Having said that, I came up with the following for those two paragraphs, > which gives a much less noisy diff and doesn't look too jagged: > Yea, I actually have re-worked it as well to something more suitable. I'm re-sending anyways as I fixed some of the other style issues and the one bug about not returning 0 on good read of the notes.merge value. Regards Jake -- 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
Re: [PATCH v2 2/2] notes: add notes.merge option to select default strategy
On Sun, Aug 02, 2015 at 12:41:08AM -0700, Jacob Keller wrote: > On Sat, Aug 1, 2015 at 7:46 PM, Eric Sunshine wrote: > >> If conflicts arise and a strategy for automatically resolving > >> -conflicting notes (see the -s/--strategy option) is not given, > >> -the "manual" resolver is used. This resolver checks out the > >> -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), > >> -and instructs the user to manually resolve the conflicts there. > >> -When done, the user can either finalize the merge with > >> -'git notes merge --commit', or abort the merge with > >> -'git notes merge --abort'. > >> +conflicting notes (see the -s/--strategy option or notes.merge > >> +config option) is not given, the "manual" resolver is used. > >> +This resolver checks out the conflicting notes in a special > >> +worktree (`.git/NOTES_MERGE_WORKTREE`), and instructs the user > >> +to manually resolve the conflicts there. When done, the user > >> +can either finalize the merge with 'git notes merge --commit', > >> +or abort the merge with 'git notes merge --abort'. > > > > When you re-wrap the text like this, it's difficult to spot your one > > little change in all the diff noise. For the sake of review, it's > > often better to minimize the change, even if it leaves the text more > > jagged than you'd like. > > This results in something incredibly jagged. I can't find a good way > to split which minimizes the change. Would a 3rd patch which just > re-flows this be an acceptable alternative > > ie: add the words in one patch then re-flow afterwards in a second > patch with no changes? > > There is no good alternative as other re-flows I tried end up looking > way too jagged, as compared to surrounding documentation. Don't worry too much about it. Consider it something to keep in mind for future patches. I reviewed the change and it seemed okay. I mentioned it because one of the goals of patch submission, in addition to making an actual change, is to ease the review process. If Junio is okay with accepting it as is, then it's probably not worth spending more time trying to refine it. Having said that, I came up with the following for those two paragraphs, which gives a much less noisy diff and doesn't look too jagged: --- 8< --- If conflicts arise and a strategy for automatically resolving -conflicting notes (see the -s/--strategy option) is not given, -the "manual" resolver is used. This resolver checks out the +conflicting notes (see -s/--strategy or notes.merge configuration) is +not given, the "manual" resolver is used. This resolver checks out the conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), and instructs the user to manually resolve the conflicts there. When done, the user can either finalize the merge with --- 8< --- ...and... --- 8< --- When merging notes, resolve notes conflicts using the given - strategy. The following strategies are recognized: "manual" + strategy. Overrides the "notes.merge" configuration variable. + The following strategies are recognized: "manual" (default), "ours", "theirs", "union" and "cat_sort_uniq". See the "NOTES MERGE STRATEGIES" section below for more information on each notes merge strategy. --- 8< --- -- 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
Re: [PATCH v2 2/2] notes: add notes.merge option to select default strategy
On Sat, Aug 1, 2015 at 7:46 PM, Eric Sunshine wrote: >> If conflicts arise and a strategy for automatically resolving >> -conflicting notes (see the -s/--strategy option) is not given, >> -the "manual" resolver is used. This resolver checks out the >> -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), >> -and instructs the user to manually resolve the conflicts there. >> -When done, the user can either finalize the merge with >> -'git notes merge --commit', or abort the merge with >> -'git notes merge --abort'. >> +conflicting notes (see the -s/--strategy option or notes.merge >> +config option) is not given, the "manual" resolver is used. >> +This resolver checks out the conflicting notes in a special >> +worktree (`.git/NOTES_MERGE_WORKTREE`), and instructs the user >> +to manually resolve the conflicts there. When done, the user >> +can either finalize the merge with 'git notes merge --commit', >> +or abort the merge with 'git notes merge --abort'. > > When you re-wrap the text like this, it's difficult to spot your one > little change in all the diff noise. For the sake of review, it's > often better to minimize the change, even if it leaves the text more > jagged than you'd like. This results in something incredibly jagged. I can't find a good way to split which minimizes the change. Would a 3rd patch which just re-flows this be an acceptable alternative ie: add the words in one patch then re-flow afterwards in a second patch with no changes? There is no good alternative as other re-flows I tried end up looking way too jagged, as compared to surrounding documentation. Regards, Jake -- 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
