[PATCH] MSVC: allow using ExtUtils::MakeMaker
Drop NO_PERL_MAKEMAKER from config.mak.uname for the MSVC platform. MakeMaker is available on Windows Perl implementations and installs modules to correct location, unlike NO_PERL_MAKEMAKER Makefile. Signed-off-by: Marat Radchenko --- config.mak.uname | 1 - 1 file changed, 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index fc5616d..6db4193 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -338,7 +338,6 @@ ifeq ($(uname_S),Windows) NO_MKSTEMPS = YesPlease SNPRINTF_RETURNS_BOGUS = YesPlease NO_SVN_TESTS = YesPlease - NO_PERL_MAKEMAKER = YesPlease RUNTIME_PREFIX = YesPlease NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease NO_NSEC = YesPlease -- 1.9.1 -- 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
Antw: Re: Q: ".git/HEAD" and ".git/refs/heads"
>>> Matthieu Moy schrieb am 02.04.2014 um 19:54
>>> in
Nachricht :
> "Ulrich Windl" writes:
>
>> Hi!
>>
>> I have a small question: After a "git gc" with last commit being "[shared
> 2679648]" I found this:
>>> cat .git/HEAD
>> ref: refs/heads/shared
>>> cat .git/refs/heads/shared
>> cat: .git/refs/heads/shared: No such file or directory
>>
>> Is this intentional?
>
> Yes.
>
>> commit in these files: .git/logs/HEAD .git/logs/refs/heads/shared
>> .git/info/refs .git/packed-refs
>
> Yes, they are where the refs are stored. If you have many refs in your
> repository, having one file per ref is inefficient. It's more efficient
> for Git to have one big read-only file. When one ref is modified, the
> .git/refs/heads/$branch file is re-created, and the packed entry is
> ignored.
>
>> if [ -d .git ]; then
>> GIT_HEAD="$(<.git/HEAD)"
>> GIT_BRANCH="${GIT_HEAD##*/}"
>> GIT_HEAD="Git:$GIT_BRANCH-$(cut -c1-7 .git/${GIT_HEAD##*: })"
>> fi
>
> Don't access the filesystem. Ask Git.
>
> GIT_FULL_BRANCH=$(git rev-parse --symbolic-full-name HEAD)
> GIT_BRANCH="${GIT_FULL_BRANCH##*/}"
> GIT_HEAD="Git:$GIT_BRANCH-$(git rev-parse --short HEAD)"
>
> (Perhaps there's a simpler way without $GIT_FULL_BRANCH)
Matthieu,
thanks for this (it not so abvious how to use "git --rev-parse")!
Ulrich
--
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] gitweb: Improve diffs when filenames contain problem characters
[Forgot to hit Reply-to-all instead of Reply. Andrew, I'm sorry for
duplicate email]
On Sat, Mar 29, 2014 at 2:53 PM, Andrew Keller wrote:
>
> When formatting a diff header line, be sure to escape the raw output from git
> for use as HTML. This ensures that when "problem characters" (&, <, >, ?,
> etc.)
> exist in filenames, gitweb displays them as text, rather than letting the
> browser interpret them as HTML.
Actually gitweb tries to do the right thing, and in most cases it does
HTML escaping correctly. The problem is only with *binary* files (this fact
should IMHO have been mentioned in commit message).
This issue is caused by two problems / errors. First, gitweb misclassify
"Binary files a/foo and b/bar differ" as diff header, while it is untypical
but it is diff contents. Second, gitweb doesn't HTML-escape unknown
diff headers, assuming that it knows about all possible types.
I have had those changes in my git repository, but I do not know if
I have pushed it before the PC went down, and if I have it in backup.
>
> Reported-by: Dongsheng Song
> Signed-off-by: Andrew Keller
Thank you for your work.
> ---
> Steps to reproduce:
>
> 1) Create a repository that contains a commit that adds a file:
> * with an ampersand in the filename
> * with binary contents
> 2) Make the repository visible to gitweb
> 3) In gitweb, navigate to the page that shows the diff for the commit
> that added the file
>
> Behavior without patch:
Page contains unescaped '&' instead of '&'
> Page stops rendering when it gets to one of
> the instances of the filename (in the diff header, to be specific), and
> a light-red box appears a the top of the page, saying something like
> this:
>
> This page contains the following errors:
>
> error on line 67 at column 22: xmlParseEntityRef: no name
>
> Below is a rendering of the page up to the first error.
>
>
> (This particular error is what you get with an unescaped ampersand)
This is caused by the fact that some browsers use strict XML validation
mode when receiving 'application/xml+xhtml' contents, and not 'text/html'.
So one might not notice it...
> Behavior with patch: You see the ampersand in the file name, and the
> page renders as one would expect.
A question: it does not escapes HTML twice, i.e. you don't see
'&' in rendered output ('&' in page source)?
> Other notes:
>
> Several helper methods exist for escaping HTML, and I was unsure
> about which one to use. Although this patch fixes the problem,
> it is possible that it may be more correct to use, for example, the
> 'esc_html' helper method instead of interacting with $cgi directly.
It is preferred to use esc_html instead of $cgi->escapeHTML.
Even better use esc_path to escape pathnames.
> The first hunk in the diff seems to be all that's required to experience
> the good behavior, however upon inspecting the code, it seems
> prudent to also include the second one. It's a nearby section of code,
> doing similar work, and is called from the same function as the
> former, and with similar arguments.
I wonder if it would not interfere with processing of diff contents
by gitweb, for example adding links to pre-image and post-image
version of a file.
> gitweb/gitweb.perl |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 79057b7..6c559f8 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2223,6 +2223,8 @@ sub format_git_diff_header_line {
> my $diffinfo = shift;
> my ($from, $to) = @_;
>
> + $line = $cgi->escapeHTML($line);
> +
> if ($diffinfo->{'nparents'}) {
> # combined diff
> $line =~ s!^(diff (.*?) )"?.*$!$1!;
> @@ -2259,6 +2261,8 @@ sub format_extended_diff_header_line {
> my $diffinfo = shift;
> my ($from, $to) = @_;
>
> + $line = $cgi->escapeHTML($line);
> +
> # match
> if ($line =~ s!^((copy|rename) from ).*$!$1! && $from->{'href'}) {
> $line .= $cgi->a({-href=>$from->{'href'}, -class=>"path"},
I'd have to examine code flow to check where it lands...
--
Jakub Narębski
--
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 00/22] Lockfile refactoring and pre-activation
On 04/01/2014 10:44 PM, Jeff King wrote: > [...] > I think all of the patches look good. I'd prefer to hold back the final > one (and probably 19/22, which has no purpose except to prepare for > 22/22) until seeing its application in practice. OK, I shuffled 19/22 to the end of the patch series, just before 22/22. That way both can be taken or left (probably left for now). > Thanks for a very pleasant read. Thanks for being a very pleasant (and thorough) reader :-) I'm still working on the backlog of comments and then I'll get back to the list with v2. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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] ls-files: do not trust stat info if lstat() fails
On Thu, Apr 3, 2014 at 1:15 AM, Junio C Hamano wrote: > I am guessing that, even though this was discovered during the > development of list-files, is a fix applicable outside the context > of that series. > > I do think the patched result is an improvement than the status quo, > but at the same time, I find it insufficient in the context of the > whole codepath. What if errno were other than ENOENT and we were > told to show_deleted (with or without show_modified)? We would end > up saying the path was deleted and modified at the same time, when > we do not know either is or is not true at all, because of the > failure to lstat() the path. > > Wouldn't it be saner to add tag_unknown and do something like this > instead, I wonder? Or even better to show an error message when the error code is unexpected? The unkown tag '!' says "there are problems" but if it shows up sort of permanently, '!' won't help much, I think. -- Duy -- 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 02/22] try_merge_strategy(): remove redundant lock_file allocation
On 04/02/2014 06:53 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Apr 01, 2014 at 05:58:10PM +0200, Michael Haggerty wrote:
>>
>>> By the time the "if" block is entered, the lock_file instance from the
>>> main function block is no longer in use, so re-use that one instead of
>>> allocating a second one.
>>>
>>> Note that the "lock" variable in the "if" block used to shadow the
>>> "lock" variable at function scope, so the only change needed is to
>>> remove the inner definition.
>>
>> I wonder if this would also be simpler if "lock" were simply declared as
>> a static variable, and we drop the allocation entirely. I suppose that
>> does create more cognitive load, though, in that it is only correct if
>> the function is not recursive. On the other hand, the current code makes
>> a reader unfamiliar with "struct lock" wonder if there is a free(lock)
>> missing.
>
> Another thing that makes a reader wonder if this is a valid rewrite
> is if it is safe to reuse a lock_file structure, especially because
> the original gives a piece of memory _cleared_ with xcalloc(). The
> second invocation of hold_locked_index() is now done on a dirty
> piece of memory, and the reader needs to drill down the callchain to
> see if that is safe (and if not, hold_locked_index() and probably
> the underlying lock_file() needs to memset() it to NULs).
It's good that you and Peff asked questions about this sort of thing.
We reuse lock_file structures *all over the place*; for example, just
search for "static struct lock_file". It has to be safe...
...and yet it isn't. Look in the definition of lock_file() (before my
changes):
static int lock_file(struct lock_file *lk, const char *path, int flags)
{
...
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
Remember that a reused lock_file structure is already in lock_file_list,
and there is already a signal handler registered that will call
remove_lock_file(), which looks like:
static void remove_lock_file(void)
{
pid_t me = getpid();
while (lock_file_list) {
if (lock_file_list->owner == me &&
lock_file_list->filename[0]) {
if (lock_file_list->fd >= 0)
close(lock_file_list->fd);
unlink_or_warn(lock_file_list->filename);
}
lock_file_list = lock_file_list->next;
}
}
So, if the process gets a signal during the call to resolve_symlink(),
the atexit() cleanup routine will delete the valuable file (the one
being locked)!
It definitely looks like this area needs more work.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
[ANNOUNCE] WinGit - native x86/x64 Git for Windows
I'm proud to announce WinGit: an attempt to bring Git powers to 64-bit Windows. WinGit is currently used only by my coworkers and isn't considered production-ready-rock-solid. Use at your own risk. Homepage & build instructions - https://github.com/slonopotamus/wingit Binaries MSI packages: https://github.com/slonopotamus/wingit/releases After installation, git.exe is ready to be used from cmd.exe or TortoiseGit. No kind of "Git Bash" or own explorer integration is provided. Issues -- Of course WinGit has issues: https://github.com/slonopotamus/wingit/issues?state=open Most notable are: git documentation is not packaged, no Tcl/Tk (thus, no gitk), no SVN, no Explorer integration. Sources -- All sources are available on GitHub: https://github.com/slonopotamus/wingit I know that build.sh is UGLY, especially openssl part. Relationship with msysgit = Unlike msysgit, WinGit is a pure-Windows binary build with MSVC. Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during build-time and runtime. WinGit adds a few patches to Git itself on top of msysgit ones. Patches are required due to insufficient testing of MSVC builds (caused by total absence of any MSVC-built Git distributions). All WinGit patches are sent upstream, just didn't get to master yet. -- 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] update-ref: fail create operation over stdin if ref already exists
On 04/02/2014 02:57 PM, Brad King wrote: > On 04/02/2014 04:09 AM, Michael Haggerty wrote: >> From: Aman Gupta > [snip] >> @@ -147,6 +147,7 @@ static void parse_cmd_create(const char *next) >> struct ref_update *update; >> >> update = update_alloc(); >> +update->have_old = 1; > > Looks good. > >> +test_expect_success 'stdin -z create ref fails when ref exists' ' > > Strictly speaking we should have a non-z mode test too. This code path is used regardless of whether -z is used, so I don't think it is necessary to duplicate the test. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
On Thu, 3 Apr 2014 17:18:50 +0400 ma...@slonopotamus.org wrote: > I'm proud to announce WinGit: > an attempt to bring Git powers to 64-bit Windows. [...] > Relationship with msysgit > = > > Unlike msysgit, WinGit is a pure-Windows binary build with MSVC. > > Like msysgit, WinGit also uses msys environment (sh/perl/etc) both > during build-time and runtime. > > WinGit adds a few patches to Git itself on top of msysgit ones. > Patches are required due to insufficient testing of MSVC builds > (caused by total absence of any MSVC-built Git distributions). > > All WinGit patches are sent upstream, just didn't get to master yet. What is the state of Unicode support in WinGit? -- 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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
On Thursday 03 April 2014 at 17:48:08 Konstantin Khomoutov wrote: > > What is the state of Unicode support in WinGit? I haven't seen any Unicode-related issues when using through TortoiseGit. Command-line usage is currently broken: no UTF-8 <->cmd.exe encoding conversion is performed. Fixing this is a high-priority issue though, most likely by migrating to newer (yet-to-be-released) msys lib. -- 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
Fwd: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
> > I know that build.sh is UGLY, especially openssl part. > > Unlike msysgit, WinGit is a pure-Windows binary build with MSVC. > > Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during > build-time and runtime. > > WinGit adds a few patches to Git itself on top of msysgit ones. > Patches are required due to insufficient testing of MSVC builds > (caused by total absence of any MSVC-built Git distributions). > I've created CMake files to be able to build git with MSVC without the need for msys. I haven't tested it with latest git and didn't really see the recent changes with respect to compilation with MSVC. But, if you're interested, let me know. Vincent -- 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 v3 2/3] patch-id: document new behaviour
"Michael S. Tsirkin" writes: > So I think I prefer using an option and not a heuristic if you > are fine with that. Sure. Changing behaviour only by explicit user request (command line or configuration) is much safer than heuristics that does not work reliably. -- 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 20/27] update-ref --stdin: Reimplement using reference transactions
Michael Haggerty writes: > I assumed that rolling back a non-consummated transaction in the case of > early program death should be the responsibility of the library, not of > the caller. If I'm correct, the caller(s) won't have to be modified > when the atexit facility is added, so I don't see a reason to add it > before it is needed by a concrete backend. > > But you suggest that the caller should be involved. I didn't say "should". If the library can automatically rollback without being called upon die() anywhere in the system, that is better. The suggestion was because I didn't think you were shooting for such a completeness in the library part, and a possible way out is for the caller to help. -- 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] ls-files: do not trust stat info if lstat() fails
Duy Nguyen writes: > On Thu, Apr 3, 2014 at 1:15 AM, Junio C Hamano wrote: >> I am guessing that, even though this was discovered during the >> development of list-files, is a fix applicable outside the context >> of that series. >> >> I do think the patched result is an improvement than the status quo, >> but at the same time, I find it insufficient in the context of the >> whole codepath. What if errno were other than ENOENT and we were >> told to show_deleted (with or without show_modified)? We would end >> up saying the path was deleted and modified at the same time, when >> we do not know either is or is not true at all, because of the >> failure to lstat() the path. >> >> Wouldn't it be saner to add tag_unknown and do something like this >> instead, I wonder? > > Or even better to show an error message when the error code is > unexpected? The unkown tag '!' says "there are problems" but if it > shows up sort of permanently, '!' won't help much, I think. I am OK with that approach, but then one question remains: should we say it is deleted, modified, both, or neither? -- 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: What's cooking in git.git (Mar 2014, #08; Mon, 31)
Heiko Voigt writes: > On Mon, Mar 31, 2014 at 05:29:03PM -0700, Junio C Hamano wrote: >> * hv/submodule-ignore-fix (2013-12-06) 4 commits >> - disable complete ignorance of submodules for index <-> HEAD diff >> - always show committed submodules in summary after commit >> - teach add -f option for ignored submodules >> - fix 'git add' to skip submodules configured as ignored >> >> Teach "git add" to be consistent with "git status" when changes to >> submodules are set to be ignored, to avoid surprises after checking >> with "git status" to see there isn't any change to be further added >> and then see that "git add ." adds changes to them. >> >> I think a reroll is coming, so this may need to be replaced, but I >> needed some practice with heavy conflict resolution. It conflicts >> with two changes to "git add" that have been scheduled for Git 2.0 >> quite badly, and I think I got the resolution right this time. >> >> Waiting for a reroll. > > Since Ronald and Jens picked up this topic[1], I think you can discard > my series. Thanks, will do. -- 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: Bug in git-diff output
Matthieu Moy writes:
> "rocketscienc01100101 ." writes:
>
>> http://i.imgur.com/BoJSjm9.png
>>
>> Here's a screenshot that shows the problem.
>
> (better cut-and-paste the text than sending a PNG image)
>
>> There's always a misplaced line in the output (most of the time
>> a[href^=tel] { }), no matter where in the file the changes are.
>
> The part after the @@ are ignored by patch tools. They are here just for
> convenience. They are a guess of what the patch hunk belongs to. For
> C/Java/Ada/... programs, it's the function name. Git does not know about
> CSS syntax, so it guesses wrong (last line starting with a letter I
> guess, not sure exactly what happens when Git doesn't know the syntax).
Ask "git grep -A14 'long def_ff' xdiff/" for details ;-)
This was an attempt to be compatible with stock behaviour of GNU
diff: a line that begins with an alpha, _ or $.
>> Sometimes it's even in the wrong position, above the @@ numbers.
>
> That is strange. Do you have a way to reproduce this?
That indeed is unusual. If the payload that was identified by the
find_func function has a funny escape sequence or something, you may
get funkiness like that in the output on the terminal, which we may
want to take notice and sanitize in xdl_emit_hunk_hdr(), instead of
straight memcpy() there, but I do not see how that would be an issue
in a css source.
--
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 v2 2/2] test/send-email: add to-cover test
Does it work? I am not sure. Signed-off-by: Michael S. Tsirkin --- t/t9001-send-email.sh | 16 1 file changed, 16 insertions(+) diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 3119c8c..3b17884 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh @@ -1334,6 +1334,22 @@ test_expect_success $PREREQ '--force sends cover letter template anyway' ' test -n "$(ls msgtxt*)" ' +test_expect_success $PREREQ 'to-cover adds To to all mail' ' + clean_fake_sendmail && + rm -fr outdir && + git format-patch --cover-letter -2 -o outdir && + git send-email \ + --force \ + --from="Example " \ + --to=nob...@example.com \ + --smtp-server="$(pwd)/fake.sendmail" \ + outdir/0002-*.patch \ + outdir/-*.patch \ + outdir/0001-*.patch \ + 2>errors >out && + ! grep "SUBJECT HERE" errors && + test -n "$(ls msgtxt*)" +' test_expect_success $PREREQ 'sendemail.aliasfiletype=mailrc' ' clean_fake_sendmail && echo "alias sbd someb...@example.org" >.mailrc && -- MST -- 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 v2 1/2] git-send-email: two new options: to-cover, cc-cover
Allow extracting To/Cc addresses from cover letter.
Signed-off-by: Michael S. Tsirkin
---
Documentation/git-send-email.txt | 12
git-send-email.perl | 16
2 files changed, 28 insertions(+)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index f0e57a5..1733664 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -248,6 +248,18 @@ Automating
cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
+--[no-]cc-cover::
+ If this is set, emails found in Cc: headers in the cover letter are
+ added to the cc list for each email set. Default is the value of
+ 'sendemail.cccover' configuration value; if that is unspecified,
+ default to --no-cc-cover.
+
+--[no-]to-cover::
+ If this is set, emails found in To: headers in the cover letter are
+ added to the to list for each email set. Default is the value of
+ 'sendemail.tocover' configuration value; if that is unspecified,
+ default to --no-to-cover.
+
--suppress-cc=::
Specify an additional category of recipients to suppress the
auto-cc of:
diff --git a/git-send-email.perl b/git-send-email.perl
index 8bbfb84..11d9a46 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -80,6 +80,8 @@ git send-email [options]
--to-cmd * Email To: via ` \$patch_path`
--cc-cmd * Email Cc: via ` \$patch_path`
--suppress-cc * author, self, sob, cc, cccmd, body,
bodycc, all.
+--[no-]cc-cover* Email Cc: addresses in the cover letter.
+--[no-]to-cover* Email To: addresses in the cover letter.
--[no-]signed-off-by-cc* Send to Signed-off-by: addresses. Default
on.
--[no-]suppress-from * Send to self. Default off.
--[no-]chain-reply-to * Chain In-Reply-To: fields. Default off.
@@ -195,6 +197,7 @@ sub do_edit {
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
+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);
@@ -211,6 +214,8 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 0],
"suppressfrom" => [\$suppress_from, undef],
"signedoffbycc" => [\$signed_off_by_cc, undef],
+"cccover" => [\$cover_cc, undef],
+"tocover" => [\$cover_to, undef],
"signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
"validate" => [\$validate, 1],
"multiedit" => [\$multiedit, undef],
@@ -302,6 +307,8 @@ my $rc = GetOptions("h" => \$help,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
+ "cc-cover|cc-cover!" => \$cover_cc,
+ "to-cover|to-cover!" => \$cover_to,
"confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
@@ -1468,6 +1475,15 @@ foreach my $t (@files) {
@to = (@initial_to, @to);
@cc = (@initial_cc, @cc);
+ if ($message_num == 1) {
+ if (defined $cover_cc and $cover_cc) {
+ @initial_cc = @cc;
+ }
+ if (defined $cover_to and $cover_to) {
+ @initial_to = @to;
+ }
+ }
+
my $message_was_sent = send_message();
# set up for the next message
--
MST
--
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 1/2] git-send-email: two new options: to-cover, cc-cover
"Michael S. Tsirkin" writes:
> Allow extracting To/Cc addresses from cover letter.
Please say what you are doing with what you extract, which is the
more important part of the objective. Extracting is merely a step
to achieve that.
s/.$/, to be used as To/Cc addresses of the remainder of the series./
or something.
I think this will be a very handy feature.
If you have a series *and* you bothered to add To/Cc to the cover
letter, it is likely that you want all the messages read by these
people [*1*].
> @@ -1468,6 +1475,15 @@ foreach my $t (@files) {
> @to = (@initial_to, @to);
> @cc = (@initial_cc, @cc);
>
> + if ($message_num == 1) {
> + if (defined $cover_cc and $cover_cc) {
> + @initial_cc = @cc;
> + }
> + if (defined $cover_to and $cover_to) {
> + @initial_to = @to;
> + }
> + }
> +
What is stored away with this code to @initial_cc/to includes:
- what was given to @initial_cc/to before ll.1468-1469
- what was in @cc/to before ll.1468-1469
when we see the first message [*2*]. The former come from the
command line --to/--cc, and the latter comes from the header lines
of the first message. Am I reading the code correctly?
If that is the case, I think the updated code makes sense.
Thanks.
[Footnote]
*1* Allowing this to be disabled is also a good thing this patch
does. A 100 patch series that does a tree-wide clean-up may
have different set of people on To/Cc of individual patches, and
you may want the union of them on To/Cc on the cover letter, so
that a person may get the cover letter and a single patch that
relates to his area of expertise without having to see the
remainder.
*2* The first message may not necessarily be the cover letter. Is
there a reliable way to detect that? The user may want to send
out a series with only a few patches without any cover, and
taking To/Cc from the [PATCH 1/3] and propagating them to the
rest does not match what the documentation and the option name
claim to do.
--
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: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)
> "Jonas Bang" writes: > > >> >> ... The default behaviour would cover their use case so your > >> >> proposal would not hurt them, but I wonder if there are things you > >> >> could do to help them as well, perhaps by allowing this new > >> >> configuration to express something like "local changes in these > >> >> paths are excempt from this new check". > >> > > >> > Yes, those people would probably use the default 'false' behavior > >> > as it is already. If they however would like to use e.g. the 'true' > >> > or 'include-untracked' setting as a configuration variable, then > >> > they can use the command line option 'false' if they wish to do a > >> > 'git checkout' even with modified files in the working tree. > >> > >> So in short, you are saying that "The added code necessary to > >> implement this feature will not help them in any way, it is just that > >> we will make sure it does not hurt them". > > > > I didn't realize they needed help. > > If so, then you could have just stated that way, instead of saying they have > an escape hatch ;-) > > It is perfectly fine to answer to "I wonder if there are things you could do?" > with "No, I am not going to help them with this series; I only make sure I do > not hurt them." and that is perfectly fine, as long as: > > - you do not directly hurt them with your series; and > > - you do not make it harder for those who are interested in helping >them to build on top of your work in the future. > > > How and who to decide if this is a reasonable feature request to accept? > > As this project primarily works on "scratch your own itch" basis, somebody > who (1) thinks that the proposed feature is worth having in our system and > (2) is interested in working on it will pick it up. > > If nobody is interested, then usually nothing happens. Thanks for your replies and your time. I'll cross my fingers for someone other than me and my identified group of users seeing the benefit of this feature request. Br, Jonas -- 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] test/send-email: add to-cover test
"Michael S. Tsirkin" writes: > Does it work? I am not sure. Then why was it sent here? > diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh > index 3119c8c..3b17884 100755 > --- a/t/t9001-send-email.sh > +++ b/t/t9001-send-email.sh > @@ -1334,6 +1334,22 @@ test_expect_success $PREREQ '--force sends cover > letter template anyway' ' > test -n "$(ls msgtxt*)" > ' > > +test_expect_success $PREREQ 'to-cover adds To to all mail' ' > + clean_fake_sendmail && > + rm -fr outdir && > + git format-patch --cover-letter -2 -o outdir && > + git send-email \ > + --force \ > + --from="Example " \ > + --to=nob...@example.com \ > + --smtp-server="$(pwd)/fake.sendmail" \ > + outdir/0002-*.patch \ > + outdir/-*.patch \ > + outdir/0001-*.patch \ > + 2>errors >out && > + ! grep "SUBJECT HERE" errors && > + test -n "$(ls msgtxt*)" > +' Is this a copy of an existing "--force can disable the safety to catch a mistake to send a cover letter template without any update"? How are you checking if you are propagating to/cc from the cover to other messages with this test? Puzzled. -- 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: socket_perror() "bug"?
Thiago Farina writes:
> On Mon, Mar 31, 2014 at 5:50 PM, Junio C Hamano wrote:
>> Thiago Farina writes:
>>
>>> In imap-send.c:socket_perror() we pass |func| as a parameter, which I
>>> think it is the name of the function that "called" socket_perror, or
>>> the name of the function which generated an error.
>>>
>>> But at line 184 and 187 it always assume it was SSL_connect.
>>>
>>> Should we instead call perror() and ssl_socket_error() with func?
>>
>> Looks that way to me, at least from a cursory look.
> Would you accept such a patch?
This back-and-forth makes me wonder what is going on. Why not send
a full patch with a proper proposed commit log message to the list
and see what happens?
> diff --git a/imap-send.c b/imap-send.c
> index 0bc6f7f..bb04768 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -181,10 +181,10 @@ static void socket_perror(const char *func,
> struct imap_socket *sock, int ret)
> case SSL_ERROR_NONE:
> break;
> case SSL_ERROR_SYSCALL:
> - perror("SSL_connect");
> + perror(func);
> break;
> default:
> - ssl_socket_perror("SSL_connect");
> + ssl_socket_perror(func);
> break;
> }
> } else
>
> --
> Thiago Farina
--
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] gitweb.conf.txt: fix typo
From: Jérôme Zago "build-time" is used everywhere else. Signed-off-by: Jérôme Zago --- Documentation/gitweb.conf.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 952f503..8b25a2f 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -482,7 +482,7 @@ project config. Per-repository configuration takes precedence over value composed from `@git_base_url_list` elements and project name. + You can setup one single value (single entry/item in this list) at build -time by setting the `GITWEB_BASE_URL` built-time configuration variable. +time by setting the `GITWEB_BASE_URL` build-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name. -- 1.9.1 -- 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 1/2] git-send-email: two new options: to-cover, cc-cover
On Thu, Apr 3, 2014 at 2:14 PM, Michael S. Tsirkin wrote:
> Allow extracting To/Cc addresses from cover letter.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> Documentation/git-send-email.txt | 12
> git-send-email.perl | 16
> 2 files changed, 28 insertions(+)
>
> diff --git a/Documentation/git-send-email.txt
> b/Documentation/git-send-email.txt
> index f0e57a5..1733664 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -248,6 +248,18 @@ Automating
> cc list. Default is the value of 'sendemail.signedoffbycc'
> configuration
> value; if that is unspecified, default to --signed-off-by-cc.
>
> +--[no-]cc-cover::
> + If this is set, emails found in Cc: headers in the cover letter are
> + added to the cc list for each email set. Default is the value of
s/email set/email sent/
> + 'sendemail.cccover' configuration value; if that is unspecified,
> + default to --no-cc-cover.
> +
> +--[no-]to-cover::
> + If this is set, emails found in To: headers in the cover letter are
> + added to the to list for each email set. Default is the value of
Ditto.
> + 'sendemail.tocover' configuration value; if that is unspecified,
> + default to --no-to-cover.
> +
> --suppress-cc=::
> Specify an additional category of recipients to suppress the
> auto-cc of:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 8bbfb84..11d9a46 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -80,6 +80,8 @@ git send-email [options] options >
> --to-cmd * Email To: via ` \$patch_path`
> --cc-cmd * Email Cc: via ` \$patch_path`
> --suppress-cc * author, self, sob, cc, cccmd, body,
> bodycc, all.
> +--[no-]cc-cover* Email Cc: addresses in the cover letter.
> +--[no-]to-cover* Email To: addresses in the cover letter.
> --[no-]signed-off-by-cc* Send to Signed-off-by: addresses.
> Default on.
> --[no-]suppress-from * Send to self. Default off.
> --[no-]chain-reply-to * Chain In-Reply-To: fields. Default off.
> @@ -195,6 +197,7 @@ sub do_edit {
>
> # Variables with corresponding config settings
> my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
> +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);
> @@ -211,6 +214,8 @@ my %config_bool_settings = (
> "chainreplyto" => [\$chain_reply_to, 0],
> "suppressfrom" => [\$suppress_from, undef],
> "signedoffbycc" => [\$signed_off_by_cc, undef],
> +"cccover" => [\$cover_cc, undef],
> +"tocover" => [\$cover_to, undef],
> "signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
> "validate" => [\$validate, 1],
> "multiedit" => [\$multiedit, undef],
> @@ -302,6 +307,8 @@ my $rc = GetOptions("h" => \$help,
> "suppress-from!" => \$suppress_from,
> "suppress-cc=s" => \@suppress_cc,
> "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
> + "cc-cover|cc-cover!" => \$cover_cc,
> + "to-cover|to-cover!" => \$cover_to,
> "confirm=s" => \$confirm,
> "dry-run" => \$dry_run,
> "envelope-sender=s" => \$envelope_sender,
> @@ -1468,6 +1475,15 @@ foreach my $t (@files) {
> @to = (@initial_to, @to);
> @cc = (@initial_cc, @cc);
>
> + if ($message_num == 1) {
> + if (defined $cover_cc and $cover_cc) {
> + @initial_cc = @cc;
> + }
> + if (defined $cover_to and $cover_to) {
> + @initial_to = @to;
> + }
> + }
> +
> my $message_was_sent = send_message();
>
> # set up for the next message
> --
> MST
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To 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 06/10] log: --function-name pickaxe
Am 27.03.2014 19:50, schrieb David A. Dalrymple (and Bhushan G. Lodha): From: "Bhushan G. Lodha & David A. Dalrymple" This is similar to the pickaxe grep option (-G), but applies the provided regex only to diff hunk headers, thereby showing only those commits which affect a "function" with a definition line matching the pattern. These are "functions" in the same sense as with --function-context, i.e., they may be classes, structs, etc. depending on the programming-language-specific pattern specified by the "diff" attribute in .gitattributes. With that approach you depend on the hunk header and apparently need to add XDL_EMIT_MOREFUNCNAMES and XDL_EMIT_MOREHUNKHEADS to improve the results. This approach feels fragile. Would it perhaps be more robust to not base the implementation on diff and instead to scan the raw file contents? You'd search both files for a matching function signature, then search for a non-matching one from there. The parts in between are function bodies and can be compared. If they match, you'd search for matching function starts again etc. Or would it make sense to make use of the diff option FUNCCONTEXT (git diff -W) and look for the function signature in the diff body instead of in the hunk header? Such a diff contains whole functions, but a single hunk could contain multiple ones. René -- 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 06/10] log: --function-name pickaxe
René Scharfe writes: > With that approach you depend on the hunk header and apparently need > to add XDL_EMIT_MOREFUNCNAMES and XDL_EMIT_MOREHUNKHEADS to improve > the results. This approach feels fragile. > > Would it perhaps be more robust to not base the implementation on diff > and instead to scan the raw file contents? That is an interesting idea. Perhaps this can be implemented as a new stage in the transformation pipeline, I wonder? There is currently no transformation that modifies the blob contents being compared, but I do not think there is anything fundamental that prevents one from being written. The new "limit to this function body" transformation would perhaps sit before the diffcore-rename and would transform all the blobs to empty, except for the part that is the body of the function the user is interested in. -- 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 0/7] fix hunk editing with 'commit -p -m'
Hi, A quick note for the future: Benoit Pierre wrote: > This patch fixes the fact that hunk editing with 'commit -p -m' does not work: > GIT_EDITOR is set to ':' to indicate to hooks that no editor will be launched, > which result in the 'hunk edit' option not launching the editor (and selecting > the whole hunk). This information should have gone in the relevant patch's commit message itself. That way, people don't have to hunt down the relevant mailing list thread to understand the patch. Generally a cover letter should say as little as possible (mostly "here is what patch you might want to look at first, and here is an overview of why the patches are in this particular order"). Thanks for a nice fix. Perhaps we'll see more in the future, hence this note. :) And if you have ideas for where an explanation of this could go in the documentation (somewhere in Documentation/SubmittingPatches?), that would be welcome too. Thanks, Jonathan -- 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
very important message.
I apologize for sending you this sensitive information via E-mail. In my banking department we discovered an abandoned sum of 10,000,000.00$ [Ten Million Dollars Only) in an account that belongs to one of our Foreign customers who unfortunately lost his life with his entire family on his way to the Airport of Heathrow. Since we got information about his death, we have been expecting his next of kin or relatives to come over and claim his funds because we cannot release it unless somebody applies for it as Next of kin or relation to the deceased as indicated in our banking guidelines. We want you to come in as the Next Of Kin, all needed cooperation to make the claims will be given to you by us. If you are interested kindly let us have the below information and I will give you more details. 1. Full name 2: Your private telephone and Fax numbers. 3. Occupations and Nationality. 4. Date of Birth 5, Present Location 6.Home Address We are offering 30% of the total sum to you as our partner. We will discuss much in details when I receive your response. Thanks and good luck to us. Email:philippepr...@bnpparibasbnk.com Best regards, Mr..Philippe Price. -- 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 20/27] update-ref --stdin: Reimplement using reference transactions
On 04/03/2014 05:57 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> I assumed that rolling back a non-consummated transaction in the case of >> early program death should be the responsibility of the library, not of >> the caller. If I'm correct, the caller(s) won't have to be modified >> when the atexit facility is added, so I don't see a reason to add it >> before it is needed by a concrete backend. >> >> But you suggest that the caller should be involved. > > I didn't say "should". If the library can automatically rollback > without being called upon die() anywhere in the system, that is > better. The suggestion was because I didn't think you were shooting > for such a completeness in the library part, and a possible way out > is for the caller to help. I was assuming that any ref backends that required rollback-on-fail would register an atexit handler and a signal handler, similar to how lock_file rollbacks are done. I admit that I haven't thought through all the details; for example, are there restrictions on the things that a signal handler is allowed to do that would preclude its being able to rollback the types of transactions that back ends might want to implement? (Though if so, what hope do we have that the caller can do better?) So, if somebody can think of a reason that we would need to involve the caller in cleanup, please speak up. Otherwise I think it would be less error-prone to leave this responsibility with the individual back ends. (And if something unexpected comes up, we can make this change later.) Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
