Re: How to use --cc-cmd in git-send-email?
From: Eric Sunshine sunsh...@sunshineco.com On Sun, Jul 19, 2015 at 6:02 PM, Philip Oakley philipoak...@iee.org wrote: I've been using git-send-email with repeated individual --cc=email address parameters on the command line. I tried putting all the addresses, one per line, into a file 'cc-cmd', so I could use if for the --cc-cmd option. I then tried to use --cc-cmd='cat cc-cmd' to do the send-email (as a --dry-run). This produced, as part of the output, a list of the output of the cc-cmd, which showed not only the file contents, but this was then followed by the full patch, as if it was part of the list of email addresses. git-send-email invokes the cc-cmd like this: $cc-cmd $patchfilename so, when you used 'cat cc-cmd' as the value of --cc-cmd, your invocation became: cat cc-cmd $patchfilename and since 'cat' copies the concatenation of its input files to its output, that explains why you first saw the names from your 'cc-cmd' file followed by the content of the patch file. Many thanks, that seems to explain everything! I'd tried to understand the code but I missed the nuances with my limited experience of perl coding. A quick-and-dirty work-around is to use '#' to effectively comment out the patch file name: --cc-cmd='cat cc-cmd #' which works, but is very, very ugly. But nicely quick and dirty ;-) Could this have been caused by an extra (blank) line at the end of the cc-cmd file? Nope. Also, does anyone have an example of a working --cc-cmd option? A very simple working solution is to make your 'cc-cmd' file executable: #!/bin/sh echo \EOF pers...@example.com pers...@example.com EOF I may try and do a small doc patch for the git-send-email.txt man page (I have a few doc fixes backing up waiting to be done ;-) -- Philip -- 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 5/9] ref-filter: add option to match literal pattern
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
Since 'ref-filter' only has an option to match path names add an
option for plain fnmatch pattern-matching.
This is to support the pattern matching options which are used in `git
tag -l` and `git branch -l` where we can match patterns like `git tag
-l foo*` which would match all tags which has a foo* pattern.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 85c561e..7ff3ded 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -966,6 +980,15 @@ static int match_name_as_path(const char **pattern,
const char *refname)
return 0;
}
+static int filter_pattern_match(struct ref_filter *filter, const char
*refname)
+{
+ if (!*filter-name_patterns)
+ return 1;
+ if (filter-match_as_path)
+ return match_name_as_path(filter-name_patterns, refname);
+ return match_pattern(filter-name_patterns, refname);
+}
+
/*
* Given a ref (sha1, refname), check if the ref belongs to the array
* of sha1s. If the given ref is a tag, check if the given tag points
@@ -1034,7 +1057,7 @@ static int ref_filter_handler(const char *refname,
const struct object_id *oid,
return 0;
}
- if (*filter-name_patterns
!match_name_as_path(filter-name_patterns, refname))
+ if (!filter_pattern_match(filter, refname))
return 0;
I find it much more difficult to grok the new logic due to
'*filter-name_patterns' having moved into the called function and its
negation inside the function returning 1 which is then negated (again)
upon return here. This sort of twisty logic places a higher cognitive
load on the reader. Retaining the original logic makes the code far
simpler to understand:
if (*filter-name_patterns
!filter_pattern_match(filter, refname))
return 0;
although it's a bit less nicely encapsulated, so I dunno...
if (filter-points_at.nr !match_points_at(filter-points_at,
oid-hash, refname))
--
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 on vagrant shared folder
Junio is absolutely right. I wasn’t trying to commit that file directly. The error comes up when I want to change the config via git config or when I clone the repo. I also know that a shared folder is not a very friendly environment, but it is the best solution for our situation here. We recognized the error first time in the beginning of july, so the change done in june 30 seems to be a reason. I will stay up to date and try it with newer git versions. Mit freundlichen Grüßen Peter Hüfner . e·confirm GmbH .. Travel.Software.Training.Consulting Geschäftsführer: Roman Borch und Michael Posthoff HRB 35653B Steuernummer 37/211/10880 10119 Berlin Linienstr. 214 Tel. +49 (0) 30 28 00 28 24 Fax. +49 (0) 30 28 00 28 28 www.e-confirm.de . Am 16.07.2015 um 18:41 schrieb Junio C Hamano gits...@pobox.com: Stefan Beller sbel...@google.com writes: A few weeks ago we weren’t able to clone and get an error: could not commit /vagrant/.git/config file. Manually we were able to change that file and also the clone command works outside the shared folder. Why are you trying to commit a file inside the .git dir? Files in that dir should not be commited (and I'm pretty sure there was a patch about this a while ago). The .git/config file for example is local to each git repo and should not be commited. Actually it is considered a security risk, see http://article.gmane.org/gmane.linux.kernel/1853266 I do not think Peter meant to git add .git/config git commit by referring to the 'could not commit config file' error message he saw; you two are going in a wrong direction. $ git grep 'could not commit' config.c: error(could not commit config file %s, config_filename); I do share Fredrik's suspicion that the virtual filesystem the Ubuntu guest is trying to write to is at fault, but I never used vagrant shared, and I do not know in what specific way their filesystem is not behaving as we expect. Applying 7a64592c (config.c: fix writing config files on Windows network shares, 2015-06-30) might be an interesting thing to try. Some filesystems do not want to rename a file that has mmaped region still active, which is my blind guess. -- 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 5/9] ref-filter: add option to match literal pattern
On Mon, Jul 20, 2015 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
Since 'ref-filter' only has an option to match path names add an
option for plain fnmatch pattern-matching.
This is to support the pattern matching options which are used in `git
tag -l` and `git branch -l` where we can match patterns like `git tag
-l foo*` which would match all tags which has a foo* pattern.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 85c561e..7ff3ded 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -966,6 +980,15 @@ static int match_name_as_path(const char **pattern,
const char *refname)
return 0;
}
+static int filter_pattern_match(struct ref_filter *filter, const char
*refname)
+{
+ if (!*filter-name_patterns)
+ return 1;
+ if (filter-match_as_path)
+ return match_name_as_path(filter-name_patterns, refname);
+ return match_pattern(filter-name_patterns, refname);
+}
+
/*
* Given a ref (sha1, refname), check if the ref belongs to the array
* of sha1s. If the given ref is a tag, check if the given tag points
@@ -1034,7 +1057,7 @@ static int ref_filter_handler(const char *refname,
const struct object_id *oid,
return 0;
}
- if (*filter-name_patterns
!match_name_as_path(filter-name_patterns, refname))
+ if (!filter_pattern_match(filter, refname))
return 0;
I find it much more difficult to grok the new logic due to
'*filter-name_patterns' having moved into the called function and its
negation inside the function returning 1 which is then negated (again)
upon return here. This sort of twisty logic places a higher cognitive
load on the reader. Retaining the original logic makes the code far
simpler to understand:
if (*filter-name_patterns
!filter_pattern_match(filter, refname))
return 0;
although it's a bit less nicely encapsulated, so I dunno...
I think a comment before filter_pattern_match() and perhaps also one
inside it might help. For example something like:
/* Return 1 if the refname matches one of the patterns, otherwise 0. */
static int filter_pattern_match(struct ref_filter *filter, const char *refname)
{
if (!*filter-name_patterns)
return 1; /* No pattern always matches */
if (filter-match_as_path)
return match_name_as_path(filter-name_patterns, refname);
return match_pattern(filter-name_patterns, refname);
}
--
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: [msysGit] [PATCH v2 10/16] engine.pl: delete the captured stderr file if empty
From: Eric Sunshine sunsh...@sunshineco.com
On Sun, Jul 19, 2015 at 4:08 PM, Philip Oakley philipoak...@iee.org
wrote:
Keep the build clean of extraneous files if it is indeed clean.
Otherwise leave the msvc-build-makedryerrors.txt file both as
a flag for any CI system or for manual debugging.
Note that the file will contain the new values of the GIT_VERSION
and GITGUI_VERSION if they were generated by the make file. They
are omitted if the release is tagged and indentically defined in
their respective GIT_VERSION_GEN file DEF_VER variables.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
diff --git a/contrib/buildsystems/engine.pl
b/contrib/buildsystems/engine.pl
index a6999b6..020776e 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -77,6 +77,8 @@ EOM
my $ErrsFile = msvc-build-makedryerrors.txt;
@makedry = `cd $git_dir make -n MSVC=1 V=1 2$ErrsFile` if
!@makedry;
+# test for an empty Errors file and remove it
+for ($ErrsFile) {unlink $_ if (-f $_) (!-s $_);}
Why the 'for' loop?
Also, if you're using the 'for' loop for the $_ side-effect, then why
not the simpler:
It was cargo cult programming, with some Google searching to select
between invocations. Most examples were looping through lists in
scripts, hence the down select.
for ($ErrsFile) { unlink if -f !-s; }
A lot better. Will fix.
?
# Parse the make output into usable info
parseMakeOutput();
--
2.4.2.windows.1.5.gd32afb6
--
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 tag: pre-receive hook issue
Hi Jake, Thanks about the refs/tags check. I’m aware about this. Junio also explained it in one of his replies. I was actually confused why my current code was working in past for few of the annotated tags. Anyways, now that I have clarity about the mistake in the code, I guess, I’ll figure it out myself. @Junio: Thanks a lot for your detailed explanation about the ‘behind the scenes’ activity during a push process. That was definitely helpful and will help me in future too. @Jake: Thanks for your help and your patience in explaining things. On Mon, Jul 20, 2015 at 5:05 AM, Jacob Keller [via git] ml-node+s661346n7635968...@n2.nabble.com wrote: To check whether the ref being updated is a tag, you need to check the 3rd parameter. pre-receive receives in the format old-value new-value ref-name so you need to check each line's 3rd value which is the ref-name being updated. If it's in refs/tags then it's a tag update. If it's not, you can check it as a branch update. Then you should check all new commits for each branch, as Julio mentioned above. Checking whether each commit has an associated tag is probably not what you meant. Regards, Jake On Sun, Jul 19, 2015 at 3:13 AM, Gaurav Chhabra [hidden email] wrote: The only thing we wanted to check was whether a ref is a tag. :) Rest other things are working fine (except for the commits=$new_sha1 thing which Junio already pointed out and corrected). I will correct the pre-receive hook. The only mystery that remains is about the current nonsensical code working fine in the past for few annotated tag pushes. It shouldn't have worked just by providing: RW+ refs/tags=developer_name Ref: http://gitolite.com/gitolite/g2/aac.html (Section: deny rules for refs in a repo) On Sun, Jul 19, 2015 at 2:09 PM, Jacob Keller [via git] [hidden email] wrote: On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra [hidden email] wrote: @Junio: So from your detailed explanation (and Jake's comment), i understand that since my ref wasn't updated on remote so querying the same using git describe resulted in failure, and hence, code was not entering the IF block. Correct? I assume so. Also, while i was reading your replies, i was just thinking that the following question that i asked Jake doesn't really make sense because a commit object _is_ being passed (on local machine) to git describe, which is what it expects so it should work for sure: It works yes. Git describe finds the nearest tag. --exact-match fails unless it can find a tag at the commit specified. If i got the above right, then shouldn't Git throw an error even on my local machine when i'm running git describe --exact-match ac28ca721e67a? only if ac28ca721e67a does not have an annotated tag associated to it @Junio: You wrote: The part that I find questionable is that by checking with is this commit a tagged one? and doing different things. What makes the initial and the third special to deserve checking (because they are not annotated with a tag) while skipping the validation for the second (merely because it has an annotated tag added to it)? Isn't the code that i shared doing just the opposite of what you've written? It's checking for annotated tags only and skipping the lightweight ones (although it shouldn't be doing all such things in the first place). Was it a typo on your part? I'm not sure what the code you have is trying to do. See below. @Jake: For the question you asked: It would help a lot if we understood exactly what you are trying to accomplish. I'm not sure how my colleague zeroed in on this git describe command but i at least know what we observed (and 'seemed' to work). We saw that if we use git-describe and pass a commit object, it throws fatal error message. On the other hand, if we pass a tag object, it doesn't throw any fatal error. That's the reason he added that tag check portion. Hmmm @Junio/Jake: After going through all the responses that i've received so far on this forum, i'm thinking how this nonsense code worked for few cases in the past? When this check was put in place, devs were getting error while pushing annotated tags. Since we use Gitolite, we added the following to gitolite.conf and the tag push worked for them: RW+ refs/tags=developer_name Sounds like you needed to add RW permissions to the refs/tags namespace. I'm wondering why. Ok, so normally, pre-receive hook is used to implement policy. Ie: prevent acceptance of pushes that have bad content as defined by the repository owner. For example, preventing push of tags that don't match some format, or preventing pushes which contain bad stuff. I could provide some examples or suggestions if you would describe what sort of policy you're trying to enforce.. git describe will tell you if the commit you're passing it is associated with an annotated tag. I do not understand who this information can help you implement any
Re: How to use --cc-cmd in git-send-email?
On Mon, Jul 20, 2015 at 2:01 AM, Philip Oakley philipoak...@iee.org wrote: From: Eric Sunshine sunsh...@sunshineco.com git-send-email invokes the cc-cmd like this: $cc-cmd $patchfilename so, when you used 'cat cc-cmd' as the value of --cc-cmd, your invocation became: cat cc-cmd $patchfilename and since 'cat' copies the concatenation of its input files to its output, that explains why you first saw the names from your 'cc-cmd' file followed by the content of the patch file. Many thanks, that seems to explain everything! I may try and do a small doc patch for the git-send-email.txt man page (I have a few doc fixes backing up waiting to be done ;-) That would be welcome. I don't think it's mentioned at all in git-send-email.txt that the --to-cmd/--cc-cmd commands are handed the patch pathname as an argument, so that's certainly something worth documenting. -- 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: [msysGit] [PATCH v2 08/16] engine.pl: ignore invalidcontinue.obj which is known to MSVC
From: Eric Sunshine sunsh...@sunshineco.com Sent: Monday, July 20,
2015 2:54 AM
On Sun, Jul 19, 2015 at 4:08 PM, Philip Oakley philipoak...@iee.org
wrote:
Commit 4b623d8 (MSVC: link in invalidcontinue.obj for better
POSIX compatibility, 2014-03-29) is not processed correctly
by the buildsystem. Ignore it.
What does not processed correctly mean? For a person reading the
commit message, but lacking your experience with this, not processed
correctly seems akin to it doesn't work[1].
True, it didn't work...
Can the commit message
provide a bit more detail?
In fact it is `parsing` (not just `processing`) the output of a
'make --dry-run', and essentially the old parser did not handle .obj
files correctly. The deliberate introduction of this .obj file had to be
handled, and given it's deliberate inclusion I wanted some deliberate
handling code.
A subsequent patch then fixes the generic .obj issue.
I'll update the commit message. Thanks for noticing the slack writing.
[1]: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
A timely reminder of this article...
Also split the .o and .obj processing; 'make' does not produce .obj
files. Only substitute filenames ending with .o when generating the
source .c filename.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
contrib/buildsystems/engine.pl | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/buildsystems/engine.pl
b/contrib/buildsystems/engine.pl
index 60c7a7d..9db3d43 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -289,7 +289,7 @@ sub handleLibLine
#exit(1);
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
push(@sources, $sourcefile);
push(@cflags, @{$compile_options{${sourcefile}_CFLAGS}});
push(@defines,
@{$compile_options{${sourcefile}_DEFINES}});
@@ -333,8 +333,12 @@ sub handleLinkLine
} elsif ($part =~ /\.(a|lib)$/) {
$part =~ s/\.a$/.lib/;
push(@libs, $part);
-} elsif ($part =~ /\.(o|obj)$/) {
+} elsif ($part eq 'invalidcontinue.obj') {
+# ignore - known to MSVC
+} elsif ($part =~ /\.o$/) {
push(@objfiles, $part);
+} elsif ($part =~ /\.obj$/) {
+# do nothing, 'make' should not be producing .obj, only
.o files
} else {
die Unhandled link option @ line $lineno: $part;
}
@@ -343,7 +347,7 @@ sub handleLinkLine
#exit(1);
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
push(@sources, $sourcefile);
push(@cflags, @{$compile_options{${sourcefile}_CFLAGS}});
push(@defines,
@{$compile_options{${sourcefile}_DEFINES}});
--
2.4.2.windows.1.5.gd32afb6
--
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: [msysGit] [PATCH v2 10/16] engine.pl: delete the captured stderr file if empty
On Mon, Jul 20, 2015 at 2:16 AM, Philip Oakley philipoak...@iee.org wrote:
From: Eric Sunshine sunsh...@sunshineco.com
On Sun, Jul 19, 2015 at 4:08 PM, Philip Oakley philipoak...@iee.org
wrote:
Keep the build clean of extraneous files if it is indeed clean.
Otherwise leave the msvc-build-makedryerrors.txt file both as
a flag for any CI system or for manual debugging.
Note that the file will contain the new values of the GIT_VERSION
and GITGUI_VERSION if they were generated by the make file. They
are omitted if the release is tagged and indentically defined in
their respective GIT_VERSION_GEN file DEF_VER variables.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
+# test for an empty Errors file and remove it
+for ($ErrsFile) {unlink $_ if (-f $_) (!-s $_);}
Why the 'for' loop?
Also, if you're using the 'for' loop for the $_ side-effect, then why
not the simpler:
It was cargo cult programming, with some Google searching to select between
invocations. Most examples were looping through lists in scripts, hence the
down select.
for ($ErrsFile) { unlink if -f !-s; }
A lot better. Will fix.
Although that works, I'm not sure that it's really all that desirable
due to the unnecessary and potentially confusing 'for' loop. I'd
probably just write it as:
unlink $ErrsFile if -f $ErrsFile !-s _;
The lone '_' is magical[1] in that it re-uses the stat() information
from the -f rather than stat'ing $ErrsFile again. I'd also probably
replace !-s (not non-zero size) with -z (zero size):
unlink $ErrsFile if -f $ErrsFile -z _;
And, if you're using Perl 5.10 or later, you could use a little
syntactic sugar[1] and stack the file test operators up against one
another:
unlink $ErrsFile if -f -z $ErrsFile;
which is the equivalent of the above with the sugar removed.
[1]: http://perldoc.perl.org/functions/-X.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: [msysGit] [PATCH v2 10/16] engine.pl: delete the captured stderr file if empty
From: Eric Sunshine sunsh...@sunshineco.com
On Mon, Jul 20, 2015 at 2:16 AM, Philip Oakley philipoak...@iee.org
wrote:
From: Eric Sunshine sunsh...@sunshineco.com
On Sun, Jul 19, 2015 at 4:08 PM, Philip Oakley
philipoak...@iee.org
wrote:
Keep the build clean of extraneous files if it is indeed clean.
Otherwise leave the msvc-build-makedryerrors.txt file both as
a flag for any CI system or for manual debugging.
Note that the file will contain the new values of the GIT_VERSION
and GITGUI_VERSION if they were generated by the make file. They
are omitted if the release is tagged and indentically defined in
their respective GIT_VERSION_GEN file DEF_VER variables.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
+# test for an empty Errors file and remove it
+for ($ErrsFile) {unlink $_ if (-f $_) (!-s $_);}
Why the 'for' loop?
Also, if you're using the 'for' loop for the $_ side-effect, then
why
not the simpler:
It was cargo cult programming, with some Google searching to select
between
invocations. Most examples were looping through lists in scripts,
hence the
down select.
for ($ErrsFile) { unlink if -f !-s; }
A lot better. Will fix.
Although that works, I'm not sure that it's really all that desirable
due to the unnecessary and potentially confusing 'for' loop. I'd
probably just write it as:
unlink $ErrsFile if -f $ErrsFile !-s _;
The lone '_' is magical[1] in that it re-uses the stat() information
from the -f rather than stat'ing $ErrsFile again. I'd also probably
replace !-s (not non-zero size) with -z (zero size):
unlink $ErrsFile if -f $ErrsFile -z _;
And, if you're using Perl 5.10 or later,
The Msysgit (@1.9.5) uses perl v5.8.8, while the newer G4W SDK uses perl
5, version 20, subversion 2 (v5.20.2), so there is a decision to be made
about whether to leave the Msysgit version behind.
While it would be nice to use the newest version, I'm minded that we
should keep a little backward compatibility with Msysgit, at least until
the new G4w has had a few 'proper' releases, so not use the magic
suggestion below.
I've cc'd dscho, Johannes, J6t and Sebastian in case they have any firm
opinions with respect to the Msysgit / G4W split.
you could use a little
syntactic sugar[1] and stack the file test operators up against one
another:
unlink $ErrsFile if -f -z $ErrsFile;
which is the equivalent of the above with the sugar removed.
[1]: http://perldoc.perl.org/functions/-X.html
--
Philip
--
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: How to use --cc-cmd in git-send-email?
From: Eric Sunshine sunsh...@sunshineco.com On Mon, Jul 20, 2015 at 2:01 AM, Philip Oakley philipoak...@iee.org wrote: From: Eric Sunshine sunsh...@sunshineco.com git-send-email invokes the cc-cmd like this: $cc-cmd $patchfilename so, when you used 'cat cc-cmd' as the value of --cc-cmd, your invocation became: cat cc-cmd $patchfilename and since 'cat' copies the concatenation of its input files to its output, that explains why you first saw the names from your 'cc-cmd' file followed by the content of the patch file. Many thanks, that seems to explain everything! I may try and do a small doc patch for the git-send-email.txt man page (I have a few doc fixes backing up waiting to be done ;-) That would be welcome. I don't think it's mentioned at all in git-send-email.txt that the --to-cmd/--cc-cmd commands are handed the patch pathname as an argument, so that's certainly something worth documenting. -- The other issue I noted was wondering what auto-cc is? It's only mentioned the once in: --suppress-cc=category Specify an additional category of recipients to suppress the auto-cc of: Is it a sort of double negative? Certainly I had no idea what an auto-cc was ;-) Philip -- 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 1/9] ref-filter: add option to align atoms to the left
On Mon, Jul 20, 2015 at 5:19 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..b81a08d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -53,6 +55,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { align },
Not a new issue, but some compilers (Solaris?) complain about the
trailing comma.
Ok will check.
};
/*
@@ -687,6 +690,17 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, align:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, align:, valp);
+ if (!valp[0])
+ die(_(No value given with 'align='));
The parser expects align:, but the error message talks about
align=. Also, current trend is to drop capitalization from the error
message.
Thanks will change.
+ strtoul_ui(valp, 10, ref-align_value);
+ if (ref-align_value 1)
+ die(_(Value should be greater than zero));
Drop capitalization. Also, the user seeing this message won't
necessarily know to which value this refers. Better would be to
provide context ('align:' value should be...), and even better would
be to show the actual value at fault:
die(_(value should be greater than zero: align:%u\n,
ref_align_value);
or something.
Makes sense, thanks :)
+ v-s = ;
+ continue;
} else
continue;
@@ -1254,17 +1268,38 @@ static void emit(const char *cp, const char *ep)
}
}
+static void assign_formating(struct ref_array_item *ref, int parsed_atom,
struct atom_value *v)
+{
+ if (v-s[0] ref-align_value) {
Mental note: v-s[0] is not NUL ('\0').
Also, in this code base, this is typically written *v-s rather than v-s[0].
My bad, got confused with that :)
+ unsigned int len = 0;
+ len = utf8_strwidth(v-s);
You initialize 'len' to 0 but then immediately re-assign it.
Will change.
+ if (ref-align_value len) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addstr(buf, v-s);
+ if (!v-s[0])
+ free((char *)v-s);
We know from the mental note above that v-s[0] is not NUL ('\0'),
so this 'if' statement can never be true, thus is dead code.
Yes, my bad. Will change.
+ strbuf_addchars(buf, ' ', ref-align_value - len);
+ v-s = strbuf_detach(buf, NULL);
+ }
+ ref-align_value = 0;
+ }
+}
Thanks.
--
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
Re: [PATCH v3 1/9] ref-filter: add option to align atoms to the left
On Mon, Jul 20, 2015 at 12:12 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..b81a08d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -53,6 +55,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { align },
Not a new issue, but some compilers (Solaris?) complain about the
trailing comma.
Hmm, are you sure? I thought we avoid trailing comma for enum
definitions, but not a list of values like this.
It's been years since I encountered such a compiler, so it's possible
that my brain is conflating different cases of trailing commas...
--
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 1/9] ref-filter: add option to align atoms to the left
On Mon, Jul 20, 2015 at 11:31 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Jul 20, 2015 at 1:22 PM, Karthik Nayak karthik@gmail.com wrote:
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..93f59aa 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -687,6 +690,17 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, align:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, align:, valp);
+ if (!valp[0])
+ die(_(no value given with 'align:'));
+ strtoul_ui(valp, 10, ref-align_value);
+ if (ref-align_value 1)
+ die(_(value should be greater than zero:
align:%u), ref-align_value);
+ v-s = ;
Mental note: v-s points at literal zero-length string ().
+ continue;
} else
continue;
@@ -1254,17 +1268,40 @@ static void emit(const char *cp, const char *ep)
}
}
+static void assign_formating(struct ref_array_item *ref, int parsed_atom,
struct atom_value *v)
+{
+ if (ref-align_value !starts_with(used_atom[parsed_atom],
align)) {
+ unsigned int len = 0;
+
+ if (*v-s)
+ len = utf8_strwidth(v-s);
+ if (ref-align_value len) {
+ struct strbuf buf = STRBUF_INIT;
+ if (*v-s)
+ strbuf_addstr(buf, v-s);
+ if (*v-s v-s[0] == '\0')
+ free((char *)v-s);
Is the v-s[0] == '\0' checking for the same literal zero-length
string assigned above? If so, attempting to free() that string doesn't
make sense, since it's not heap-allocated. Maybe you meant != '\0'?
Overall, this code is getting rather complex and difficult to follow
(especially with all the 'v-s' checks thrown in). Junio's proposed
'pseudo_atom' and 'ref_formatting_state' would go a long way toward
simplifying it.
You're right, thats what I meant.
Having a look at Junio's proposed idea.
--
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 2/3] doc: send-email; expand on the meaning of 'auto-cc'
Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/git-send-email.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index bc357b8..ddc8a11 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -282,7 +282,7 @@ Automation options --suppress-cc=category:: Specify an additional category of recipients to suppress the - auto-cc of: + inclusion of addresses added via other automation options: + -- - 'author' will avoid including the patch author -- 2.4.2.windows.1.5.gd32afb6 -- 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 1/3] doc: convert send-email option headings to nouns
... for ease of reference within the text. Except the 'Sending options' for which there wasn't an obvious noun phrase. Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/git-send-email.txt | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 7ae467b..bc357b8 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -41,8 +41,8 @@ and the Subject: of the message as the second line. OPTIONS --- -Composing -~ +Composition options +~~~ --annotate:: Review and edit each patch you're about to send. Default is the value @@ -147,8 +147,8 @@ Note that no attempts whatsoever are made to validate the encoding. the header is added, but it can be turned off by setting the `sendemail.xmailer` configuration variable to `false`. -Sending -~~~ +Sending options +~~~ --envelope-sender=address:: Specify the envelope sender used to send the emails. @@ -234,8 +234,8 @@ must be used for each option. commands and replies will be printed. Useful to debug TLS connection and authentication problems. -Automating -~~ +Automation options +~~ --to-cmd=command:: Specify a command to execute once per patch file which @@ -326,8 +326,8 @@ Failure to do so may not produce the expected result in the recipient's MUA. -Administering -~ +Administration options +~~ --confirm=mode:: Confirm just before sending: -- 2.4.2.windows.1.5.gd32afb6 -- 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 3/3] doc: give examples for send-email cc-cmd operation
Explain how the cc-cmd (and to-cmd) is invoked, along with two simple examples (and a how-not-to example) to help in getting started. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Philip Oakley philipoak...@iee.org --- http://article.gmane.org/gmane.comp.version-control.git/274302 --- Documentation/git-send-email.txt | 36 1 file changed, 36 insertions(+) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index ddc8a11..9f991cf 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -436,6 +436,42 @@ following commands: Note: the following perl modules are required Net::SMTP::SSL, MIME::Base64 and Authen::SASL +Creating a cc-cmd (and to-cmd) action +~ + +git-send-email invokes the cc-cmd like this: + + $cc-cmd $patchfilename + +Thus the patch itself can be processed to locate appropriate email address +information if required. + +A simple solution for a basic address list is to create a 'cc-cmd' file +(executable) which provides a list of addressees: + + #!/bin/sh + echo \EOF + pers...@example.com + pers...@example.com + EOF + +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + +and since 'cat' copies the concatenation of its input files to its output, +this adds the patch file to the address list resulting in an error +unable to extract a valid address from:. + +The quick-and-dirty work-around is to use '#' to effectively comment out +the patch file name: + +--cc-cmd='cat cc-cmd #' + +which works, but is very, very ugly. + + SEE ALSO linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5) -- 2.4.2.windows.1.5.gd32afb6 -- 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 0/3] Update send-email cc-cmd documentation
This mini series updates captures the details of how to use the cc-cmd option of send-email, following my abortive attempts to use a simple 'cat cc-cmd' invocation. The alternative text for 'auto-cc' has been somewhat guesses at. I haven't tested how well it lays out when docbook'ed. The series could be squashed together.. Philip Oakley (3): doc: convert send-email option headings to nouns doc: send-email; expand on the meaning of 'auto-cc' doc: give examples for send-email cc-cmd operation Documentation/git-send-email.txt | 54 +--- 1 file changed, 45 insertions(+), 9 deletions(-) -- 2.4.2.windows.1.5.gd32afb6 -- 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 2/3] doc: send-email; expand oon the meaning of 'auto-cc'
Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/git-send-email.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index bc357b8..ddc8a11 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -282,7 +282,7 @@ Automation options --suppress-cc=category:: Specify an additional category of recipients to suppress the - auto-cc of: + inclusion of addresses added via other automation options: + -- - 'author' will avoid including the patch author -- 2.4.2.windows.1.5.gd32afb6 -- 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 3/3] doc: give examples for send-email cc-cmd operation
On Mon, Jul 20, 2015 at 2:26 PM, Philip Oakley philipoak...@iee.org wrote: Explain how the cc-cmd (and to-cmd) is invoked, along with two simple examples (and a how-not-to example) to help in getting started. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Philip Oakley philipoak...@iee.org --- diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index ddc8a11..9f991cf 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -436,6 +436,42 @@ following commands: Note: the following perl modules are required Net::SMTP::SSL, MIME::Base64 and Authen::SASL +Creating a cc-cmd (and to-cmd) action +~ + +git-send-email invokes the cc-cmd like this: + + $cc-cmd $patchfilename + +Thus the patch itself can be processed to locate appropriate email address +information if required. + +A simple solution for a basic address list is to create a 'cc-cmd' file +(executable) which provides a list of addressees: Rather than calling this a simple solution, you might instead say that this is an example of a bare-bones script which just returns a fixed list of email addresses without attempting to extract any addresses from the patch file itself. + #!/bin/sh + echo \EOF + pers...@example.com + pers...@example.com + EOF I don't know if it deserves mention that the script must be executable (chmod +x) or should we assume that readers are smart enough to understand this implicitly? (It probably should be mentioned.) Other than those minor points, the above looks fine, however... +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + +and since 'cat' copies the concatenation of its input files to its output, +this adds the patch file to the address list resulting in an error +unable to extract a valid address from:. + +The quick-and-dirty work-around is to use '#' to effectively comment out +the patch file name: + +--cc-cmd='cat cc-cmd #' + +which works, but is very, very ugly. This entire above text about cat $addressfile seems awfully inappropriate for a manual page, especially the bit about the terrible cat $file # hack. SEE ALSO linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5) -- 2.4.2.windows.1.5.gd32afb6 -- 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 2/3] doc: send-email; expand oon the meaning of 'auto-cc'
This one, with oon in the subject, is incorrect. I made the same mistake yesterday, thinking that a fresh format-patch had/would over-write the previous patches, but I'd forgot, again, that the filename uses the subject line, so send-email picked up both versions .. doh. Sorry for the noise. - Original Message - From: Philip Oakley philipoak...@iee.org To: Git List git@vger.kernel.org Cc: Junio C Hamano gits...@pobox.com; Eric Sunshine sunsh...@sunshineco.com Sent: Monday, July 20, 2015 7:26 PM Subject: [PATCH 2/3] doc: send-email; expand oon the meaning of 'auto-cc' -- 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/5] mh: worktree-related doc fixes
On 07/19/2015 10:29 PM, Eric Sunshine wrote: This re-roll of Michael Haggerty's worktree-related documentation tweaks[1] takes my review comments into account and adds one new patch. Eric, Thanks for separating the wheat from the chaff. I'm still traveling, which I'll claim as an excuse for my poor responsiveness. All of your changes look good. I was wondering one thing: is there a value like never or false to which gc.worktreepruneexpire can be set to turn off pruning entirely? If so, it might be nice to mention it in the config manpage. Similarly for the other expiration grace time settings. But it's definitely not a blocker. 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
Re: [PATCH 2/2] Fix sed usage in tests to work around broken xpg4/sed on Solaris
Johannes Sixt j...@kdbg.org writes: I really wonder why the previous file+ mv -f file+ file dance needs to be replaced? The sed must be replaced because some versions on Solaris choke on the incomplete last line in the file. Switching from sed to perl is not being questioned. I think Dscho is asking about the use of -i, when the original idiom target+ mv -f target+ target worked perfectly fine. I.e. perl -p -e '...' file file+ mv file+ file -- 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 1/9] ref-filter: add option to align atoms to the left
Eric Sunshine sunsh...@sunshineco.com writes:
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..b81a08d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -53,6 +55,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { align },
Not a new issue, but some compilers (Solaris?) complain about the
trailing comma.
Hmm, are you sure? I thought we avoid trailing comma for enum
definitions, but not a list of values like this.
--
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 1/9] ref-filter: add option to align atoms to the left
Junio C Hamano gits...@pobox.com writes:
Your caller is iterating over the elements in a format string,
e.g. 'A %(align:20)%(foo) B %(bar) C', and its caller is iterating
over a list of refs, e.g. 'maint', 'master' branches. With that
format string, as long as %(foo) does not expand to something that
exceeds 20 display places or so, I'd expect literal 'B' for all refs
to align, but I do not think this code gives me that; what happens
if '%(foo)' happens to be an empty string for 'maint' but is a
string, say 'x', for 'master'?
Having looked at the caller once again, I have to say that the
interface to this function is poorly designed. 'info' might have
been a convenient place to keep the formatting state during this
loop (e.g. was the previous atom tell us to format this atom in a
special way and if so how?), but that state does not belong to the
'info' thing we are getting from our caller. It is something we'd
want to clear before we come into the for() loop, and mutate and
utilize while in the loop. For example, if the caller ever wants
to show the same ref twice by calling this function with the same
ref twice, and if the format string ended with %(align:N), you do
not want that leftover state to right-pad the first atom in the
second invocation.
Imagine that in the future you might want to affect how things are
formatted based on how much we have already output for the ref so
far (e.g. limiting the total line length). Where would you implement
such a feature and hook it in this loop?
I'd imagine that a sensible way to organize and structure the
codeflow to support this align and related enhancement we may want
to have in the future cleanly would be to teach print_value about
the formatting state and share it with this loop. Roughly...
void show_ref_array_item(struct ref_array_item *info, const char *format,
int quote_style)
{
const char *cp, *sp, *ep;
Insert something like this here:
struct ref_formatting_state state;
memset(state, 0, sizeof(state));
state.quote_style = quote_style;
for (cp = format; *cp (sp = find_next(cp)); cp = ep + 1) {
struct atom_value *atomv;
+ int parsed_atom;
ep = strchr(sp, ')');
if (cp sp)
emit(cp, sp);
- get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
+ parsed_atom = parse_ref_filter_atom(sp + 2, ep);
+ get_ref_atom_value(info, parsed_atom, atomv);
+ assign_formating(info, parsed_atom, atomv);
print_value(atomv, quote_style);
and replace all of the above with something like this (a separate
variable parsed_atom may not be necessary):
get_ref_atom_value(state, info,
parse_ref_filter_atom(sp + 2, ep), atomv);
print_value(state, atomv);
Things like %(align:20) are not really atoms in the sense that they
are not used as placeholders for attributes that refs being printed
have, but they are there solely in order to affect the formating
state. Introduce a new field struct atom_value.pseudo_atom to
tell print_value() that fact from get_ref_atom_value(), e.g.
static void print_value(struct ref_formatting_state *state,
struct atom_value *v)
{
struct strbuf value = STRBUF_INIT;
struct strbuf formatted = STRBUF_INIT;
if (v-pseudo_atom)
return;
if (state-pad_to_right) {
strbuf_addf(value, %.*s, state-pad_to_right, v-s);
state-pad_to_right = 0;
}
switch (state-quote_style) {
case QUOTE_SHELL:
sq_quote_buf(formatted, value.buf);
break;
...
}
fputs(formatted.buf, stdout);
strbuf_release(value);
strbuf_release(formatted);
}
or something like that. As this print_value() knows everything that
happens to a single output line during that loop and is allowed to
keep track of what it sees in 'state', this would give a natural and
codeflow to add 'limit the total line length' and things like that
if desired.
We may want to further clean up to update %(color) thing to clarify
that it is a pseudo atom. I suspect %(align:20)%(color:blue) would
do a wrong thing with the current code, and it would be a reasonable
thing to allow both of these interchangeably:
%(align:20)%(color:blue)%(refname:short)%(color:reset)
%(color:blue)%(align:20)%(refname:short)%(color:reset)
and implementation of that would become more obvious once you have a
more explicit formatting state that is known to and shared among
get_value(), the for() loop that walks the format string, and
print_value().
--
To unsubscribe from
Re: [PATCH v2] unpack-trees: don't update files with CE_WT_REMOVE set
Anatole tells me that this works for us. Thanks.
On Sat, 2015-07-18 at 15:37 +0700, Duy Nguyen wrote:
On Fri, Jul 17, 2015 at 05:19:27PM -0400, David Turner wrote:
Don't update files in the worktree from cache entries which are
flagged with CE_WT_REMOVE.
When a user does a sparse checkout, git removes files that are marked
with CE_WT_REMOVE (because they are out-of-scope for the sparse
checkout). If those files are also marked CE_UPDATE (for instance,
because they differ in the branch that is being checked out and the
outgoing branch), git would previously recreate them. This patch
prevents them from being recreated.
These erroneously-created files would also interfere with merges,
causing pre-merge revisions of out-of-scope files to appear in the
worktree.
Thank you both for catching this. Just a small suggestion. Perhaps we
should do this instead. apply_sparse_checkout() is the function where
all action manipulation (add, delete, update files..) for sparse
checkout occurs and it should not ask to delete and update both at the
same time.
-- 8 --
diff --git a/unpack-trees.c b/unpack-trees.c
index 2927660..d6cf849 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -224,6 +224,9 @@ static int check_updates(struct unpack_trees_options *o)
struct cache_entry *ce = index-cache[i];
if (ce-ce_flags CE_UPDATE) {
+ if (ce-ce_flags CE_WT_REMOVE)
+ die(BUG: both update and delete flags are set
on %s,
+ ce-name);
display_progress(progress, ++cnt);
ce-ce_flags = ~CE_UPDATE;
if (o-update !o-dry_run) {
@@ -293,6 +296,7 @@ static int apply_sparse_checkout(struct index_state
*istate,
if (!(ce-ce_flags CE_UPDATE) verify_uptodate_sparse(ce,
o))
return -1;
ce-ce_flags |= CE_WT_REMOVE;
+ ce-ce_flags = ~CE_UPDATE;
}
if (was_skip_worktree !ce_skip_worktree(ce)) {
if (verify_absent_sparse(ce,
ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
-- 8 --
--
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 v3 1/9] ref-filter: add option to align atoms to the left
On Mon, Jul 20, 2015 at 1:22 PM, Karthik Nayak karthik@gmail.com wrote:
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..93f59aa 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -687,6 +690,17 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, align:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, align:, valp);
+ if (!valp[0])
+ die(_(no value given with 'align:'));
+ strtoul_ui(valp, 10, ref-align_value);
+ if (ref-align_value 1)
+ die(_(value should be greater than zero:
align:%u), ref-align_value);
+ v-s = ;
Mental note: v-s points at literal zero-length string ().
+ continue;
} else
continue;
@@ -1254,17 +1268,40 @@ static void emit(const char *cp, const char *ep)
}
}
+static void assign_formating(struct ref_array_item *ref, int parsed_atom,
struct atom_value *v)
+{
+ if (ref-align_value !starts_with(used_atom[parsed_atom],
align)) {
+ unsigned int len = 0;
+
+ if (*v-s)
+ len = utf8_strwidth(v-s);
+ if (ref-align_value len) {
+ struct strbuf buf = STRBUF_INIT;
+ if (*v-s)
+ strbuf_addstr(buf, v-s);
+ if (*v-s v-s[0] == '\0')
+ free((char *)v-s);
Is the v-s[0] == '\0' checking for the same literal zero-length
string assigned above? If so, attempting to free() that string doesn't
make sense, since it's not heap-allocated. Maybe you meant != '\0'?
Overall, this code is getting rather complex and difficult to follow
(especially with all the 'v-s' checks thrown in). Junio's proposed
'pseudo_atom' and 'ref_formatting_state' would go a long way toward
simplifying it.
+ strbuf_addchars(buf, ' ', ref-align_value - len);
+ v-s = strbuf_detach(buf, NULL);
+ }
+ ref-align_value = 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: How to use --cc-cmd in git-send-email?
On Mon, Jul 20, 2015 at 10:20 AM, Philip Oakley philipoak...@iee.org wrote: From: Eric Sunshine sunsh...@sunshineco.com On Mon, Jul 20, 2015 at 2:01 AM, Philip Oakley philipoak...@iee.org wrote: I may try and do a small doc patch for the git-send-email.txt man page (I have a few doc fixes backing up waiting to be done ;-) That would be welcome. I don't think it's mentioned at all in git-send-email.txt that the --to-cmd/--cc-cmd commands are handed the patch pathname as an argument, so that's certainly something worth documenting. The other issue I noted was wondering what auto-cc is? It's only mentioned the once in: --suppress-cc=category Specify an additional category of recipients to suppress the auto-cc of: Is it a sort of double negative? Certainly I had no idea what an auto-cc was ;-) I presume that auto-cc refers to git-send-email's behavior of figuring out whom to cc: automatically (by gleaning email addresses from various sources, such as the patch itself, cc-cmd, etc.). Even just saying ...suppress the automatic cc:'ing... would be an improvement, though it may deserve its own little paragraph explaining that automatic cc:'ing is occurring and from where the email addresses are gleaned. -- 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: [msysGit] [PATCH v2 10/16] engine.pl: delete the captured stderr file if empty
On Mon, Jul 20, 2015 at 7:55 AM, Philip Oakley philipoak...@iee.org wrote: From: Eric Sunshine sunsh...@sunshineco.com Although that works, I'm not sure that it's really all that desirable due to the unnecessary and potentially confusing 'for' loop. I'd probably just write it as: unlink $ErrsFile if -f $ErrsFile !-s _; The lone '_' is magical[1] in that it re-uses the stat() information from the -f rather than stat'ing $ErrsFile again. I'd also probably replace !-s (not non-zero size) with -z (zero size): unlink $ErrsFile if -f $ErrsFile -z _; And, if you're using Perl 5.10 or later, The Msysgit (@1.9.5) uses perl v5.8.8, while the newer G4W SDK uses perl 5, version 20, subversion 2 (v5.20.2), so there is a decision to be made about whether to leave the Msysgit version behind. While it would be nice to use the newest version, I'm minded that we should keep a little backward compatibility with Msysgit, at least until the new G4w has had a few 'proper' releases, so not use the magic suggestion below. you could use a little syntactic sugar[1] and stack the file test operators up against one another: unlink $ErrsFile if -f -z $ErrsFile; Since msysgit is only at Perl 5.8.8, it makes plenty of sense to just stick with: unlink $ErrsFile if -f $ErrsFile -z _; since it's only a tiny bit more verbose than: unlink $ErrsFile if -f -z $ErrsFile; and then you don't have to worry about needing a more modern Perl version. -- 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 5/9] ref-filter: add option to match literal pattern
On Mon, Jul 20, 2015 at 4:01 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Mon, Jul 20, 2015 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote:
+static int filter_pattern_match(struct ref_filter *filter, const char
*refname)
+{
+ if (!*filter-name_patterns)
+ return 1;
+ if (filter-match_as_path)
+ return match_name_as_path(filter-name_patterns, refname);
+ return match_pattern(filter-name_patterns, refname);
+}
@@ -1034,7 +1057,7 @@ static int ref_filter_handler(const char *refname,
const struct object_id *oid,
- if (*filter-name_patterns
!match_name_as_path(filter-name_patterns, refname))
+ if (!filter_pattern_match(filter, refname))
return 0;
I find it much more difficult to grok the new logic due to
'*filter-name_patterns' having moved into the called function and its
negation inside the function returning 1 which is then negated (again)
upon return here. This sort of twisty logic places a higher cognitive
load on the reader. Retaining the original logic makes the code far
simpler to understand:
if (*filter-name_patterns
!filter_pattern_match(filter, refname))
return 0;
although it's a bit less nicely encapsulated, so I dunno...
I think a comment before filter_pattern_match() and perhaps also one
inside it might help. For example something like:
/* Return 1 if the refname matches one of the patterns, otherwise 0. */
static int filter_pattern_match(struct ref_filter *filter, const char
*refname)
{
if (!*filter-name_patterns)
return 1; /* No pattern always matches */
if (filter-match_as_path)
return match_name_as_path(filter-name_patterns, refname);
return match_pattern(filter-name_patterns, refname);
}
Yes, the comments do improve the situation and may be a reasonable compromise...
--
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 2/3] doc: send-email; expand on the meaning of 'auto-cc'
On Mon, Jul 20, 2015 at 2:26 PM, Philip Oakley philipoak...@iee.org wrote: doc: send-email; expand on the meaning of 'auto-cc' s/;/:/ Signed-off-by: Philip Oakley philipoak...@iee.org --- diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index bc357b8..ddc8a11 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -282,7 +282,7 @@ Automation options --suppress-cc=category:: Specify an additional category of recipients to suppress the - auto-cc of: + inclusion of addresses added via other automation options: + -- - 'author' will avoid including the patch author -- 2.4.2.windows.1.5.gd32afb6 -- 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/9] ref-filter: add option to align atoms to the left
From: Karthik Nayak karthik@gmail.com
Add a new atom align and support %(align:X) where X is a number.
This will align the preceeding atom value to the left followed by
spaces for a total length of X characters. If X is less than the item
size, the entire atom value is printed.
Helped-by: Duy Nguyen pclo...@gmail.com
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
ref-filter.c | 41 +++--
ref-filter.h | 1 +
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..93f59aa 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -10,6 +10,8 @@
#include quote.h
#include ref-filter.h
#include revision.h
+#include utf8.h
+#include git-compat-util.h
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
@@ -53,6 +55,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { align },
};
/*
@@ -620,7 +623,7 @@ static void populate_value(struct ref_array_item *ref)
const char *name = used_atom[i];
struct atom_value *v = ref-value[i];
int deref = 0;
- const char *refname;
+ const char *refname = NULL;
const char *formatp;
struct branch *branch = NULL;
@@ -687,6 +690,17 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, align:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, align:, valp);
+ if (!valp[0])
+ die(_(no value given with 'align:'));
+ strtoul_ui(valp, 10, ref-align_value);
+ if (ref-align_value 1)
+ die(_(value should be greater than zero:
align:%u), ref-align_value);
+ v-s = ;
+ continue;
} else
continue;
@@ -1254,17 +1268,40 @@ static void emit(const char *cp, const char *ep)
}
}
+static void assign_formating(struct ref_array_item *ref, int parsed_atom,
struct atom_value *v)
+{
+ if (ref-align_value !starts_with(used_atom[parsed_atom], align)) {
+ unsigned int len = 0;
+
+ if (*v-s)
+ len = utf8_strwidth(v-s);
+ if (ref-align_value len) {
+ struct strbuf buf = STRBUF_INIT;
+ if (*v-s)
+ strbuf_addstr(buf, v-s);
+ if (*v-s v-s[0] == '\0')
+ free((char *)v-s);
+ strbuf_addchars(buf, ' ', ref-align_value - len);
+ v-s = strbuf_detach(buf, NULL);
+ }
+ ref-align_value = 0;
+ }
+}
+
void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style)
{
const char *cp, *sp, *ep;
for (cp = format; *cp (sp = find_next(cp)); cp = ep + 1) {
struct atom_value *atomv;
+ int parsed_atom;
ep = strchr(sp, ')');
if (cp sp)
emit(cp, sp);
- get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
+ parsed_atom = parse_ref_filter_atom(sp + 2, ep);
+ get_ref_atom_value(info, parsed_atom, atomv);
+ assign_formating(info, parsed_atom, atomv);
print_value(atomv, quote_style);
}
if (*cp) {
diff --git a/ref-filter.h b/ref-filter.h
index 6bf27d8..12ffbc5 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -30,6 +30,7 @@ struct ref_sorting {
struct ref_array_item {
unsigned char objectname[20];
int flag;
+ unsigned int align_value;
const char *symref;
struct commit *commit;
struct atom_value *value;
--
2.4.6
--
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 tag: pre-receive hook issue
On Mon, 2015-07-20 at 13:13 +0530, Gaurav Chhabra wrote: Hi Jake, Thanks about the refs/tags check. I’m aware about this. Junio also explained it in one of his replies. I was actually confused why my current code was working in past for few of the annotated tags. Anyways, now that I have clarity about the mistake in the code, I guess, I’ll figure it out myself. @Junio: Thanks a lot for your detailed explanation about the ‘behind the scenes’ activity during a push process. That was definitely helpful and will help me in future too. @Jake: Thanks for your help and your patience in explaining things. No problem. I'm also not certain why it would have worked in some cases, so that is definitely confusing, but at least you can get it sorted to do what you intend. Best of luck! Regards, Jake
Re: [PATCH v3 4/9] ref-filter: add support to sort by version
On Mon, Jul 20, 2015 at 7:09 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
To agree with the actual code: s/version_cmp/versioncmp/
Yeah! will change.
Assuming I'm a reader without prior knowledge, the first question
which pops into my mind is what's the difference between
'version:refname' and 'v:refname'? Is one just shorthand for the
other, or is there some subtle difference in behavior, or what? The
documentation should explain this better.
Will include more explanation.
Also, why are there parentheses around 'version:refname' or
'v:refname'? And, you should use backticks rather than apostrophes, as
is done with the other field names.
Wanted to show that they are the same command. Seems confusing now that
you mentioned, will change it.
In any case, a field name that refers to a field inapplicable to
the object referred by the ref does not cause an error. It
diff --git a/ref-filter.c b/ref-filter.c
index 82731ac..85c561e 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1169,18 +1170,22 @@ static int cmp_ref_sorting(struct ref_sorting *s,
struct ref_array_item *a, stru
get_ref_atom_value(a, s-atom, va);
get_ref_atom_value(b, s-atom, vb);
- switch (cmp_type) {
- case FIELD_STR:
- cmp = strcmp(va-s, vb-s);
- break;
- default:
- if (va-ul vb-ul)
- cmp = -1;
- else if (va-ul == vb-ul)
- cmp = 0;
- else
- cmp = 1;
- break;
+ if (s-version)
+ cmp = versioncmp(va-s, vb-s);
+ else {
+ switch (cmp_type) {
+ case FIELD_STR:
+ cmp = strcmp(va-s, vb-s);
+ break;
+ default:
+ if (va-ul vb-ul)
+ cmp = -1;
+ else if (va-ul == vb-ul)
+ cmp = 0;
+ else
+ cmp = 1;
+ break;
+ }
The logic might be slightly easier to follow, and give a much less
noisy diff if you rewrite it like this instead:
if (s-version)
cmp = versioncmp(va-s, vb-s);
else if (cmp_type == FIELD_STR)
cmp = strcmp(va-s, vb-s);
else {
if (va-ul vb-ul)
cmp = -1;
else if (va-ul == vb-ul)
cmp = 0;
else
cmp = 1;
}
Or, if you don't mind a noisy diff, you can outdent the other branches, as
well:
if (s-version)
cmp = versioncmp(va-s, vb-s);
else if (cmp_type == FIELD_STR)
cmp = strcmp(va-s, vb-s);
else if (va-ul vb-ul)
cmp = -1;
else if (va-ul == vb-ul)
cmp = 0;
else
cmp = 1;
(I rather prefer the latter, despite the noisy diff.)
Err! just didn't want to existing code. Your latter code usage seems
easier and simpler to follow. Will use that thanks :D
}
return (s-reverse) ? -cmp : cmp;
}
diff --git a/ref-filter.h b/ref-filter.h
index 7dfdea0..6f1646b 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -25,7 +25,7 @@ struct atom_value {
struct ref_sorting {
struct ref_sorting *next;
int atom; /* index into used_atom array (internal) */
- unsigned reverse : 1;
+ unsigned reverse : 1, version : 1;
This is difficult to read. Style elsewhere (if I'm not mistaken) is to
place the declaration on a line by itself.
Yes just checked, thats the style. Thank you.
};
struct ref_array_item {
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index 505a360..c31fd2f 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -81,4 +81,30 @@ test_expect_success 'filtering with --contains' '
test_cmp expect actual
'
+test_expect_success 'version sort' '
+ git tag -l --sort=version:refname | grep foo actual
+ cat expect -\EOF
+ foo1.3
+ foo1.6
+ foo1.10
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'reverse version sort' '
+ git tag -l --sort=-version:refname | grep foo actual
Maybe use 'v:refname' in one of these tests in order to exercise that
alias as well?
The idea was to only include a minimal test as t7004 has tests for the same,
but I guess a minimal test for 'v:refname' is also required.
--
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
Re: [PATCH v3 3/9] ref-filter: support printing N lines from tag annotation
On Mon, Jul 20, 2015 at 5:32 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, Jul 18, 2015 at 3:12 PM, Karthik Nayak karthik@gmail.com wrote: In 'tag.c' we can print N lines from the annotation of the tag using the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and modify 'ref-filter' to support printing of N lines from the annotation of tags. Signed-off-by: Karthik Nayak karthik@gmail.com --- diff --git a/ref-filter.c b/ref-filter.c index 771c48d..82731ac 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1288,7 +1288,48 @@ static void assign_formating(struct ref_array_item *ref, int parsed_atom, struct } } -void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style) +/* Print 'lines' no of lines of a given oid */ This is difficult to read and understand. I presume you meant no. as shorthand for number but dropped the period. Even with the period, it's still hard to read. Perhaps rewrite it as: If 'lines' is greater than 0, print that may lines of... or something. Ah okay :) Will change it to a better explanation. diff --git a/ref-filter.h b/ref-filter.h index c18781b..7dfdea0 100644 --- a/ref-filter.h +++ b/ref-filter.h @@ -87,8 +88,11 @@ int parse_ref_filter_atom(const char *atom, const char *ep); int verify_ref_format(const char *format); /* Sort the given ref_array as per the ref_sorting provided */ void ref_array_sort(struct ref_sorting *sort, struct ref_array *array); -/* Print the ref using the given format and quote_style */ -void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style); +/* + * Print the ref using the given format and quote_style. If lines 0, + * prints the lines no of lines of the objected pointed to. + */ Same problem. This literal no is quite confusing. Perhaps rewrite as above: If lines 0, print that many lines of... Will change this too. +void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style, unsigned int lines); ref-filter.h seems to be setting a precedent for overlong lines. Wrapping this manually could improve readability. Definitely! Thanks for all the suggestions. -- 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
Re: [PATCH v3 1/9] ref-filter: add option to align atoms to the left
Karthik Nayak karthik@gmail.com writes:
@@ -687,6 +690,17 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, align:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, align:, valp);
+ if (!valp[0])
+ die(_(No value given with 'align='));
+ strtoul_ui(valp, 10, ref-align_value);
+ if (ref-align_value 1)
+ die(_(Value should be greater than zero));
+ v-s = ;
+ continue;
} else
continue;
@@ -1254,17 +1268,38 @@ static void emit(const char *cp, const char *ep)
}
}
+static void assign_formating(struct ref_array_item *ref, int parsed_atom,
struct atom_value *v)
+{
+ if (v-s[0] ref-align_value) {
+ unsigned int len = 0;
+
+ len = utf8_strwidth(v-s);
+ if (ref-align_value len) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addstr(buf, v-s);
+ if (!v-s[0])
+ free((char *)v-s);
+ strbuf_addchars(buf, ' ', ref-align_value - len);
+ v-s = strbuf_detach(buf, NULL);
+ }
+ ref-align_value = 0;
+ }
+}
What is your plan for this function? Is it envisioned that this
will gain more variations of formatting options over time?
Otherwise it seems misnamed (it is not assign formatting but
merely pad to the right).
I also doubt that the logic is sane. More specifically, what does
that if (v-s[0]) buy you?
Your caller is iterating over the elements in a format string,
e.g. 'A %(align:20)%(foo) B %(bar) C', and its caller is iterating
over a list of refs, e.g. 'maint', 'master' branches. With that
format string, as long as %(foo) does not expand to something that
exceeds 20 display places or so, I'd expect literal 'B' for all refs
to align, but I do not think this code gives me that; what happens
if '%(foo)' happens to be an empty string for 'maint' but is a
string, say 'x', for 'master'?
--
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] userdiff: add support for Fountain documents
Zoë Blade z...@bytenoise.co.uk writes: diff --git a/userdiff.c b/userdiff.c index 2ccbee5..5a600d6 100644 --- a/userdiff.c +++ b/userdiff.c @@ -35,6 +35,8 @@ IPATTERN(fortran, * they would have been matched above as a variable anyway. */ |[-+]?[0-9.]+([AaIiDdEeFfLlTtXx][Ss]?[-+]?[0-9.]*)?(_[a-zA-Z0-9][a-zA-Z0-9_]*)? |//|\\*\\*|::|[/=]=), +PATTERNS(fountain, ^((\\.|(([Ii][Nn][Tt]|[Ee][Ss][Tt]|[Ee][Xx][Tt])?\\.?|[Ii]([Nn][Tt])?\\.?/[Ee]([Xx][Tt])?\\.?) ).+)$, + [^ \t-]+), Wouldn't IPATTERN() be a better choice here? PATTERNS(html, ^[ \t]*([Hh][1-6][ \t].*.*)$, [^= \t]+), PATTERNS(java, -- 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 3/3] doc: give examples for send-email cc-cmd operation
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: +git-send-email invokes the cc-cmd like this: + + $cc-cmd $patchfilename + +Thus the patch itself can be processed to locate appropriate email address +information if required. That's not even a valid command line (cc-cmd cannot be a shell variable name), so why bother writing it that way? Rather We seem to be going round in circles. Currently the --cc-cmd isn't well documented. I was trying to use, essentially, 'cat list.txt' as the command, which should work according to the current doc, which says nothing about how/if the patch file is to be passed to the command. Eric was able to make clear (*) that the code https://github.com/git/git/blob/master/git-send-email.perl#L1602 does essentially execute '$cc-cmd $patchfilename' where $cc-cmd is the value of the --cc-cmd option. This meant that my plain vanilla 'cat list.txt' command errored out. The question are: What should the command look like. (can it be a command, or does it have to be a script??) How should the patch/patchfile be passed - what should the documentation guarantee? At the moment it's the perl code that defines execution of the rather flexible '$cc-cmd $patchfilename' command. (i.e. anything could be in the $cc-cmd string) The program that is specified by `cc-cmd` is invoked by `git send-email` with the name of the patch file as an argument; the program can read from it and customize its output based on what the patch file contains. or something like that, perhaps. + +A simple solution for a basic address list is to create a 'cc-cmd' file +(executable) which provides a list of addressees: There is no problem stated here that requires your solution. In fact, what problem are you solving? As noted above, it's so that I can state a direct command as the --cc-cmd, so that a plain text file listing cc addresses is offered to send-email, without needing to create a script. + #!/bin/sh + echo \EOF + pers...@example.com + pers...@example.com + EOF That is one simple and denegerate use case; if the program does not need any information from the patch file, it surely has an option not to look at it. But it is not an interesting usage. If you want to add a single example to illustrate how cc-cmd (or to-cmd, or anything that goes thru recipients_cmd()), you should have an example that reads the input and then adds a few hardcoded one. #!/bin/sh # always send it to the logger service echo patch...@example.com # tell the bug tracker as necessary if fixes=$(sed -ne 's/^Fixes bug#\([0-9]*\)/\1/p' $1) then echo bugs+$fi...@example.com fi or something silly like that. And this ... +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + ... and the rest of the patch is unnecessary noise to a reader who read that the single argument to the program is the name of the patchfile, I think. You were trying to avoid the same confusion caused by the sketchy documentaiton, and you already solved that I'm not so sure that all other readers would 'know' what went wrong if they tried the same as I, without going through the same QA, hence the desire to inform. problem by telling the reader what the command takes as its input. +--cc-cmd='cat cc-cmd #' This heavily depends on the current implementation that happens to pass the command line string to a shell. Not sure what effective alternative is being suggested - if its a shell script, it'll still hit the shell. -- Philip -- 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 3/3] doc: give examples for send-email cc-cmd operation
On Mon, Jul 20, 2015 at 2:50 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, Jul 20, 2015 at 2:26 PM, Philip Oakley philipoak...@iee.org wrote: Explain how the cc-cmd (and to-cmd) is invoked, along with two simple examples (and a how-not-to example) to help in getting started. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Philip Oakley philipoak...@iee.org --- +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + +and since 'cat' copies the concatenation of its input files to its output, +this adds the patch file to the address list resulting in an error +unable to extract a valid address from:. + +The quick-and-dirty work-around is to use '#' to effectively comment out +the patch file name: + +--cc-cmd='cat cc-cmd #' + +which works, but is very, very ugly. This entire above text about cat $addressfile seems awfully inappropriate for a manual page, especially the bit about the terrible cat $file # hack. If you really want to give an example of how to use --cc-cmd (--to-cmd) with a plain text file holding email addresses, maybe something like this instead: Create an EXAMPLES section. Make the bare-bones, static address list script the first example: #!/bin/sh echo \EOF pers...@example.com pers...@example.com EOF Then add an example showing how to take the fixed address list from a plain text file. Have the user create the following script (let's call it anticat) which cat's all of its input arguments except the final one, which is the patch itself: #!/bin/sh while test $# -gt 1 do cat $1 shift done And, to use: --to-cccmd='anticat myaddresses.txt' -- 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 3/3] doc: give examples for send-email cc-cmd operation
From: Eric Sunshine sunsh...@sunshineco.com On Mon, Jul 20, 2015 at 2:26 PM, Philip Oakley philipoak...@iee.org wrote: Explain how the cc-cmd (and to-cmd) is invoked, along with two simple examples (and a how-not-to example) to help in getting started. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Philip Oakley philipoak...@iee.org --- diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index ddc8a11..9f991cf 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -436,6 +436,42 @@ following commands: Note: the following perl modules are required Net::SMTP::SSL, MIME::Base64 and Authen::SASL +Creating a cc-cmd (and to-cmd) action +~ + +git-send-email invokes the cc-cmd like this: + + $cc-cmd $patchfilename + +Thus the patch itself can be processed to locate appropriate email address +information if required. + +A simple solution for a basic address list is to create a 'cc-cmd' file +(executable) which provides a list of addressees: Rather than calling this a simple solution, you might instead say that this is an example of a bare-bones script which just returns a fixed list of email addresses without attempting to extract any addresses from the patch file itself. + #!/bin/sh + echo \EOF + pers...@example.com + pers...@example.com + EOF I don't know if it deserves mention that the script must be executable (chmod +x) or should we assume that readers are smart enough to understand this implicitly? (It probably should be mentioned.) It's there, but it's after the wrap-around. Maybe s/(executable)/(must be executable: `chmod +x`)/ to be fully pedantic. Other than those minor points, the above looks fine, however... +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + +and since 'cat' copies the concatenation of its input files to its output, +this adds the patch file to the address list resulting in an error +unable to extract a valid address from:. + +The quick-and-dirty work-around is to use '#' to effectively comment out +the patch file name: + +--cc-cmd='cat cc-cmd #' + +which works, but is very, very ugly. This entire above text about cat $addressfile seems awfully inappropriate for a manual page, especially the bit about the terrible cat $file # hack. Given that this invocation is why this all kicked off ... 'cat list.txt', being the most simple of commands and a first cargo-cult try for many, I definitely think it's worthwhile including somehow. Perhaps one needs to be more direct with the right invocation. A simple `--cc-cmd='cat list.txt #'` is a quick-and-dirty way of using an address list, while ignoring the patch content. SEE ALSO linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5) -- 2.4.2.windows.1.5.gd32afb6 -- 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 3/3] doc: give examples for send-email cc-cmd operation
Philip Oakley philipoak...@iee.org writes: +git-send-email invokes the cc-cmd like this: + + $cc-cmd $patchfilename + +Thus the patch itself can be processed to locate appropriate email address +information if required. That's not even a valid command line (cc-cmd cannot be a shell variable name), so why bother writing it that way? Rather The program that is specified by `cc-cmd` is invoked by `git send-email` with the name of the patch file as an argument; the program can read from it and customize its output based on what the patch file contains. or something like that, perhaps. + +A simple solution for a basic address list is to create a 'cc-cmd' file +(executable) which provides a list of addressees: There is no problem stated here that requires your solution. In fact, what problem are you solving? + #!/bin/sh + echo \EOF + pers...@example.com + pers...@example.com + EOF That is one simple and denegerate use case; if the program does not need any information from the patch file, it surely has an option not to look at it. But it is not an interesting usage. If you want to add a single example to illustrate how cc-cmd (or to-cmd, or anything that goes thru recipients_cmd()), you should have an example that reads the input and then adds a few hardcoded one. #!/bin/sh # always send it to the logger service echo patch...@example.com # tell the bug tracker as necessary if fixes=$(sed -ne 's/^Fixes bug#\([0-9]*\)/\1/p' $1) then echo bugs+$fi...@example.com fi or something silly like that. And this ... +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text file +of email addresses), does not work as expected as the invocation becomes: + + $cat cc-cmd $patchfilename + ... and the rest of the patch is unnecessary noise to a reader who read that the single argument to the program is the name of the patchfile, I think. You were trying to avoid the same confusion caused by the sketchy documentaiton, and you already solved that problem by telling the reader what the command takes as its input. +--cc-cmd='cat cc-cmd #' This heavily depends on the current implementation that happens to pass the command line string to a shell. -- 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 3/3] doc: give examples for send-email cc-cmd operation
On Mon, Jul 20, 2015 at 3:14 PM, Eric Sunshine sunsh...@sunshineco.com wrote: If you really want to give an example of how to use --cc-cmd (--to-cmd) with a plain text file holding email addresses, maybe something like this instead: Create an EXAMPLES section. Make the bare-bones, static address list script the first example: #!/bin/sh echo \EOF pers...@example.com pers...@example.com EOF Then add an example showing how to take the fixed address list from a plain text file. Have the user create the following script (let's call it anticat) which cat's all of its input arguments except the final one, which is the patch itself: #!/bin/sh while test $# -gt 1 do cat $1 shift done And, to use: --to-cccmd='anticat myaddresses.txt' I forgot to add that even this is iffy as an example because it depends upon the current implementation passing the cmd string to a shell, which might not always be the case, and might not be reliably implemented that way on some platforms (such as Windows). -- 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 3/3] doc: give examples for send-email cc-cmd operation
On Mon, Jul 20, 2015 at 3:36 PM, Philip Oakley philipoak...@iee.org wrote: From: Eric Sunshine sunsh...@sunshineco.com + echo \EOF + pers...@example.com + pers...@example.com + EOF I don't know if it deserves mention that the script must be executable (chmod +x) or should we assume that readers are smart enough to understand this implicitly? (It probably should be mentioned.) It's there, but it's after the wrap-around. Maybe s/(executable)/(must be executable: `chmod +x`)/ to be fully pedantic. I did see the (executable), but wasn't sure if it meant executable in the 'chmod +x' sense or executable as another name for program. This entire above text about cat $addressfile seems awfully inappropriate for a manual page, especially the bit about the terrible cat $file # hack. Given that this invocation is why this all kicked off ... 'cat list.txt', being the most simple of commands and a first cargo-cult try for many, I definitely think it's worthwhile including somehow. Perhaps one needs to be more direct with the right invocation. A simple `--cc-cmd='cat list.txt #'` is a quick-and-dirty way of using an address list, while ignoring the patch content. It seems utterly sinful to promulgate this sort of hack to a wider audience. If reading addresses from a file is likely to be a common need, then perhaps it ought to have direct support in git-send-email (via a new command-line option or something). Also, this all may be moot once rl/send-email-aliases[1] lands in a release since users will then be able to say: --cc=$(cat recipients.txt) provided that the email addresses in recipients.txt are comma-separated and a POSIX-like shell is being used. Perhaps that deserves an example in the documentation? [1]: b1c8a11 (send-email: allow multiple emails using --cc, --to and --bcc, 2015-06-30) -- 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 1/9] ref-filter: add option to align atoms to the left
What is your plan for this function? Is it envisioned that this will gain more variations of formatting options over time? Otherwise it seems misnamed (it is not assign formatting but merely pad to the right). I wanna include an 'ifexists' atom in the future where an user can specify a string format to be printed only if the preceding atom holds a value. e.g. '%(ifexists:refname is %s)%(refname)' So I see that going in here. I also doubt that the logic is sane. More specifically, what does that if (v-s[0]) buy you? Yeah, that's wrong, like Eric pointed out. Should have been if (v-s[0] == '\0') Your caller is iterating over the elements in a format string, e.g. 'A %(align:20)%(foo) B %(bar) C', and its caller is iterating over a list of refs, e.g. 'maint', 'master' branches. With that format string, as long as %(foo) does not expand to something that exceeds 20 display places or so, I'd expect literal 'B' for all refs to align, but I do not think this code gives me that; what happens if '%(foo)' happens to be an empty string for 'maint' but is a string, say 'x', for 'master'? Oh yeah! That doesn't work, I have a fix in mind I'll reply to this mail with a fix. -- 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 v2b 00/16, 2 updates] Make the msvc-build scripts work again
This updates two patches in the series based on Eric Sunshine's comments. Patch 8b updates the commit message to make clear what was going wrong. Patch 10b improves the perl code. Junio: would a full re-roll be appropriate at a suitable point? Philip Oakley (2): engine.pl: ignore invalidcontinue.obj which is known to MSVC engine.pl: delete the captured stderr file if empty -- 2.4.2.windows.1.5.gd32afb6 -- 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 10b/16] engine.pl: delete the captured stderr file if empty
Keep the build clean of extraneous files if it is indeed clean. Otherwise leave the msvc-build-makedryerrors.txt file both as a flag for any CI system or for manual debugging. Alternatively, with improved syntactic sugar[1]: unlink $ErrsFile if -f -z $ErrsFile; could be used but requires Perl 5.10 or later, which is not available on Msysgit, but is available on the newer Git-for-Windows SDK on Msys2 [2]. Note that the file will contain the new values of the GIT_VERSION and GITGUI_VERSION if they were generated by the make file. They are omitted if the release is tagged and identically defined in their respective GIT_VERSION_GEN file DEF_VER variables. [1]: http://perldoc.perl.org/functions/-X.html [2]: http://git-for-windows.github.io/ Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Philip Oakley philipoak...@iee.org --- Eric's help gmane.comp.version-control.msysgit/21745 --- contrib/buildsystems/engine.pl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl index a6999b6..154575d 100755 --- a/contrib/buildsystems/engine.pl +++ b/contrib/buildsystems/engine.pl @@ -77,6 +77,8 @@ EOM my $ErrsFile = msvc-build-makedryerrors.txt; @makedry = `cd $git_dir make -n MSVC=1 V=1 2$ErrsFile` if !@makedry; +# test for an empty Errors file and remove it +unlink $ErrsFile if -f $ErrsFile -z _; # Parse the make output into usable info parseMakeOutput(); -- 2.3.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
[PATCH v2 8b/16] engine.pl: ignore invalidcontinue.obj which is known to MSVC
Commit 4b623d8 (MSVC: link in invalidcontinue.obj for better
POSIX compatibility, 2014-03-29) introduced invalidcontinue.obj
into the Makefile output, which was not parsed correctly by the
buildsystem. Ignore it, as it is known to Visual Studio and,
there is no matching source file.
Only substitute filenames ending with .o when generating the
source .c filename, otherwise a .cbj file may be expected.
Split the .o and .obj processing; 'make' does not produce .obj
files.
In the future there may be source files that produce .obj files
so keep the two issues (.obj files with without source files)
separate.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
contrib/buildsystems/engine.pl | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 60c7a7d..9db3d43 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -289,7 +289,7 @@ sub handleLibLine
#exit(1);
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
push(@sources, $sourcefile);
push(@cflags, @{$compile_options{${sourcefile}_CFLAGS}});
push(@defines, @{$compile_options{${sourcefile}_DEFINES}});
@@ -333,8 +333,12 @@ sub handleLinkLine
} elsif ($part =~ /\.(a|lib)$/) {
$part =~ s/\.a$/.lib/;
push(@libs, $part);
-} elsif ($part =~ /\.(o|obj)$/) {
+} elsif ($part eq 'invalidcontinue.obj') {
+# ignore - known to MSVC
+} elsif ($part =~ /\.o$/) {
push(@objfiles, $part);
+} elsif ($part =~ /\.obj$/) {
+# do nothing, 'make' should not be producing .obj, only .o files
} else {
die Unhandled link option @ line $lineno: $part;
}
@@ -343,7 +347,7 @@ sub handleLinkLine
#exit(1);
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
push(@sources, $sourcefile);
push(@cflags, @{$compile_options{${sourcefile}_CFLAGS}});
push(@defines, @{$compile_options{${sourcefile}_DEFINES}});
--
2.3.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 3/3] doc: give examples for send-email cc-cmd operation
Junio C Hamano gits...@pobox.com writes: I was trying to use, essentially, 'cat list.txt' as the command,... One thing that needs to be made clear is that I do not think we want to encourage `cat list.txt #` abuse in the first place. It is an unacceptable hack for us to encourage in the longer term. It may happen to work with the current implementation, but it does so merely by depending on the implementation too much. If it is so common to want to spray all your patches to exactly the same list of recipients that is unconditionally determined, having multiple sendemail.cc configuration variables, which are cumulative, is already one way to do so, and you do not have to type such a long option --cc-cmd='cat $filename' every time. And if you do not want configuration for some reason, and having a list of addresses in a flat file is so common, we could have a new option --cc-list=$filename to support that use case. I however doubt anything that starts with First you make a list of addresses in a flat file, and then do this is a good solution. I would think that it would probably be the best way to address I often want to cc these recipients, but not always is to keep a list of aliases, each entry of which expands to the recipients, and say --cc=group from the command line to have it expanded to the set of recipients. -- 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 3/3] introduce format date-mode
On Tue, Jun 30, 2015 at 9:26 AM, Jeff King p...@peff.net wrote:
On Mon, Jun 29, 2015 at 06:22:47PM -0400, Eric Sunshine wrote:
Clients of strbuf rightly expect the buffer to grow as needed in
order to complete the requested operation. It is, therefore, both
weird and expectation-breaking for strbuf_addftime() to lack this
behavior. Worse, it doesn't even signal when the format has failed
due to insufficient buffer space.
How about taking this approach (or something similar), instead, which
grows the strbuf as needed?
Here's a patch, on top of jk/date-mode-format (I think it would also be
fine to just squash into the tip commit; the explanation in the commit
message is sufficiently mirrored in the code comment).
While cleaning up old local branches, I noticed that, although the
jk/date-mode-format topic[1] made it into 'next' (and will be merged
to 'master' according to What's cooking[2]), the below follow-on
patch[3] which improves strbuf_addftime() never got picked up. Was
this omission intentional? Based upon the discussion[4], I was under
the impression that the patch was considered reasonably acceptable
(and did not worsen problems with bogus format strings -- which are
bogus anyway).
[1]: http://thread.gmane.org/gmane.comp.version-control.git/272658/focus=272695
[2]: http://news.gmane.org/gmane.comp.version-control.git
[3]: http://article.gmane.org/gmane.comp.version-control.git/273061
[4]: http://thread.gmane.org/gmane.comp.version-control.git/272658/focus=273026
-- 8 --
Subject: [PATCH] strbuf: make strbuf_addftime more robust
The return value of strftime is poorly designed; when it
returns 0, the caller cannot tell if the buffer was not
large enough, or if the output was actually 0 bytes. In the
original implementation of strbuf_addftime, we simply punted
and guessed that our 128-byte hint would be large enough.
We can do better, though, if we're willing to treat strftime
like less of a black box. We can munge the incoming format
to make sure that it never produces 0-length output, and
then fix the resulting output. That lets us reliably grow
the buffer based on strftime's return value.
Clever-idea-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Jeff King p...@peff.net
---
strbuf.c| 38 +-
t/t6300-for-each-ref.sh | 10 ++
2 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index a7ba028..e5e7370 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -712,29 +712,33 @@ char *xstrfmt(const char *fmt, ...)
void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm)
{
+ size_t hint = 128;
size_t len;
- /*
-* strftime reports 0 if it could not fit the result in the buffer.
-* Unfortunately, it also reports 0 if the requested time string
-* takes 0 bytes. So if we were to probe and grow, we have to choose
-* some arbitrary cap beyond which we guess that the format probably
-* just results in a 0-length output. Since we have to choose some
-* reasonable cap anyway, and since it is not that big, we may
-* as well just grow to their in the first place.
-*/
- strbuf_grow(sb, 128);
+ if (!*fmt)
+ return;
+
+ strbuf_grow(sb, hint);
len = strftime(sb-buf + sb-len, sb-alloc - sb-len, fmt, tm);
if (!len) {
/*
-* Either we failed, or the format actually produces a
0-length
-* output. There's not much we can do, so we leave it blank.
-* However, the output array is left in an undefined state, so
-* we must re-assert our NUL terminator.
+* strftime reports 0 if it could not fit the result in the
buffer.
+* Unfortunately, it also reports 0 if the requested time
string
+* takes 0 bytes. So our strategy is to munge the format so
that the
+* output contains at least one character, and then drop the
extra
+* character before returning.
*/
- sb-buf[sb-len] = '\0';
- } else {
- sb-len += len;
+ struct strbuf munged_fmt = STRBUF_INIT;
+ strbuf_addf(munged_fmt, %s , fmt);
+ while (!len) {
+ hint *= 2;
+ strbuf_grow(sb, hint);
+ len = strftime(sb-buf + sb-len, sb-alloc - sb-len,
+ munged_fmt.buf, tm);
+ }
+ strbuf_release(munged_fmt);
+ len--; /* drop munged space */
}
+ strbuf_setlen(sb, sb-len + len);
}
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index c7f368c..7c9bec7 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -235,6 +235,16 @@
Re: What's cooking in git.git (Jul 2015, #05; Mon, 20)
* dt/refs-backend-preamble (2015-07-13) 7 commits - git-stash: use update-ref --create-reflog instead of creating files - update-ref and tag: add --create-reflog arg - refs: add REF_FORCE_CREATE_REFLOG flag - git-reflog: add exists command - refs: new public ref function: safe_create_reflog - refs: Break out check for reflog autocreation - refs.c: add err arguments to reflog functions In preparation for allowing different backends to store the refs in a way different from the traditional one ref per file in $GIT_DIR or in a $GIT_DIR/packed-refs file filesystem storage, reduce direct filesystem access to ref-like things like CHERRY_PICK_HEAD from scripts and programs. Still under discussion. Will hold. What's left to discuss on this one? I think the latest version addresses all concerns, but I'm happy to do another reroll or discuss further if necessary. -- 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 3/3] introduce format date-mode
On Mon, Jul 20, 2015 at 08:41:08PM -0400, Eric Sunshine wrote: Here's a patch, on top of jk/date-mode-format (I think it would also be fine to just squash into the tip commit; the explanation in the commit message is sufficiently mirrored in the code comment). While cleaning up old local branches, I noticed that, although the jk/date-mode-format topic[1] made it into 'next' (and will be merged to 'master' according to What's cooking[2]), the below follow-on patch[3] which improves strbuf_addftime() never got picked up. Was this omission intentional? Based upon the discussion[4], I was under the impression that the patch was considered reasonably acceptable (and did not worsen problems with bogus format strings -- which are bogus anyway). Thanks for noticing. I do think the patch you quoted (to loop and grow the strbuf) is a good change. The original code would easily bite somebody with a really large date format, whereas this should work sanely everywhere, short of malformed inputs. And even then, I'd expect reasonable behavior on most systems. The obvious thing to worry about is a system where feeding a malformed % causes strftime to return 0, no matter what, and we reallocated and loop forever. But: 1. I don't even know if such a system exists. 2. We probably would blow up on malloc() eventually, so it wouldn't even be a real infinite loop. So I think the worst case is probably that we get a report later on from somebody on an arcane system that says I fed crap to --date=format, and my git died with an out-of-memory error, and then we figure out exactly _how_ their system is weird and deal with it then. -Peff -- 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 3/3] doc: give examples for send-email cc-cmd operation
Philip Oakley philipoak...@iee.org writes: We seem to be going round in circles. I do not think so. Currently the --cc-cmd isn't well documented. Yes, I agree. I was trying to use, essentially, 'cat list.txt' as the command, which should work according to the current doc, which says nothing about how/if the patch file is to be passed to the command. I've already agreed in the message you are responding to that the current documentation is sketchy and invite mistakes like yours. And that is why this series exists, isn't it? The question are: What should the command look like. (can it be a command, or does it have to be a script??) How should the patch/patchfile be passed - what should the documentation guarantee? Yes, I think I already answered that, no? The program that is specified by `cc-cmd` is invoked by `git send-email` with the name of the patch file as an argument; the program can read from it and customize its output based on what the patch file contains. or something like that, perhaps. We do not care if that program is scripted, or written in java and compiled. It will find the patch in argv[1]. It is up to the program if it uses that input to customize its output, or it just outputs a hardcoded list of addresses. That is the only guarantee we would want to give. -- 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 v2b 00/16, 2 updates] Make the msvc-build scripts work again
Philip Oakley philipoak...@iee.org writes: This updates two patches in the series based on Eric Sunshine's comments. Patch 8b updates the commit message to make clear what was going wrong. Patch 10b improves the perl code. Is v2b like saying v3 or something else? Does 8b replaces 8 or updates it (i.e. comes between 8 and 9)? Junio: would a full re-roll be appropriate at a suitable point? Probably, but I'd like to see people try it out and give positive feedback first. This part of the tree I can give no input or pre- pushout testing at all. Who are the people involved in this part of the system in the past? Does shortlog -n --no-merges contrib/buildsystems compat/vcbuild tell us anything? Philip Oakley (2): engine.pl: ignore invalidcontinue.obj which is known to MSVC engine.pl: delete the captured stderr file if empty -- 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
What's cooking in git.git (Jul 2015, #05; Mon, 20)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* zb/userdiff-fountain (2015-07-17) 1 commit
- userdiff: add support for Fountain documents
New userdiff pattern definition for fountain screenwriting markup
format.
Needs another reroll? ($gmane/274354)
* as/sparse-checkout-removal (2015-07-17) 1 commit
- unpack-trees: don't update files with CE_WT_REMOVE set
Duy's replacement needs to be applied ($gmane/274158).
* cb/uname-in-untracked (2015-07-17) 1 commit
- untracked: fix detection of uname(2) failure
An experimental untracked cache feature used to use uname(2) in a
slightly unportable way.
Will merge to 'next'.
* jc/rerere-multi (2015-07-20) 5 commits
- t4200: rerere a merge with two identical conflicts
- rerere: delay the recording of preimage for the first time
- rerere: handle leftover rr-cache/$ID directory and postimage files
- rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
- rerere: split conflict ID further
(this branch uses jc/rerere.)
This is a contination of jc/rerere topic.
* bw/portability-solaris (2015-07-20) 3 commits
- tests: fix sed usage in tests to work around broken xpg4/sed on Solaris
- tests: fix sed usage in tests to work around broken xpg4/sed on Solaris
- tests: modify tr expressions so that xpg4/tr handles it on Solaris
Needs another reroll? ($gmane/274296)
* es/worktree-add (2015-07-20) 5 commits
(merged to 'next' on 2015-07-20 at 76e840b)
+ config: rename gc.pruneWorktreesExpire to gc.worktreePruneExpire
+ Documentation/git-worktree: wordsmith worktree-related manpages
+ Documentation/config: fix stale git prune --worktree reference
+ Documentation/git-worktree: fix incorrect reference to file locked
+ Documentation/git-worktree: consistently use term linked working tree
(this branch is used by es/worktree-add-cleanup.)
Will merge to 'master'.
* sg/bash-prompt-untracked-optim (2015-07-20) 2 commits
- bash prompt: faster untracked status indicator with untracked directories
- bash prompt: test untracked files status indicator with untracked dirs
Will merge to 'next'.
--
[Graduated to master]
* jc/diff-ws-error-highlight (2015-07-12) 1 commit
(merged to 'next' on 2015-07-12 at 15b60ce)
+ diff: parse ws-error-highlight option more strictly
A hotfix to a new feature in 2.5.0-rc.
* jk/still-interesting (2015-06-29) 1 commit
(merged to 'next' on 2015-07-09 at e19fc0e)
+ revision.c: remove unneeded check for NULL
Code clean-up.
Will merge to 'master'.
--
[Stalled]
* sg/config-name-only (2015-05-28) 3 commits
- completion: use new 'git config' options to reliably list variable names
- SQUASH
- config: add options to list only variable names
git config --list output was hard to parse when values consist of
multiple lines. Introduce a way to show only the keys.
Adding a single --name-only option may be a better way to go than
adding two new options.
Expecting a reroll.
* kk/log-merges-config (2015-04-21) 5 commits
- bash-completion: add support for git-log --merges= and log.merges
- t4202-log: add tests for --merges=
- Documentation: add git-log --merges= option and log.merges config. var
- log: honor log.merges= option
- revision: add --merges={show|only|hide} option
git log (but not other commands in the log family) learned to
pay attention to the log.merges configuration variable that can be
set to show (the normal behaviour), only (hide non-merge
commits), or hide (hide merge commits). --merges=(show|only|hide)
can be used to override the setting from the command line.
The documentation may need to be updated once more ($gmane/267250).
Waiting for a reroll.
* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
- t/lib-git-svn: check same httpd module dirs as lib-httpd
- t/lib-httpd: load mod_unixd
This is the first two commits in a three-patch series $gmane/266962
Will be rerolled.
with updated log message ($gmane/268061).
* mh/numparse (2015-03-19) 14 commits
- diff_opt_parse(): use convert_i() when handling --abbrev=num
- diff_opt_parse(): use convert_i() when handling -lnum
- opt_arg(): simplify pointer handling
- opt_arg(): report errors parsing option values
- opt_arg(): use convert_i() in implementation
- opt_arg(): val is always non-NULL
- builtin_diff(): detect errors when parsing --unified argument
- handle_revision_opt(): use convert_ui() when handling --abbrev=
- strtoul_ui(), strtol_i(): remove functions
- handle_revision_opt(): use convert_i() when handling -digit
- handle_revision_opt(): use
[GIT PULL] l10n updates for 2.5.0 round 2
Hi Junio, The following changes since commit 961abca02c532626df631c851688ec433095d93d: Merge tag 'l10n-2.5.0-rnd1' of git://github.com/git-l10n/git-po (2015-07-13 15:37:24 -0700) are available in the git repository at: git://github.com/git-l10n/git-po tags/l10n-2.5.0-rnd2 for you to fetch changes up to cdab3cacf643b290e423335e8e04b62fbd24b08c: l10n: ca.po: update translation (2015-07-20 11:54:40 -0600) l10n-2.5.0-rnd2 Alex Henrie (1): l10n: ca.po: update translation Alexander Shopov (1): l10n: Updated Bulgarian translation of git (2359t,0f,0u) Dimitriy Ryazantcev (1): l10n: ru.po: update Russian translation Jean-Noel Avila (1): l10n: fr v2.5.0 round 2 (2359t) Jiang Xin (5): l10n: git.pot: v2.5.0 round 2 (9 new, 5 removed) Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru Merge branch 'fr_v2.5.0-round2' of git://github.com/jnavila/git l10n: zh_CN: for git v2.5.0 l10n round 2 Merge branch 'master' of https://github.com/ralfth/git-po-de Peter Krefting (1): l10n: sv.po: Update Swedish translation (2359t0f0u) Ralf Thielow (1): l10n: de.po: translate 9 new messages Trần Ngọc Quân (1): l10n: Updated Vietnamese translation (2359t) po/bg.po| 398 +- po/ca.po| 391 - po/de.po| 440 ++- po/fr.po| 451 ++- po/git.pot | 381 - po/ru.po| 2531 +-- po/sv.po| 402 +- po/vi.po| 465 ++- po/zh_CN.po | 400 +- 9 files changed, 3179 insertions(+), 2680 deletions(-) -- 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
$0.92/pc monopod selfie stick,on promotion
Dear Good day $0.92/pc monopod selfie stick with cable take pole,only from us,the arcpeaks factory 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: What's cooking in git.git (Jul 2015, #05; Mon, 20)
David Turner dtur...@twopensource.com writes: * dt/refs-backend-preamble (2015-07-13) 7 commits - git-stash: use update-ref --create-reflog instead of creating files - update-ref and tag: add --create-reflog arg - refs: add REF_FORCE_CREATE_REFLOG flag - git-reflog: add exists command - refs: new public ref function: safe_create_reflog - refs: Break out check for reflog autocreation - refs.c: add err arguments to reflog functions ... Still under discussion. Will hold. What's left to discuss on this one? I think the latest version addresses all concerns, but I'm happy to do another reroll or discuss further if necessary. I think I found the series more or less ready when I saw v7, but there was a good discussion between Michael Haggerty and you on that round after I thought so, and then you posted the reroll (v8) which is what is queued above. As I was not closely following the earlier exchange, I wanted to hear from Michael if everything is now good with v8, which hasn't happened as far as I recall. Also in $gmane/273828 [*1*] you hinted (but without showing a firm commitment) that there might be a reroll coming, which was another reason why I wasn't in a hurry to merge v8 iteration down to 'next'. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/273786/focus=273828 -- 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
