gitweb on Godaddy
HI Can someone share procedure to setup gitweb on a Godaddy hosting server ? Any pointers to tutorials would be helpful Cheers -- 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: gitweb on Godaddy
On Thu, Jul 04, 2013 at 11:56:40AM +0530, RR wrote: HI Can someone share procedure to setup gitweb on a Godaddy hosting server ? Any pointers to tutorials would be helpful Hi, I suggest that you contact godaddy and check with them what options you have. Gitweb is a cgi program and you need support to run cgi-applicatios from godaddy. You would also have to host your git repository on the same server (or at least you should). If that's not a possibility you might need to use a static html creator like http://hssl.cs.jhu.edu/~neal/git2html/ . -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: prevent push -f from pushing all branches at once
Dany nes...@gmail.com writes: Again, I think the case where one intends to force push many branches is certainly not as common as the case where one intends to force push one branch, so why does git's default behavior leave the user in the position of fscking himself over pretty badly? I don't think the case of force push is very different from the non-force push. If you're surprised that git push -f pushes everything, most likely you didn't want a plain git push to push everything either. There are already several measures against this. The first is mentionned in Jonathan's message: Git 2.0 will only push one branch by default (-f or not). You can already get this behavior by setting push.default (if your Git version is too old, set it to current for example, read git config --help). Another measure is a better documentation. We've just merged the change below. In short: don't run git push -f, but run e.g. git push origin +master. commit 70495b556f5685afe0e41988e42d48b2331d77a0 Author: Matthieu Moy matthieu@imag.fr Date: Mon Jun 17 19:52:41 2013 +0200 Documentation/git-push.txt: explain better cases where --force is dangerous The behavior of git push --force is rather clear when it updates only one remote ref, but running it when pushing several branches can really be dangerous. Warn the users a bit more and give them the alternative to push only one branch. Signed-off-by: Matthieu Moy matthieu@imag.fr Signed-off-by: Junio C Hamano gits...@pobox.com diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 8b637d3..28a17c3 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -124,6 +124,15 @@ no `push.default` configuration variable is set. not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care. + Note that `--force` applies to all the refs that are pushed, + hence using it with `push.default` set to `matching` or with + multiple push destinations configured with `remote.*.push` + may overwrite refs other than the current branch (including + local refs that are strictly behind their remote counterpart). + To force a push to only one branch, use a `+` in front of the + refspec to push (e.g `git push origin +master` to force a push + to the `master` branch). See the `refspec...` section above + for details. --repo=repository:: This option is only relevant if no repository argument is -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request:
Dany nes...@gmail.com writes: lol, confusion abound. this message was intended to be in response to Re: Feature request: prevent push -f from pushing all branches at once While we're there: please, don't top-post here. Quote the part of the message you're replying to, and reply below. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Review of git multimail
Jed Brown j...@59a2.org writes: Note that RHEL5 has only python2.4 and will be supported through March, 2017. Since it is not feasible to have code that works in both python3 and any versions prior to python2.6, any chosen dialect will be broken by default on some major distributions that still have full vendor support. At worse, if git-multimail is ported to Python 3, people using old distros will still be able to use today's version which works in Python 2 and already does a good job. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
Jakub Narębski jna...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:59 PM, Jonathan Nieder jrnie...@gmail.com wrote: Tony Finch wrote: +@extra_breadcrumbs:: + Additional links to be added to the start of the breadcrumb trail, + that are logically above the gitweb projects list. For example, + links to the organization and department which host the gitweb + server. Each element of the list is a reference to an array, + in which element 0 is the link text and element 1 is the + target URL. Is arbitrary HTML permitted in the link text? I had the same question when I was wondering about abusing $home_link_str to do this without a patch :-) I think it makes sense to permit it for consistency with $home_link_str, but it might be worth mentioning in the manpage so the administrator knows not to set it to something user-controlled --- e.g.: I left this detail out of the man page for consistency with the documentation for $home_link_str. Nb. it would be nice to have relation of @extra_breadcrumbs with $home_link_str explained. I will make that clearer. Thanks for reviewing the patch. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: [PATCH] Change remote tracking to remote-tracking
On Wed, Jul 03, 2013 at 11:38:51AM -0700, Jonathan Nieder wrote: Michael Schubert wrote: --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -180,7 +180,7 @@ subsequent 'sync' operations. Import changes into given branch. If the branch starts with 'refs/', it will be used as is. Otherwise if it does not start with 'p4/', that prefix is added. The branch is assumed to - name a remote tracking, but this can be modified using + name a remote-tracking, but this can be modified using '--import-local', or by giving a full ref name. The default branch is 'master'. This is confusing both before and after the patch. What is a remote tracking? Perhaps: --branch ref:: Import changes into ref instead of refs/remotes/p4/master. If ref starts with refs/, it is used as is. Otherwise, if it does not start with p4/, that prefix is added. + By default a ref not starting with refs/ is treated as the name of a remote-tracking branch (under refs/remotes/). This behavior can be modified using the --import-local option. + The default ref is master. Thanks. -- 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
git gui replaces amend message when prepare-commit-msg hook is used
Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. - Orgad -- 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] gitweb: allow extra breadcrumbs to prefix the trail
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch d...@dotat.at
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
This update includes the documentation improvements suggested by
Jonathan Nieder and Jakub NarÄbski.
Documentation/gitweb.conf.txt | 22 --
gitweb/gitweb.perl| 6 ++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index ea0526e..305db63 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -336,8 +336,26 @@ $home_link_str::
used as the first component of gitweb's breadcrumb trail:
`home link / project / action`. Can be set at build time using
the `GITWEB_HOME_LINK_STR` variable. By default it is set to
projects,
- as this link leads to the list of projects. Other popular choice it to
- set it to the name of site.
+ as this link leads to the list of projects. Another popular choice is
to
+ set it to the name of site. Note that it is treated as raw HTML so it
+ should not be set from untrusted sources.
+
+@extra_breadcrumbs::
+ Additional links to be added to the start of the breadcrumb trail before
+ the home link, to pages that are logically above the gitweb projects
+ list, such as the organization and department which host the gitweb
+ server. Each element of the list is a reference to an array, in which
+ element 0 is the link text (equivalent to `$home_link_str`) and element
+ 1 is the target URL (equivalent to `$home_link`).
++
+For example, the following setting produces a breadcrumb trail like
+home / dev / projects / ... where projects is the home link.
+
+our @extra_breadcrumbs = (
+ [ 'home' = 'https://www.example.org/' ],
+ [ 'dev' = 'https://dev.example.org/' ],
+);
+
$logo_url::
$logo_label::
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d69ada..436f17a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,9 @@ our $project_maxdepth = ++GITWEB_PROJECT_MAXDEPTH++;
# string of the home link on top of all pages
our $home_link_str = ++GITWEB_HOME_LINK_STR++;
+# extra breadcrumbs preceding the home link
+our @extra_breadcrumbs = ();
+
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = ++GITWEB_SITENAME++
@@ -3982,6 +3985,9 @@ sub print_nav_breadcrumbs_path {
sub print_nav_breadcrumbs {
my %opts = @_;
+ for my $crumb (@extra_breadcrumbs) {
+ print $cgi-a({-href = esc_url($crumb-[1])}, $crumb-[0]) .
/ ;
+ }
print $cgi-a({-href = esc_url($home_link)}, $home_link_str) . / ;
if (defined $project) {
my @dirname = split '/', $project;
--
1.8.3.1.605.g85318f5
--
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 gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I don't get it. The message from the hook is replaced with the message from the hook? What I don't get is how you can amend to a commit that doesn't yet exists. How is that possible? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 4, 2013 at 1:01 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I don't get it. The message from the hook is replaced with the message from the hook? What I don't get is how you can amend to a commit that doesn't yet exists. How is that possible? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com Did I say anything about a commit that doesn't exist? I have a commit which I want to amend. If I click the Amend button before the hook is done, this commit's message is replaced (in the editor, not the actual commit) with the hook's result. The message that should appear in the editor should come from the amended commit, not from the hook. - Orgad -- 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 gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 01:03:31PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:01 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I don't get it. The message from the hook is replaced with the message from the hook? What I don't get is how you can amend to a commit that doesn't yet exists. How is that possible? Did I say anything about a commit that doesn't exist? I have a commit which I want to amend. If I click the Amend button before the hook is done, this commit's message is replaced (in the editor, not the actual commit) with the hook's result. When you click on amend the prepare-commit-msg hook is runned. But you say that you click amend before the hook is done. Which hook are you talking about in this case? Are you clicking twice on amend? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. -- 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 gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. Let me try to explain. When git gui is executed, it calls the prepare-commit-msg script with .git/PREPARE_COMMIT_MSG as an argument. When amend is selected, the hook is *not* called at all (what would it prepare? The message is already committed) Use the following hook to reproduce: --- snip --- #!/bin/sh sleep 5 echo $@ /tmp/hook.log echo 'Hello hook' $1 --- snip --- Now run git gui (or press F5 if it is already running), and before 5 seconds pass, click Amend last commit. You'll see the commit's message, but when the 5 seconds pass it is replaced with Hello hook. That's the bug. - Orgad -- 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 gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. Let me try to explain. When git gui is executed, it calls the prepare-commit-msg script with .git/PREPARE_COMMIT_MSG as an argument. When amend is selected, the hook is *not* called at all (what would it prepare? The message is already committed) Use the following hook to reproduce: --- snip --- #!/bin/sh sleep 5 echo $@ /tmp/hook.log echo 'Hello hook' $1 --- snip --- Now run git gui (or press F5 if it is already running), and before 5 seconds pass, click Amend last commit. You'll see the commit's message, but when the 5 seconds pass it is replaced with Hello hook. That's the bug. Yeah I got what you mean, it looks like it's an update problem of the test-box in git-gui. You can also get that textbox to be completely empty if you click back and foward between new commit and amend. The hook is not always runned. I can confirm this bug. I don't think it related to pure git but to git-gui. I imagine that new commit exectures the prepare-commit-msg hook and replaces the textbox content with it. Something that should be correct, but the you've already told the textbox to have an other value (the value of the commit to amend). There should be a check before writing to the textbox if new commit still is set. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. Let me try to explain. When git gui is executed, it calls the prepare-commit-msg script with .git/PREPARE_COMMIT_MSG as an argument. When amend is selected, the hook is *not* called at all (what would it prepare? The message is already committed) Use the following hook to reproduce: --- snip --- #!/bin/sh sleep 5 echo $@ /tmp/hook.log echo 'Hello hook' $1 --- snip --- Now run git gui (or press F5 if it is already running), and before 5 seconds pass, click Amend last commit. You'll see the commit's message, but when the 5 seconds pass it is replaced with Hello hook. That's the bug. Yes, and that's a bug in the hook. The hook is called with a second argument commit but it is ignoring this and blindly overwriting the message. githooks(5) says: prepare-commit-msg This hook is invoked by git commit right after preparing the default log message, and before the editor is started. It takes one to three parameters. The first is the name of the file that contains the commit log message. The second is the source of the commit message, and can be: message (if a -m or -F option was given); template (if a -t option was given or the configuration option commit.template is set); merge (if the commit is a merge or a .git/MERGE_MSG file exists); squash (if a .git/SQUASH_MSG file exists); or commit, followed by a commit SHA1 (if a -c, -C or --amend option was given). If the exit status is non-zero, git commit will abort. The purpose of the hook is to edit the message file in place, and it is not suppressed by the --no-verify option. A non-zero exit means a failure of the hook and aborts the commit. It should not be used as replacement for pre-commit hook. Your problem is that your hook script is not checking $2 so it is overwriting the message even when you do not want to do so. -- 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 gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 4, 2013 at 2:19 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. Let me try to explain. When git gui is executed, it calls the prepare-commit-msg script with .git/PREPARE_COMMIT_MSG as an argument. When amend is selected, the hook is *not* called at all (what would it prepare? The message is already committed) Use the following hook to reproduce: --- snip --- #!/bin/sh sleep 5 echo $@ /tmp/hook.log echo 'Hello hook' $1 --- snip --- Now run git gui (or press F5 if it is already running), and before 5 seconds pass, click Amend last commit. You'll see the commit's message, but when the 5 seconds pass it is replaced with Hello hook. That's the bug. Yes, and that's a bug in the hook. The hook is called with a second argument commit but it is ignoring this and blindly overwriting the message. githooks(5) says: prepare-commit-msg This hook is invoked by git commit right after preparing the default log message, and before the editor is started. It takes one to three parameters. The first is the name of the file that contains the commit log message. The second is the source of the commit message, and can be: message (if a -m or -F option was given); template (if a -t option was given or the configuration option commit.template is set); merge (if the commit is a merge or a .git/MERGE_MSG file exists); squash (if a .git/SQUASH_MSG file exists); or commit, followed by a commit SHA1 (if a -c, -C or --amend option was given). If the exit status is non-zero, git commit will abort. The purpose of the hook is to edit the message file in place, and it is not suppressed by the --no-verify option. A non-zero exit means a failure of the hook and aborts the commit. It should not be used as replacement for pre-commit hook. Your problem is that your hook script is not checking $2 so it is overwriting the message even when you do not want to do so. No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the hook I provided... - Orgad -- 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 gui replaces amend message when prepare-commit-msg hook is used
Your problem is that your hook script is not checking $2 so it is overwriting the message even when you do not want to do so. No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the hook I provided... So what you mean is that the hook is not executed with the correct parameters? Could you please provide the output of the /tmp/hook.log file (I can't reproduce right now) ? -- 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 v9 0/5] Incremental updates against 'next' branch
This patch series is an incremental updates on top of (7c375214 t4205: replace .\+ with ..* in sed commands, 2013-07-01) as far as v7 patches were applied to the 'next' branch but there were more improvements made in v8. Alexey Shumkin (5): t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1 t4205: revert back single quotes t4205, t6006, t7102: make functions more readable t6006: add two more tests for the case i18n.commitEncoding is not set t4205: avoid using `sed` t/t4041-diff-submodule-option.sh | 4 +- t/t4205-log-pretty-formats.sh| 145 +++ t/t6006-rev-list-format.sh | 69 ++- t/t7102-reset.sh | 22 +++--- 4 files changed, 121 insertions(+), 119 deletions(-) -- 1.8.3.1.15.g5c23c1e -- 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 v9 3/5] t4205, t6006, t7102: make functions more readable
Function 'test_format' is become hard to read after its change in
de6029a2d7734a93a9e27b9c4471862a47dd8123. So, make it more elegant.
Also, change 'commit_msg' function to make it more pretty.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
Improved-by: Johannes Sixt j.s...@viscovery.net
---
t/t4205-log-pretty-formats.sh | 5 +++--
t/t6006-rev-list-format.sh| 23 +--
t/t7102-reset.sh | 12 +++-
3 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index ef9770a..bb87f02 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -7,8 +7,9 @@
test_description='Test pretty formats'
. ./test-lib.sh
-commit_msg () {
- # String initial. initial partly in German (translated with Google
Translate),
+commit_msg() {
+ # String initial. initial partly in German
+ # (translated with Google Translate),
# encoded in UTF-8, used as a commit log message below.
msg=$(printf initial. anf\303\244nglich)
if test -n $1
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 4751d22..e069263 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -35,26 +35,13 @@ test_expect_success 'setup' '
git config --unset i18n.commitEncoding
'
-# usage: test_format [failure] name format_string expected_output
+# usage: test_format name format_string [failure] expected_output
test_format () {
- must_fail=0
- # if parameters count is more than 2 then test must fail
- if test $# -gt 2
- then
- must_fail=1
- # remove first parameter which is flag for test failure
- shift
- fi
cat expect.$1
- name=format $1
- command=git rev-list --pretty=format:'$2' master output.$1
- test_cmp expect.$1 output.$1
- if test $must_fail -eq 1
- then
- test_expect_failure $name $command
- else
- test_expect_success $name $command
- fi
+ test_expect_${3:-success} format $1
+ git rev-list --pretty=format:'$2' master output.$1
+ test_cmp expect.$1 output.$1
+
}
# Feed to --format to provide predictable colored sequences.
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 2ef96e9..73a1bdb 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -9,15 +9,17 @@ Documented tests for git reset'
. ./test-lib.sh
-commit_msg () {
- # String modify 2nd file (changed) partly in German(translated with
Google Translate),
+commit_msg() {
+ # String modify 2nd file (changed) partly in German
+ # (translated with Google Translate),
# encoded in UTF-8, used as a commit log message below.
- msg=$(printf modify 2nd file (ge\303\244ndert))
+ printf modify 2nd file (ge\303\244ndert) |
if test -n $1
then
- msg=$(echo $msg | iconv -f utf-8 -t $1)
+ iconv -f utf-8 -t $1
+ else
+ cat
fi
- echo $msg
}
test_expect_success 'creating initial files and commits' '
--
1.8.3.1.15.g5c23c1e
--
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 v9 1/5] t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1
This is actually a fixup of de6029a2d7734a93a9e27b9c4471862a47dd8123,
which was applied before final patch series was sent.
Also, see 3994e8a98dc7bbf67e61d23c8125f44383499a1f for the explanation
of such a replacement.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
Reviewed-by: Johannes Sixt j.s...@viscovery.net
---
t/t4041-diff-submodule-option.sh | 4 ++--
t/t4205-log-pretty-formats.sh| 8
t/t6006-rev-list-format.sh | 14 +++---
t/t7102-reset.sh | 10 +-
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 0a4f496..1751c83 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -23,8 +23,8 @@ add_file () {
echo $name $name
git add $name
test_tick
- msg_added_iso88591=$(echo Add $name ($added $name) |
iconv -f utf-8 -t iso-8859-1)
- git -c 'i18n.commitEncoding=iso-8859-1' commit -m
$msg_added_iso88591
+ msg_added_iso88591=$(echo Add $name ($added $name) |
iconv -f utf-8 -t iso8859-1)
+ git -c 'i18n.commitEncoding=iso8859-1' commit -m
$msg_added_iso88591
done /dev/null
git rev-parse --short --verify HEAD
)
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 3cfb744..c283842 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -32,8 +32,8 @@ test_expect_success 'set up basic repos' '
bar
git add foo
test_tick
- git config i18n.commitEncoding iso-8859-1
- git commit -m $(commit_msg iso-8859-1)
+ git config i18n.commitEncoding iso8859-1
+ git commit -m $(commit_msg iso8859-1)
git add bar
test_tick
git commit -m add bar
@@ -61,8 +61,8 @@ test_expect_success 'alias user-defined format' '
test_cmp expected actual
'
-test_expect_success 'alias user-defined tformat with %s (iso-8859-1 encoding)'
'
- git config i18n.logOutputEncoding iso-8859-1
+test_expect_success 'alias user-defined tformat with %s (iso8859-1 encoding)' '
+ git config i18n.logOutputEncoding iso8859-1
git log --oneline expected-s
git log --pretty=tformat:%h %s actual-s
git config --unset i18n.logOutputEncoding
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 380c85b..4751d22 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -12,15 +12,15 @@ test_tick
# String added in German (translated with Google Translate), encoded in
UTF-8,
# used as a commit log message below.
added=$(printf added (hinzugef\303\274gt) foo)
-added_iso88591=$(echo $added | iconv -f utf-8 -t iso-8859-1)
+added_iso88591=$(echo $added | iconv -f utf-8 -t iso8859-1)
# same but changed
changed=$(printf changed (ge\303\244ndert) foo)
-changed_iso88591=$(echo $changed | iconv -f utf-8 -t iso-8859-1)
+changed_iso88591=$(echo $changed | iconv -f utf-8 -t iso8859-1)
test_expect_success 'setup' '
: foo
git add foo
- git config i18n.commitEncoding iso-8859-1
+ git config i18n.commitEncoding iso8859-1
git commit -m $added_iso88591
head1=$(git rev-parse --verify HEAD)
head1_short=$(git rev-parse --verify --short $head1)
@@ -136,9 +136,9 @@ EOF
test_format encoding %e EOF
commit $head2
-iso-8859-1
+iso8859-1
commit $head1
-iso-8859-1
+iso8859-1
EOF
test_format subject %s EOF
@@ -242,9 +242,9 @@ test_format complex-encoding %e EOF
commit $head3
iso8859-1
commit $head2
-iso-8859-1
+iso8859-1
commit $head1
-iso-8859-1
+iso8859-1
EOF
test_format complex-subject %s EOF
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 9132dd9..2ef96e9 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -39,7 +39,7 @@ test_expect_success 'creating initial files and commits' '
echo 1st line 2nd file secondfile
echo 2nd line 2nd file secondfile
- git -c i18n.commitEncoding=iso-8859-1 commit -a -m $(commit_msg
iso-8859-1)
+ git -c i18n.commitEncoding=iso8859-1 commit -a -m $(commit_msg
iso8859-1)
head5=$(git rev-parse --verify HEAD)
'
# git log --pretty=oneline # to see those SHA1 involved
@@ -62,10 +62,10 @@ test_expect_success 'reset --hard message' '
test_cmp .expected .actual
'
-test_expect_success 'reset --hard message (iso-8859-1 logoutencoding)' '
+test_expect_success 'reset --hard message (iso8859-1 logoutputencoding)' '
hex=$(git log -1 --format=%h)
- git -c i18n.logOutputEncoding=iso-8859-1 reset --hard .actual
- echo HEAD is now at $hex $(commit_msg iso-8859-1) .expected
+ git -c i18n.logOutputEncoding=iso8859-1 reset --hard .actual
+ echo HEAD is now at $hex $(commit_msg iso8859-1) .expected
[PATCH v9 4/5] t6006: add two more tests for the case i18n.commitEncoding is not set
In de6029a2d7734a93a9e27b9c4471862a47dd8123 'complex-subject' test was changed. Revert it back, and add two more tests to test encoding conversions with no i18n.commitEncoding set. Signed-off-by: Alexey Shumkin alex.crez...@gmail.com Reviewed-by: Johannes Sixt j.s...@viscovery.net --- t/t6006-rev-list-format.sh | 32 +--- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index e069263..843134f 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -217,12 +217,7 @@ test_expect_success 'setup complex body' ' git config i18n.commitencoding iso8859-1 echo change2 foo git commit -a -F commit-msg head3=$(git rev-parse --verify HEAD) - head3_short=$(git rev-parse --short $head3) - # unset commit encoding config - # otherwise %e does not print encoding value - # and following test fails - git config --unset i18n.commitEncoding - + head3_short=$(git rev-parse --short $head3) ' test_format complex-encoding %e EOF @@ -238,12 +233,35 @@ test_format complex-subject %s EOF commit $head3 Test printing of complex bodies commit $head2 +$changed_iso88591 +commit $head1 +$added_iso88591 +EOF + +test_format complex-body %b EOF +commit $head3 +This commit message is much longer than the others, +and it will be encoded in iso8859-1. We should therefore +include an iso8859 character: ¡bueno! + +commit $head2 +commit $head1 +EOF + +# Git uses i18n.commitEncoding if no i18n.logOutputEncoding set +# so unset i18n.commitEncoding to test encoding conversion +git config --unset i18n.commitEncoding + +test_format complex-subject-commitencoding-unset %s EOF +commit $head3 +Test printing of complex bodies +commit $head2 $changed commit $head1 $added EOF -test_format complex-body %b EOF +test_format complex-body-commitencoding-unset %b EOF commit $head3 This commit message is much longer than the others, and it will be encoded in iso8859-1. We should therefore -- 1.8.3.1.15.g5c23c1e -- 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 v9 2/5] t4205: revert back single quotes
In previuos commit de6029a2d7734a93a9e27b9c4471862a47dd8123 single
quotes were replaced with double quotes to make $(commit_msg)
expression in heredoc to work. The same effect can be achieved by using
EOF as a heredoc delimiter instead of \EOF.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
Suggested-by: Johannes Sixt j.s...@viscovery.net
---
t/t4205-log-pretty-formats.sh | 106 +-
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index c283842..ef9770a 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -145,174 +145,174 @@ test_expect_success 'setup more commits' '
head4=$(git rev-parse --verify --short HEAD~3)
'
-test_expect_success 'left alignment formatting'
- git log --pretty='format:%(40)%s' actual
+test_expect_success 'left alignment formatting' '
+ git log --pretty=format:%(40)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
message twoZ
message oneZ
add barZ
$(commit_msg)Z
EOF
test_cmp expected actual
-
+'
-test_expect_success 'left alignment formatting at the nth column'
- git log --pretty='format:%h %|(40)%s' actual
+test_expect_success 'left alignment formatting at the nth column' '
+ git log --pretty=format:%h %|(40)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
$head1 message twoZ
$head2 message oneZ
$head3 add barZ
$head4 $(commit_msg)Z
EOF
test_cmp expected actual
-
+'
-test_expect_success 'left alignment formatting with no padding'
- git log --pretty='format:%(1)%s' actual
+test_expect_success 'left alignment formatting with no padding' '
+ git log --pretty=format:%(1)%s actual
# complete the incomplete line at the end
echo actual
- cat \EOF expected
+ cat EOF expected
message two
message one
add bar
$(commit_msg)
EOF
test_cmp expected actual
-
+'
-test_expect_success 'left alignment formatting with trunc'
- git log --pretty='format:%(10,trunc)%s' actual
+test_expect_success 'left alignment formatting with trunc' '
+ git log --pretty=format:%(10,trunc)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
message ..
message ..
add bar Z
$(commit_msg 8 ..*$)
EOF
test_cmp expected actual
-
+'
-test_expect_success 'left alignment formatting with ltrunc'
- git log --pretty='format:%(10,ltrunc)%s' actual
+test_expect_success 'left alignment formatting with ltrunc' '
+ git log --pretty=format:%(10,ltrunc)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
..sage two
..sage one
add bar Z
$(commit_msg 0 .\{11\})
EOF
test_cmp expected actual
-
+'
-test_expect_success 'left alignment formatting with mtrunc'
- git log --pretty='format:%(10,mtrunc)%s' actual
+test_expect_success 'left alignment formatting with mtrunc' '
+ git log --pretty=format:%(10,mtrunc)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
mess.. two
mess.. one
add bar Z
$(commit_msg 4 .\{11\})
EOF
test_cmp expected actual
-
+'
-test_expect_success 'right alignment formatting'
- git log --pretty='format:%(40)%s' actual
+test_expect_success 'right alignment formatting' '
+ git log --pretty=format:%(40)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
Zmessage two
Zmessage one
Zadd bar
Z$(commit_msg)
EOF
test_cmp expected actual
-
+'
-test_expect_success 'right alignment formatting at the nth column'
- git log --pretty='format:%h %|(40)%s' actual
+test_expect_success 'right alignment formatting at the nth column' '
+ git log --pretty=format:%h %|(40)%s actual
# complete the incomplete line at the end
echo actual
- qz_to_tab_space \EOF expected
+ qz_to_tab_space EOF expected
$head1 message two
$head2 message one
$head3 add bar
$head4 $(commit_msg)
EOF
test_cmp expected actual
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 4, 2013 at 3:42 PM, Antoine Pelisse apeli...@gmail.com wrote: Your problem is that your hook script is not checking $2 so it is overwriting the message even when you do not want to do so. No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the hook I provided... So what you mean is that the hook is not executed with the correct parameters? Could you please provide the output of the /tmp/hook.log file (I can't reproduce right now) ? It only runs for New commit (possibly with merge or squash as arguments). In my case the log is: .git/PREPARE_COMMIT_MSG .git/PREPARE_COMMIT_MSG .git/PREPARE_COMMIT_MSG ... Not running the hook for amend is another problem. What I referred to was that handling the hook's result is done without checking if the state has changed while it was running, like Fredrik has already pointed out. - Orgad -- 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 4/6] .mailmap: Multiple mail addresses of Keith Cascio
Capital letters in mail address. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 6d75678..1e94906 100644 --- a/.mailmap +++ b/.mailmap @@ -52,6 +52,7 @@ Junio C Hamano gits...@pobox.com ju...@hera.kernel.org Junio C Hamano gits...@pobox.com ju...@kernel.org Junio C Hamano gits...@pobox.com jun...@cox.net Karl Hasselström k...@treskal.com +Keith Cascio ke...@cs.ucla.edu ke...@cs.ucla.edu Kevin Leung kevin...@gmail.com Kent Engstrom k...@lysator.liu.se Lars Doelle lars.doelle@on-line ! de -- 1.8.3.2.636.g7943f03 -- 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/6] Corrections to the mailmap file
Hello,
I noticed many duplicates in email addresses but having the same name by
running:
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
Most of these entries are most probably the same person, but we cannot be
sure, as there might be different persons having the same name, then they
are only distinguished by the mail address.
However I suspect most of these to be the same person, having changed
mail addresses.
Here comes an initial batch of corrections to the mailmap file, which
maps people with email addresses of different capitalization onto
the same entity.
(Example n...@mit.edu is the same as n...@mit.edu)
I intend to contact each of the persons individually and ask whether
just their mail address changed, or if they are indeed different persons.
Stefan Beller
Stefan Beller (6):
.mailmap: Multiple email addresses of Alejandro R. Sedeño
.mailmap: Multiple mail addresses of Alex Riesen
.mailmap: Multiple mail addresses of Paul Mackerras
.mailmap: Multiple mail addresses of Keith Cascio
.mailmap: Multiple mail addresses of Johannes Schindelin
.mailmap: Multiple mail addresses of Toby Allsopp
.mailmap | 9 +
1 file changed, 9 insertions(+)
--
1.8.3.2.636.g7943f03
--
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/6] .mailmap: Multiple mail addresses of Alex Riesen
Signed-off-by: Stefan Beller stefanbel...@googlemail.com Signed-off-by: Alex Riesen raa.l...@gmail.com --- .mailmap | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.mailmap b/.mailmap index 3a4dd49..cd46d24 100644 --- a/.mailmap +++ b/.mailmap @@ -6,6 +6,9 @@ # Alejandro R. Sedeño ased...@mit.edu ased...@mit.edu +Alex Riesen raa.l...@gmail.com fo...@t-online.de +Alex Riesen raa.l...@gmail.com raa@limbo.localdomain +Alex Riesen raa.l...@gmail.com r...@steel.home Alex Bennée kernel-hac...@bennee.com Alexander Gavrilov angavri...@gmail.com Aneesh Kumar K.V aneesh.ku...@gmail.com -- 1.8.3.2.636.g7943f03 -- 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 5/6] .mailmap: Multiple mail addresses of Johannes Schindelin
Different capitalization. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 1e94906..d7d7b89 100644 --- a/.mailmap +++ b/.mailmap @@ -38,6 +38,7 @@ Jakub Narębski jna...@gmail.com Jay Soffian jaysoffian+...@gmail.com Jeff King p...@peff.net p...@github.com Joachim Berdal Haga cjh...@fys.uio.no +Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de Johannes Sixt j...@kdbg.org johannes.s...@telecom.at Johannes Sixt j...@kdbg.org j.s...@viscovery.net Johannes Sixt j...@kdbg.org j.s...@eudaptics.com -- 1.8.3.2.636.g7943f03 -- 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/6] .mailmap: Multiple mail addresses of Paul Mackerras
This is an obvious one, as the .(none) addresses are not valid mail addresses. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.mailmap b/.mailmap index cd46d24..6d75678 100644 --- a/.mailmap +++ b/.mailmap @@ -76,6 +76,8 @@ Nanako Shiraishi nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com Nguyễn Thái Ngọc Duy pclo...@gmail.com n...@fluxnic.net n...@cam.org +Paul Mackerras pau...@samba.org paulus@dorrigo.(none) +Paul Mackerras pau...@samba.org paulus@pogo.(none) Peter Krefting pe...@softwolves.pp.se pe...@svarten.intern.softwolves.pp.se Peter Krefting pe...@softwolves.pp.se pe...@softwolves.pp.se Petr Baudis pa...@ucw.cz pa...@suse.cz -- 1.8.3.2.636.g7943f03 -- 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/6] .mailmap: Multiple email addresses of Alejandro R. Sedeño
This is obvious as its only difference is capital letters in one of the mail addresses. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 345cce6..3a4dd49 100644 --- a/.mailmap +++ b/.mailmap @@ -5,6 +5,7 @@ # same person appearing not to be so. # +Alejandro R. Sedeño ased...@mit.edu ased...@mit.edu Alex Bennée kernel-hac...@bennee.com Alexander Gavrilov angavri...@gmail.com Aneesh Kumar K.V aneesh.ku...@gmail.com -- 1.8.3.2.636.g7943f03 -- 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 6/6] .mailmap: Multiple mail addresses of Toby Allsopp
Different capitalization Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index d7d7b89..7e5638d 100644 --- a/.mailmap +++ b/.mailmap @@ -97,6 +97,7 @@ Steven Grimm kor...@midwinter.com Tay Ray Chuan rcta...@gmail.com Theodore Ts'o ty...@mit.edu Thomas Rast tr...@inf.ethz.ch tr...@student.ethz.ch +Toby Allsopp toby.alls...@navman.co.nz toby.alls...@navman.co.nz Tony Luck tony.l...@intel.com Uwe Kleine-König uwe_zeisber...@digi.com Uwe Kleine-König uwe.kleine-koe...@digi.com -- 1.8.3.2.636.g7943f03 -- 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] config: add support for http.url.* settings
The url value is considered a match to a url if the url
value is a prefix of the url which ends on a path component
boundary ('/'). So https://example.com/test; will match
https://example.com/test; and https://example.com/test/too;
but not https://example.com/testextra;.
Longer matches take precedence over shorter matches with
environment variable settings taking precedence over all.
With this configuration:
[http]
useragent = other-agent
noEPSV = true
[http https://example.com;]
useragent = example-agent
sslVerify = false
[http https://example.com/path;]
useragent = path-agent
The https://other.example.com/; url will have useragent
other-agent and sslVerify will be on.
The https://example.com/; url will have useragent
example-agent and sslVerify will be off.
The https://example.com/path/sub; url will have useragent
path-agent and sslVerify will be off.
All three of examples will have noEPSV enabled.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
The credentials configuration values already support url-specific
configuration items in the form credential.url.*. This patch
adds similar support for http configuration values.
Documentation/config.txt | 8 +++
http.c | 125 +++
+---
2 files changed, 116 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b4d4887..27d19a1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1531,6 +1531,14 @@ http.useragent::
of common USER_AGENT strings (but not including those like git/1.7.1).
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
+http.url.*::
+ Any of the http.* options above can be applied selectively to some
urls.
+ For example http.https://example.com.useragent; would set the user
+ agent only for https connections to example.com. The url value
+ matches a url if it is a prefix of the url matching at a '/' boundary.
+ Longer url matches take precedence over shorter ones with the
+ environment variable settings taking precedence over all.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index 2d086ae..7ddf9af 100644
--- a/http.c
+++ b/http.c
@@ -30,6 +30,34 @@ static CURL *curl_default;
char curl_errorstr[CURL_ERROR_SIZE];
+enum http_option_type {
+ o_post_buffer = 0,
+ o_min_sessions,
+#ifdef USE_CURL_MULTI
+ o_max_requests,
+#endif
+ o_ssl_verify,
+ o_ssl_try,
+ o_ssl_cert,
+#if LIBCURL_VERSION_NUM = 0x070903
+ o_ssl_key,
+#endif
+#if LIBCURL_VERSION_NUM = 0x070908
+ o_ssl_capath,
+#endif
+ o_ssl_cainfo,
+ o_low_speed,
+ o_low_time,
+ o_no_epsv,
+ o_http_proxy,
+ o_cookie_file,
+ o_user_agent,
+ o_passwd_req,
+ o_max
+};
+
+static int http_option_maxlen[o_max];
+
static int curl_ssl_verify = -1;
static int curl_ssl_try;
static const char *ssl_cert;
@@ -65,6 +93,23 @@ static struct curl_slist *no_pragma_header;
static struct active_request_slot *active_queue_head;
+static int http_options_url_match(const char *url, const char
*config_url)
+{
+ /*
+* config option with config_url matches url if config_url is a
+* prefix of url and the match ends on a path component boundary.
+* the return value is the length of the match in characters or
+* 0 for no match.
+*/
+ size_t url_len, config_url_len = strlen(config_url);
+ if (!config_url || strncmp(url, config_url, config_url_len))
+ return 0;
+ url_len = strlen(url);
+ if (url_len == config_url_len || url[config_url_len - 1] == '/' ||
url[config_url_len] == '/')
+ return url[config_url_len - 1] == '/' ? config_url_len - 1 :
config_url_len;
+ return 0;
+}
+
size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void
*buffer_)
{
size_t size = eltsize * nmemb;
@@ -143,32 +188,65 @@ static void process_curl_messages(void)
static int http_options(const char *var, const char *value, void *cb)
{
- if (!strcmp(http.sslverify, var)) {
+#define CHECKLEN(opt) if (http_option_maxlen[opt] matchlen) return
0; \
+ else http_option_maxlen[opt] = matchlen
+
+ const char *url = (const char *)cb;
+ const char *key, *dot;
+ int matchlen = 0;
+
+ key = skip_prefix(var, http.);
+ if (!key)
+ return git_default_config(var, value, cb);
+
+ dot = strrchr(key, '.');
+ if (dot) {
+ char *config_url = xmemdupz(key, dot - key);
+ matchlen = http_options_url_match(url, config_url);
+ free(config_url);
+ if (!matchlen)
+ return git_default_config(var, value, cb);
+
Re: [PATCH 0/6] Corrections to the mailmap file
Here is a script to display the entries I was referring to:
---
#!/bin/bash
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d mailmapdoubles
while read line ; do
# remove leading whitespace
trimmed=$(echo $line | sed -e 's/^ *//g' -e 's/ *$//g')
echo git shortlog -sne | grep \$trimmed\
done mailmapdoubles mailmapdoubles2
sh mailmapdoubles2
rm mailmapdoubles
rm mailmapdoubles2
On 07/04/2013 04:04 PM, Stefan Beller wrote:
Hello,
I noticed many duplicates in email addresses but having the same name by
running:
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
Most of these entries are most probably the same person, but we cannot be
sure, as there might be different persons having the same name, then they
are only distinguished by the mail address.
However I suspect most of these to be the same person, having changed
mail addresses.
Here comes an initial batch of corrections to the mailmap file, which
maps people with email addresses of different capitalization onto
the same entity.
(Example n...@mit.edu is the same as n...@mit.edu)
I intend to contact each of the persons individually and ask whether
just their mail address changed, or if they are indeed different persons.
Stefan Beller
Stefan Beller (6):
.mailmap: Multiple email addresses of Alejandro R. Sedeño
.mailmap: Multiple mail addresses of Alex Riesen
.mailmap: Multiple mail addresses of Paul Mackerras
.mailmap: Multiple mail addresses of Keith Cascio
.mailmap: Multiple mail addresses of Johannes Schindelin
.mailmap: Multiple mail addresses of Toby Allsopp
.mailmap | 9 +
1 file changed, 9 insertions(+)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
On Thu, Jul 4, 2013 at 10:44 AM, Tony Finch d...@dotat.at wrote: Jakub Narębski jna...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:59 PM, Jonathan Nieder jrnie...@gmail.com wrote: Tony Finch wrote: +@extra_breadcrumbs:: BTW. perhaps (it is only an idea) @top_level_breadcrumbs or @home_breadcrumbs would be a better name for this variable. + Additional links to be added to the start of the breadcrumb trail, + that are logically above the gitweb projects list. For example, + links to the organization and department which host the gitweb + server. Each element of the list is a reference to an array, + in which element 0 is the link text and element 1 is the + target URL. Is arbitrary HTML permitted in the link text? I had the same question when I was wondering about abusing $home_link_str to do this without a patch :-) Not exactly arbitrary, as it is inside A element, so it cannot contain A links itself (hyperlinks should not be nested), but it is not esc_html-aped. I think it makes sense to permit it for consistency with $home_link_str, but it might be worth mentioning in the manpage so the administrator knows not to set it to something user-controlled --- e.g.: I left this detail out of the man page for consistency with the documentation for $home_link_str. It would be better to improve documentation, than follow current bad practice... ;-P Nb. it would be nice to have relation of @extra_breadcrumbs with $home_link_str explained. I will make that clearer. Perhaps even make ( [ $home_link_str, $home_link ] ) to be default value for @extra_breadcrumbs, making new feature generalization of $home_link*, similarly to how it was done for $stylesheet - @stylesheets transition. What do you think about it? -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
Jakub Narębski jna...@gmail.com wrote: It would be better to improve documentation, than follow current bad practice... ;-P The v2 patch does just that :-) Perhaps even make ( [ $home_link_str, $home_link ] ) to be default value for @extra_breadcrumbs, making new feature generalization of $home_link*, similarly to how it was done for $stylesheet - @stylesheets transition. I don't think that's a win. There's a lot of existing gitweb.conf out there which sets $home_link_str, so the code would have to either print the last element of @extra_breadcrumbs or the $home_link variables depending on whether the variables were modified. And the documentation would have to explain this complicated arrangement. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
On Thu, Jul 4, 2013 at 5:11 PM, Tony Finch d...@dotat.at wrote:
Jakub Narębski jna...@gmail.com wrote:
It would be better to improve documentation, than follow current bad
practice... ;-P
The v2 patch does just that :-)
Thanks.
Perhaps even make ( [ $home_link_str, $home_link ] ) to be default
value for @extra_breadcrumbs, making new feature generalization
of $home_link*, similarly to how it was done for $stylesheet - @stylesheets
transition.
I don't think that's a win. There's a lot of existing gitweb.conf out
there which sets $home_link_str, so the code would have to either print
the last element of @extra_breadcrumbs or the $home_link variables
depending on whether the variables were modified. And the documentation
would have to explain this complicated arrangement.
First, do I understand corrctly that @extra_breadcrumbs are rendered *after*
$home_link*, and in exactly the same manner?
Second, I misremembered how $stylesheet / @stylesheets is handled.
I was thinking more about having in gitweb.perl the following default
initialization for @extra_breadcrumbs:
our @extra_breadcrumbs = ( [ $home_link_str, $home_link ] );
Then one can add breadcrumbs with
push @extra_breadcrumbs, [ $foo_html, $foo_url ], [
esc_html($bar_txt), $bar_url ];
But now I think that we can do better, simply put $home_link_str and $home_link
in @extra_breadcrumbs / @top_level_breadcrumbs / @nav_breadcrumbs before
using it, either via
unshift @nav_breadcrumbs, [ $home_link_str, $home_link ];
or
for $breadcrumb ([ $home_link_str, $home_link ], @nav_breadcrumbs) {
... unless we treat home link in some special way (do we?).
P.S. It is a bit late, but wouldn't { name = $link_name, href = $link_url }
(like %features hash) be a better solution than [ $link_name, $link_url ],
i.e. hashref (named parameters) instead of arrayref (positional parameters).
You wouldn't have to remember which is first: text or URL.
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
Jakub Narębski jna...@gmail.com wrote:
First, do I understand corrctly that @extra_breadcrumbs are rendered *after*
$home_link*, and in exactly the same manner?
Before the home link, and yes, in the same manner. The extra breadcrumbs
are for links to parent pages above gitweb in some hierarchy.
But now I think that we can do better, simply put $home_link_str and
$home_link
in @extra_breadcrumbs / @top_level_breadcrumbs / @nav_breadcrumbs before
using it,
We could save a line that way:
- print $cgi-a({-href = esc_url($home_link)}, $home_link_str) . / ;
+ for my $crumb (@extra_breadcrumbs, [ $home_link_str = $home_link ]) {
+ print $cgi-a({-href = esc_url($crumb-[1])}, $crumb-[0]) .
/ ;
+ }
P.S. It is a bit late, but wouldn't { name = $link_name, href = $link_url }
(like %features hash) be a better solution than [ $link_name, $link_url ],
i.e. hashref (named parameters) instead of arrayref (positional parameters).
You wouldn't have to remember which is first: text or URL.
I thought the fat arrow would be mnemonic enough, and less verbose.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
On Thu, Jul 4, 2013 at 5:56 PM, Tony Finch d...@dotat.at wrote:
Jakub Narębski jna...@gmail.com wrote:
First, do I understand correctly that @extra_breadcrumbs are rendered *after*
$home_link*, and in exactly the same manner?
Before the home link, and yes, in the same manner. The extra breadcrumbs
are for links to parent pages above gitweb in some hierarchy.
Hmmm... I would have thought that they were after home link. I wonder
if leaving it up to user to configure @extra_breadcrumbs to include $home_link
in appropriate place (the unshift / push solution to adding to
@extra_breadcrumbs,
starting with $home_link) would be good idea, or over-engineering.
In what situation do you need those extra breadcrumbs useful? What
necessity / itch to scratch is behind idea of this patch?
But now I think that we can do better, simply put $home_link_str and
$home_link
in @extra_breadcrumbs / @top_level_breadcrumbs / @nav_breadcrumbs before
using it,
We could save a line that way:
- print $cgi-a({-href = esc_url($home_link)}, $home_link_str) . / ;
+ for my $crumb (@extra_breadcrumbs, [ $home_link_str = $home_link ]) {
+ print $cgi-a({-href = esc_url($crumb-[1])}, $crumb-[0]) .
/ ;
+ }
And avoid a bit of code duplication; now we are sure that both
@extra_breadcrumbs and $home_link are rendered in the same way.
P.S. It is a bit late, but wouldn't { name = $link_name, href = $link_url }
(like %features hash) be a better solution than [ $link_name, $link_url ],
i.e. hashref (named parameters) instead of arrayref (positional parameters).
You wouldn't have to remember which is first: text or URL.
I thought the fat arrow would be mnemonic enough, and less verbose.
Yes, hashref solution is a bit verbose. I don't like abusing fat arrow notation,
but here it gives nice mnemonic (hopefully explained in documentation).
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail
Jakub Narębski jna...@gmail.com wrote: In what situation do you need those extra breadcrumbs useful? What necessity / itch to scratch is behind idea of this patch? For an example, see https://git.csx.cam.ac.uk/x/ucs/git/git.git I have three items in @extra_breadcrumbs which point to the University home page, my department home page, and my git server's home page; there are a number of gitolite accounts on the server each of which has a project listing which is where gitweb's home link points. (I expect to change the link texts to make it less confusing when you happen to be looking at my department's account on the git server...) our @extra_breadcrumbs = ( [ cam = 'http://www.cam.ac.uk/' ], [ ucs = 'http://www.ucs.cam.ac.uk/' ], [ git = 'https://git.csx.cam.ac.uk/' ], ); This is in line with our house style (none of which I have implemented on this server yet) - there are other examples of similar breadcrumb trails at https://raven.cam.ac.uk and http://new-webmail.hermes.cam.ac.uk There is a more generic version of this description and config example in v2 of my patch. I hope it is clear enough. I'll send a v3 patch with the code tweak. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
[PATCH v2 0/2] commit: improve UTF-8 validation
This series contains a pair of patches that improve the validation of the UTF-8 used in commit messages. Invalid codepoints, such as surrogates and guaranteed non-characters, are rejected, along with overlong UTF-8 sequences. Changes from v1: * Improved comments to aid those less familiar with Unicode. * Generated test files using printf as part of the test. * Removed FIXME comments for things that have been fixed. * Use a shorter form for detecting surrogate pairs. brian m. carlson (2): commit: reject invalid UTF-8 codepoints commit: reject overlong UTF-8 sequences commit.c | 34 -- t/t3900-i18n-commit.sh | 23 +++ 2 files changed, 51 insertions(+), 6 deletions(-) -- 1.8.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 v3] gitweb: allow extra breadcrumbs to prefix the trail
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch d...@dotat.at
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/gitweb.conf.txt | 22 --
gitweb/gitweb.perl| 7 ++-
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index ea0526e..305db63 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -336,8 +336,26 @@ $home_link_str::
used as the first component of gitweb's breadcrumb trail:
`home link / project / action`. Can be set at build time using
the `GITWEB_HOME_LINK_STR` variable. By default it is set to
projects,
- as this link leads to the list of projects. Other popular choice it to
- set it to the name of site.
+ as this link leads to the list of projects. Another popular choice is
to
+ set it to the name of site. Note that it is treated as raw HTML so it
+ should not be set from untrusted sources.
+
+@extra_breadcrumbs::
+ Additional links to be added to the start of the breadcrumb trail before
+ the home link, to pages that are logically above the gitweb projects
+ list, such as the organization and department which host the gitweb
+ server. Each element of the list is a reference to an array, in which
+ element 0 is the link text (equivalent to `$home_link_str`) and element
+ 1 is the target URL (equivalent to `$home_link`).
++
+For example, the following setting produces a breadcrumb trail like
+home / dev / projects / ... where projects is the home link.
+
+our @extra_breadcrumbs = (
+ [ 'home' = 'https://www.example.org/' ],
+ [ 'dev' = 'https://dev.example.org/' ],
+);
+
$logo_url::
$logo_label::
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d69ada..f429f75 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,9 @@ our $project_maxdepth = ++GITWEB_PROJECT_MAXDEPTH++;
# string of the home link on top of all pages
our $home_link_str = ++GITWEB_HOME_LINK_STR++;
+# extra breadcrumbs preceding the home link
+our @extra_breadcrumbs = ();
+
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = ++GITWEB_SITENAME++
@@ -3982,7 +3985,9 @@ sub print_nav_breadcrumbs_path {
sub print_nav_breadcrumbs {
my %opts = @_;
- print $cgi-a({-href = esc_url($home_link)}, $home_link_str) . / ;
+ for my $crumb (@extra_breadcrumbs, [ $home_link_str = $home_link ]) {
+ print $cgi-a({-href = esc_url($crumb-[1])}, $crumb-[0]) .
/ ;
+ }
if (defined $project) {
my @dirname = split '/', $project;
my $projectbasename = pop @dirname;
--
1.8.3.1.605.g85318f5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] commit: reject invalid UTF-8 codepoints
The commit code already contains code for validating UTF-8, but it does not
check for invalid values, such as guaranteed non-characters and surrogates. Fix
this by explicitly checking for and rejecting such characters.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 27 ++-
t/t3900-i18n-commit.sh | 12
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index 888e02a..2264106 100644
--- a/commit.c
+++ b/commit.c
@@ -1244,6 +1244,7 @@ static int find_invalid_utf8(const char *buf, int len)
while (len) {
unsigned char c = *buf++;
int bytes, bad_offset;
+ unsigned int codepoint;
len--;
offset++;
@@ -1264,24 +1265,40 @@ static int find_invalid_utf8(const char *buf, int len)
bytes++;
}
- /* Must be between 1 and 5 more bytes */
- if (bytes 1 || bytes 5)
+ /*
+* Must be between 1 and 3 more bytes. Longer sequences result
in
+* codepoints beyond U+10, which are guaranteed never to
exist.
+*/
+ if (bytes 1 || bytes 3)
return bad_offset;
/* Do we *have* that many bytes? */
if (len bytes)
return bad_offset;
+ /* Place the encoded bits at the bottom of the value. */
+ codepoint = (c 0x7f) bytes;
+
offset += bytes;
len -= bytes;
/* And verify that they are good continuation bytes */
do {
+ codepoint = 6;
+ codepoint |= *buf 0x3f;
if ((*buf++ 0xc0) != 0x80)
return bad_offset;
} while (--bytes);
- /* We could/should check the value and length here too */
+ /* No codepoints can ever be allocated beyond U+10. */
+ if (codepoint 0x10)
+ return bad_offset;
+ /* Surrogates are only for UTF-16 and cannot be encoded in
UTF-8. */
+ if ((codepoint 0x1ff800) == 0xd800)
+ return bad_offset;
+ /* U+FFFE and U+ are guaranteed non-characters. */
+ if ((codepoint 0x1e) == 0xfffe)
+ return bad_offset;
}
return -1;
}
@@ -1292,8 +1309,8 @@ static int find_invalid_utf8(const char *buf, int len)
* If it isn't, it assumes any non-utf8 characters are Latin1,
* and does the conversion.
*
- * Fixme: we should probably also disallow overlong forms and
- * invalid characters. But we don't do that currently.
+ * Fixme: we should probably also disallow overlong forms.
+ * But we don't do that currently.
*/
static int verify_utf8(struct strbuf *buf)
{
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index 37ddabb..ee8ba6c 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -39,6 +39,18 @@ test_expect_failure 'UTF-16 refused because of NULs' '
git commit -a -F $TEST_DIRECTORY/t3900/UTF-16.txt
'
+test_expect_success 'UTF-8 invalid characters refused' '
+ test_when_finished rm -f $HOME/stderr $HOME/invalid
+ rm -f $HOME/stderr
+ echo UTF-8 characters F
+ printf Commit message\n\nInvalid surrogate:\355\240\200\n \
+ $HOME/invalid
+ git commit -a -F $HOME/invalid \
+ 2$HOME/stderr
+ grep did not conform $HOME/stderr
+'
+
+rm -f $HOME/stderr
for H in ISO8859-1 eucJP ISO-2022-JP
do
--
1.8.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 2/2] commit: reject overlong UTF-8 sequences
The commit code accepts pseudo-UTF-8 sequences that encode a character with more
bytes than necessary. Reject such sequences, since they are not valid UTF-8.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 17 +++--
t/t3900-i18n-commit.sh | 11 +++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index 2264106..b59c187 100644
--- a/commit.c
+++ b/commit.c
@@ -1240,11 +1240,15 @@ int commit_tree(const struct strbuf *msg, unsigned char
*tree,
static int find_invalid_utf8(const char *buf, int len)
{
int offset = 0;
+ static const unsigned int max_codepoint[] = {
+ 0x7f, 0x7ff, 0x, 0x10
+ };
while (len) {
unsigned char c = *buf++;
int bytes, bad_offset;
unsigned int codepoint;
+ unsigned int min_val, max_val;
len--;
offset++;
@@ -1276,8 +1280,12 @@ static int find_invalid_utf8(const char *buf, int len)
if (len bytes)
return bad_offset;
- /* Place the encoded bits at the bottom of the value. */
+ /* Place the encoded bits at the bottom of the value and
compute the
+* valid range.
+*/
codepoint = (c 0x7f) bytes;
+ min_val = max_codepoint[bytes-1] + 1;
+ max_val = max_codepoint[bytes];
offset += bytes;
len -= bytes;
@@ -1290,8 +1298,8 @@ static int find_invalid_utf8(const char *buf, int len)
return bad_offset;
} while (--bytes);
- /* No codepoints can ever be allocated beyond U+10. */
- if (codepoint 0x10)
+ /* Reject codepoints that are out of range for the sequence
length. */
+ if (codepoint min_val || codepoint max_val)
return bad_offset;
/* Surrogates are only for UTF-16 and cannot be encoded in
UTF-8. */
if ((codepoint 0x1ff800) == 0xd800)
@@ -1308,9 +1316,6 @@ static int find_invalid_utf8(const char *buf, int len)
*
* If it isn't, it assumes any non-utf8 characters are Latin1,
* and does the conversion.
- *
- * Fixme: we should probably also disallow overlong forms.
- * But we don't do that currently.
*/
static int verify_utf8(struct strbuf *buf)
{
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index ee8ba6c..94fa1e8 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -50,6 +50,17 @@ test_expect_success 'UTF-8 invalid characters refused' '
grep did not conform $HOME/stderr
'
+test_expect_success 'UTF-8 overlong sequences rejected' '
+ test_when_finished rm -f $HOME/stderr $HOME/invalid
+ rm -f $HOME/stderr $HOME/invalid
+ echo UTF-8 overlong F
+ printf \340\202\251ommit message\n\nThis is not a space:\300\240\n \
+ $HOME/invalid
+ git commit -a -F $HOME/invalid \
+ 2$HOME/stderr
+ grep did not conform $HOME/stderr
+'
+
rm -f $HOME/stderr
for H in ISO8859-1 eucJP ISO-2022-JP
--
1.8.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] gitweb: allow extra breadcrumbs to prefix the trail
On Thu, Jul 4, 2013 at 7:08 PM, Tony Finch d...@dotat.at wrote: Jakub Narębski jna...@gmail.com wrote: In what situation do you need those extra breadcrumbs useful? What necessity / itch to scratch is behind idea of this patch? For an example, see https://git.csx.cam.ac.uk/x/ucs/git/git.git I have three items in @extra_breadcrumbs which point to the University home page, my department home page, and my git server's home page; there are a number of gitolite accounts on the server each of which has a project listing which is where gitweb's home link points. Of course those @external_breadcrumbs are really useful iff they are repeated consistently in at least similar form in all those external pages... (I expect to change the link texts to make it less confusing when you happen to be looking at my department's account on the git server...) -- Jakub Narebski -- 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] gitweb: allow extra breadcrumbs to prefix the trail
On Thu, Jul 4, 2013 at 7:02 PM, Tony Finch d...@dotat.at wrote:
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch d...@dotat.at
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
For what it is worth:
Acked-by: Jakub Narebski jna...@gmail.com
---
Documentation/gitweb.conf.txt | 22 --
gitweb/gitweb.perl| 7 ++-
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index ea0526e..305db63 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -336,8 +336,26 @@ $home_link_str::
used as the first component of gitweb's breadcrumb trail:
`home link / project / action`. Can be set at build time using
the `GITWEB_HOME_LINK_STR` variable. By default it is set to
projects,
- as this link leads to the list of projects. Other popular choice it
to
- set it to the name of site.
+ as this link leads to the list of projects. Another popular choice
is to
+ set it to the name of site. Note that it is treated as raw HTML so it
+ should not be set from untrusted sources.
I wonder if we should change this... but it is issue unrelated to current
patch, which doesn't make situation worse.
+
+@extra_breadcrumbs::
@external_breadcrumbs ???
+ Additional links to be added to the start of the breadcrumb trail
before
+ the home link, to pages that are logically above the gitweb projects
+ list, such as the organization and department which host the gitweb
+ server. Each element of the list is a reference to an array, in which
+ element 0 is the link text (equivalent to `$home_link_str`) and
element
+ 1 is the target URL (equivalent to `$home_link`).
++
+For example, the following setting produces a breadcrumb trail like
+home / dev / projects / ... where projects is the home link.
+
+our @extra_breadcrumbs = (
+ [ 'home' = 'https://www.example.org/' ],
+ [ 'dev' = 'https://dev.example.org/' ],
+);
+
$logo_url::
$logo_label::
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d69ada..f429f75 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,9 @@ our $project_maxdepth = ++GITWEB_PROJECT_MAXDEPTH++;
# string of the home link on top of all pages
our $home_link_str = ++GITWEB_HOME_LINK_STR++;
+# extra breadcrumbs preceding the home link
+our @extra_breadcrumbs = ();
+
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = ++GITWEB_SITENAME++
@@ -3982,7 +3985,9 @@ sub print_nav_breadcrumbs_path {
sub print_nav_breadcrumbs {
my %opts = @_;
- print $cgi-a({-href = esc_url($home_link)}, $home_link_str) . / ;
+ for my $crumb (@extra_breadcrumbs, [ $home_link_str = $home_link ]) {
+ print $cgi-a({-href = esc_url($crumb-[1])}, $crumb-[0]) .
/ ;
+ }
if (defined $project) {
my @dirname = split '/', $project;
my $projectbasename = pop @dirname;
--
1.8.3.1.605.g85318f5
--
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
intend-to-edit flag
Hi, we're evaluating Git to be used in our companies Tool. But a hard requirement is the possibility to set an intend-to-edit flag on a file (better path). Notice that I did not use the word lock! :-) One easy implementation might be a special branch XYZ-locks that contains an empty blob for every flagged file. So our tool just needs to check, whether a blob exists for the path that's intended to edit, tries to push a commit that touches the file and only allows editing if the push succeeds. Does anybody have a better idea, maybe with notes? Thank you, Thomas Koch, http://www.koch.ro -- 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: intend-to-edit flag
On Thu, Jul 04, 2013 at 08:10:07PM +0200, Ævar Arnfjörð Bjarmason wrote: On Thu, Jul 4, 2013 at 7:56 PM, Thomas Koch tho...@koch.ro wrote: we're evaluating Git to be used in our companies Tool. But a hard requirement is the possibility to set an intend-to-edit flag on a file (better path). Notice that I did not use the word lock! :-) One easy implementation might be a special branch XYZ-locks that contains an empty blob for every flagged file. So our tool just needs to check, whether a blob exists for the path that's intended to edit, tries to push a commit that touches the file and only allows editing if the push succeeds. In my experience everyone who thinks this is a hard requirement is wrong. I completely agree with this. Having said that, if you're looking at using Gitolite (which you should if you're hosing your own repositories and not using some other hosting solution), there is a lock command [1]. Note that this cannot stop you committing changes to locked files locally but it does stop you pushing changes to the central repository that touch locked files. [1] http://gitolite.com/gitolite/locking.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: intend-to-edit flag
On Thursday, July 04, 2013 08:10:07 PM Ævar Arnfjörð Bjarmason wrote: Why don't you just start using Git and see if this becomes a practical problem rather than devising some elaborate solution to work around something that probably won't be an issue anyway? I've been giving talks about Git already in 2008. I know that we don't need locking. But my boss says we need it. - So he'll get it. Thomas Koch, http://www.koch.ro -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Junio C Hamano wrote:
I like the part that gets rid of that get-mode-bits but at the
same time, I find this part wanting a reasonable in-code comment.
Indeed. (As I said, a bit rough around the edges ;-)
At least, with the earlier get-mode-bits, it was clear why we are
doing something special in that codepath, both from the name of the
helper function/macro and the comment attached to it describing how
the regular one is cheating.
We must say why this fast is not used everywhere and what criteria
you should apply when deciding to use it (or not use it). And the
fast name is much less descriptive.
I suspect (without thinking it through) that the rule would be
something like:
The fast variant is to be used to read from the filesystem the
stat bits that are stuffed into the index for quick touch
detection (aka cached stat info) and/or that are compared
with the cached stat info, and should not be used anywhere else.
Sounds good to me.
But then we always use lstat(2) and not stat(2) for that, so...
Indeed. Although there may be need of an fast_fstat (see below). :(
+#ifndef GIT_FAST_STAT
+static inline int fast_stat(const char *path, struct stat *st)
+{
+return stat(path, st);
+}
+static inline int fast_lstat(const char *path, struct stat *st)
+{
+return lstat(path, st);
+}
+#endif
Yes, I'm not very good at naming things, so suggestions welcome!
Note that I missed at least one lstat() call which needed to be renamed
to fast_lstat() (builtin/apply.c, line 3094 in checkout_target()).
This is my main concern with this patch (i.e. that I have missed some
more lstat calls that need to be renamed). I was a little surprised
at the size of the patch; direct index manipulation is more widespread
than I had expected.
Also, since cygwin has UNRELIABLE_FSTAT defined, on the first pass of
the patch, I ignored the use of fstat() in write_entry(). However, *if*
we allow for some other platform, which has a reliable fstat, but wants
to provide fast stat variants, then these fstat calls should logically
be fast. Alternatively, we could drop the use of fstat(), like so:
diff --git a/entry.c b/entry.c
index 4d2ac73..d04d7a1 100644
--- a/entry.c
+++ b/entry.c
@@ -104,21 +104,9 @@ static int open_output_fd(char *path, struct cache_entry
*ce, int to_tempfile)
}
}
-static int fstat_output(int fd, const struct checkout *state, struct stat
*st)
-{
- /* use fstat() only when path == ce-name */
- if (fstat_is_reliable()
- state-refresh_cache !state-base_dir_len) {
- fstat(fd, st);
- return 1;
- }
- return 0;
-}
-
static int streaming_write_entry(struct cache_entry *ce, char *path,
struct stream_filter *filter,
- const struct checkout *state, int to_tempfile,
- int *fstat_done, struct stat *statbuf)
+ const struct checkout *state, int to_tempfile)
{
int result = 0;
int fd;
@@ -128,7 +116,6 @@ static int streaming_write_entry(struct cache_entry *ce,
char *path,
return -1;
result |= stream_blob_to_fd(fd, ce-sha1, filter, 1);
- *fstat_done = fstat_output(fd, state, statbuf);
result |= close(fd);
if (result)
@@ -139,7 +126,7 @@ static int streaming_write_entry(struct cache_entry *ce,
char *path,
static int write_entry(struct cache_entry *ce, char *path, const struct
checkout *state, int to_tempfile)
{
unsigned int ce_mode_s_ifmt = ce-ce_mode S_IFMT;
- int fd, ret, fstat_done = 0;
+ int fd, ret;
char *new;
struct strbuf buf = STRBUF_INIT;
unsigned long size;
@@ -150,8 +137,7 @@ static int write_entry(struct cache_entry *ce, char
*path, const struct checkout
struct stream_filter *filter = get_stream_filter(ce-name,
ce-sha1);
if (filter
!streaming_write_entry(ce, path, filter,
-state, to_tempfile,
-fstat_done, st))
+state, to_tempfile))
goto finish;
}
@@ -190,8 +176,6 @@ static int write_entry(struct cache_entry *ce, char
*path, const struct checkout
}
wrote = write_in_full(fd, new, size);
- if (!to_tempfile)
- fstat_done = fstat_output(fd, state, st);
close(fd);
free(new);
if (wrote != size)
@@ -209,8 +193,7 @@ static int write_entry(struct cache_entry *ce, char
*path, const struct checkout
finish:
if (state-refresh_cache) {
- if (!fstat_done)
- fast_lstat(ce-name, st);
+ fast_lstat(ce-name, st);
Re: [PATCH 1/2] show-ref.c: Add missing call to git_config()
Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: Yes, I will send a v2 (soon-ish, I hope). Ping? No need to hurry, but just to make sure this didn't disappear from everybody's radar. Yep, this is still on my TODO list. Sorry for being tardy on these patches. :( ATB, Ramsay Jones -- 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: unexpected file deletion after using git rebase --abort
On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Paul A. Kennedy wrote: If we don't expect this, should we update the documentation for the --abort heading in the git rebase man page to indicate that newly staged content will be lost after a git rebase --abort? How about something along these lines? diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt index 6b2e1c8..dcae40d 100644 --- i/Documentation/git-rebase.txt +++ w/Documentation/git-rebase.txt @@ -240,6 +240,9 @@ leave out at most one of A and B, in which case it defaults to HEAD. started, then HEAD will be reset to branch. Otherwise HEAD will be reset to where it was when the rebase operation was started. ++ +This discards any changes to files tracked in the working tree or branch. +You may want to stash your changes first (see linkgit:git-stash[1]). rebase --abort is typically used to get rid of conflicted mess the user does not want to resolve right now, and stash would not be a sensible thing to use in such a situation, I think. Doesn't it even refuse to work if there is a conflicted entry in the index? Thanks for thinking about this with me. After contemplating your messages, I think that it's unreasonable to expect git rebase --abort to be able to properly handle content from completely outside the repo and only placed in the index. I think that Jonathan's suggestion makes too mild a point (and I think Junio's objection may be a consequence of this). I've added a little paragraph to the documentation that covers two cases: what you should do before you started (i.e. git-stash if messing about with adding content); and how to recover in case you managed to lose content in this way (hence the links to git-fsck and git-cat-file). This is the diff (against v.1.8.3.2 in the git tree): diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index aca8405..ffaef29 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -238,6 +238,13 @@ leave out at most one of A and B, in which case it defaults to HEAD. will be reset to where it was when the rebase operation was started. + Untracked files added to the index will not be unstaged, and + therefore, not present in the working directory upon abort. + Unstage files before the abort, or stash untracked content before + starting the rebase (see linkgit:git-stash[1]). Dangling blobs + may be found and recovered using fsck and cat-file (see + linkgit:git-fsck[1], linkgit:git-cat-file[1]). + --keep-empty:: Keep the commits that do not change anything from its parents in the result. -- Paul A. Kennedy paken...@pobox.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/7] wrap-for-bin: Make bin-wrappers chainable
From: Benoit Person benoit.per...@ensimag.fr
For now, bin-wrappers overwrites GITPERLLIB. If we want to chain to
those scripts and define GITPERLLIB before, our changes will be
discarded.
This patch makes the bin-wrappers prepend their modifications to
GITPERLLIB rather than redefining it. It also unset GITPERLLIB in the
test-suite to prevent broken $GITPERLLIB in the user's configuration
from interfering with the testsuite.
The codes using GIT_TEMPLATE_DIR and GIT_TEXTDOMAINDIR handle only one
path in each of this variable so this new behavior would be useless on
those variables.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
t/test-lib.sh | 1 +
wrap-for-bin.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index eff3a65..43e2a39 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -92,6 +92,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $($PERL_PATH -e '
print join(\n, @vars);
')
unset XDG_CONFIG_HOME
+unset GITPERLLIB
GIT_AUTHOR_EMAIL=aut...@example.com
GIT_AUTHOR_NAME='A U Thor'
GIT_COMMITTER_EMAIL=commit...@example.com
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
index 53a8dd0..35b394a 100644
--- a/wrap-for-bin.sh
+++ b/wrap-for-bin.sh
@@ -14,7 +14,7 @@ else
GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt'
export GIT_TEMPLATE_DIR
fi
-GITPERLLIB='@@BUILD_DIR@@/perl/blib/lib'
+GITPERLLIB='@@BUILD_DIR@@/perl/blib/lib:'${GITPERLLIB:+:$GITPERLLIB}
GIT_TEXTDOMAINDIR='@@BUILD_DIR@@/po/build/locale'
PATH='@@BUILD_DIR@@/bin-wrappers:'$PATH
export GIT_EXEC_PATH GITPERLLIB PATH GIT_TEXTDOMAINDIR
--
1.8.3.1.590.gc07d91b
--
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 v8 3/7] git-remote-mediawiki: New git bin-wrapper for developement
From: Benoit Person benoit.per...@ensimag.fr
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypassing its
installed version if any.
An alternate solution was to 'install' all the files required at each build
but it pollutes the toplevel with untracked files.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Makefile| 6 ++
contrib/mw-to-git/bin-wrapper/git | 14 ++
2 files changed, 20 insertions(+)
create mode 100755 contrib/mw-to-git/bin-wrapper/git
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index a6f8b24..c5e66df 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -2,6 +2,12 @@
# Copyright (C) 2013
# Matthieu Moy matthieu@imag.fr
#
+# To build and test:
+#
+# make:
+# bin-wrapper/git mw preview Some_page.mw
+# bin-wrapper/git clone mediawiki::http://example.com/wiki/
+#
# To install, run Git's toplevel 'make install' then run:
#
# make install
diff --git a/contrib/mw-to-git/bin-wrapper/git
b/contrib/mw-to-git/bin-wrapper/git
new file mode 100755
index 000..59c1420
--- /dev/null
+++ b/contrib/mw-to-git/bin-wrapper/git
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+# git executable wrapper script for Git-Mediawiki to run tests without
+# installing all the scripts and perl packages.
+
+GIT_ROOT_DIR=../../..
+GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
+
+GITPERLLIB=$GIT_EXEC_PATH'/contrib/mw-to-git:'${GITPERLLIB:+:$GITPERLLIB}
+PATH=$GIT_EXEC_PATH'/contrib/mw-to-git:'$PATH
+
+export GITPERLLIB PATH
+
+exec ${GIT_EXEC_PATH}/bin-wrappers/git $@
--
1.8.3.1.590.gc07d91b
--
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 v8 0/7] git-remote-mediawiki: new tool to preview local changes without pushing
From: Benoit Person benoit.per...@ensimag.fr
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v7:
- Update commit message of 1/7: remove the obvious (we need a way to
share code between scripts) and make the commit message less vague.
- Update commit message of 2/7: it's useless to do the same
update on GIT_TEMPLATE_DIR and GIT_TEXTDOMAINDIR since the codes using
them do not seem to handle multiple dirs.
- Remove trailing ':' while concatening GITPERLLIB to itself in files:
- wrap-for-bin.sh
- contrib/mw-to-git/bin-wrapper/git
changes from v6:
- Rewrite of bin-wrapper/git in 3/7
- Update wrap-for-bin.sh and make bin-wrappers chainable it
removes the need for a GPLEXTEA since we only have to first
define GITPERLLIB, the bin-wrappers will no longer overwrite
it. (2/7)
Maybe we should apply the same mechanism to all variables in
wrap-for-bin.sh ? (there is no need for it right now though)
- Replace the symlink created in the test suite (if git-remote-mediawiki
was not installed) by the new bin-wrapper introduced in 3/4 (4/7).
- Small typos in the commit messages
changes from v5:
- Move git bin-wrapper 'git' into bin-wrapper/
- Updates its GIT_ROOT_DIR accordingly
- Updates the Makefile to use that new path in the comments
changes from v4:
- Rebase on latest master
- Typos in commits messages and code
- Comments in Makefile
- Factoring the conversion from relatives links to absolute ones in
`git mw preview`
- Updating that conversion mechanism to not convert links with an
anchor '#'.
- git-mw should be executable now.
changes from v3:
- Rewrite all commit messages.
- No more \ No newline at end of file.
- Rename GitMediawiki.pm into Git::Mediawiki.pm (so it moves GitMedawiki.pm
into Git/Mediawiki.pm).
- Remove from the Makefile the copy_pm target (see below 'Add a bin-wrapper').
- Use of 'install' insted of 'cp' in the Makefile.
- Comment on the install_pm target in the Makefile.
- Add a bin-wrapper for git to test scripts without 'make install'-ing them.
- Move verbose option handling from previous v3-4/4 (introduction of preview
tool) into v4-4/5 (introduction of git-mw).
- Refactor some code into subroutines to clean the global 'preview'
subroutine.
- Rewrite some error messages to make them more concise while still giving
the same amount of information.
- Use 'remote.${remote_name}.mwIDcontent' instead of 'mediawiki.IDContent'
as config item for the lookup ID used to combine template + new content.
- Remove comments about what's going on in the preview subroutine.
- Use 'clean_filename' (and not 'smudge_filename') in the preview tool to find
the correct mediawiki page name based on a filename.
- Remove space/tab mixup in the 'help' subroutine.
changes from v2:
- Add a way to test, without installation, code that uses GitMediawiki.pm.
- Move more constants to GitMediawiki.pm
- Remove the encapsulation of Git::config calls into a git_cmd_try one.
- Remove the --blob option, distinction between files and blobs is now
automatic.
- Add a --verbose option to output more information on what's going on.
- Rewrote the doc and the commit message.
- Rewrote of the template retrieving code (see 'get_template' sub).
- Use a configuration variable to define the content ID search in the
template. Default value set as 'bodyContent' since it seems more standard
than 'mw-content-text'.
- Final content is now saved as utf-8 to solve encoding issues.
- Perlcritic changes:
- Update for loops style to a more perlish one.
- All 'print's specify their output streams.
-- Same useless warnings left in git-remote-mediawiki.perl after
célestin's
work and git-mw.perl after this patch :) .
changes from v1:
- add new package GitMediawiki
- move some of git-remote-mediawiki functions into the package
- update git-remote-mediawiki to use those moved functions
- add a hacky-way to install it in the Makefile
- use it in the new git mw tool
- add a way to give to the preview tool blobs as argument
- add a fallback when the upstream's branch remote is not a mediawiki remote
- update the `autoload` option to use `git web--browse` and not `xdg-open`
- update the way we find the upstream's branch remote name
[1] https://github.com/moy/Git-Mediawiki/issues/7
Benoit Person (7):
git-remote-mediawiki: Introduction of Git::Mediawiki.pm
wrap-for-bin: Make bin-wrappers chainable
git-remote-mediawiki: New git bin-wrapper for developement
git-remote-mediawiki: Update tests to run with the new bin-wrapper
git-remote-mediawiki: Factoring code between git-remote-mediawiki and
Git::Mediawiki
git-remote-mediawiki: Adding git-mw command
git-remote-mediawiki: Add preview subcommand into git mw
[PATCH v8 1/7] git-remote-mediawiki: Introduction of Git::Mediawiki.pm
From: Benoit Person benoit.per...@ensimag.fr
We would want to allow the user to preview what he has edited locally
before pushing it out (and thus creating a non-removable revision in
the mediawiki's history).
This patch introduces a new perl package in which we will be able to
share code between that new tool and the remote helper:
git-remote-mediawiki.perl.
A perl package offers the best way to handle such case: Each script
can select what should be imported in its namespace. The package
namespacing limits the use of side effects in the shared code.
An alternate solution is to concatenate a toolset file with each
*.perl when 'make'-ing the project. In that scheme, everything is
imported in the script's namespace. Plus, files should be renamed in
order to chain to Git's toplevel makefile. Hence, this solution is not
acceptable.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 24
contrib/mw-to-git/Makefile | 24 +---
2 files changed, 45 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/Git/Mediawiki.pm
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
new file mode 100644
index 000..805f42a
--- /dev/null
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -0,0 +1,24 @@
+package Git::Mediawiki;
+
+use 5.008;
+use strict;
+use Git;
+
+BEGIN {
+
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
+
+# Totally unstable API.
+$VERSION = '0.01';
+
+require Exporter;
+
+@ISA = qw(Exporter);
+
+@EXPORT = ();
+
+# Methods which can be called as standalone functions as well:
+@EXPORT_OK = ();
+}
+
+1; # Famous last words
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index 1fb2424..a6f8b24 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -2,18 +2,36 @@
# Copyright (C) 2013
# Matthieu Moy matthieu@imag.fr
#
-## Build git-remote-mediawiki
+# To install, run Git's toplevel 'make install' then run:
+#
+# make install
+GIT_MEDIAWIKI_PM=Git/Mediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+INSTLIBDIR=$(shell $(MAKE) -C $(GIT_ROOT_DIR)/perl \
+-s --no-print-directory instlibdir)
all: build
-build install clean:
+install_pm:
+ install $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
+
+build:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+build-perl-script
+
+install: install_pm
$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
-$@-perl-script
+install-perl-script
+
+clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+clean-perl-script
+ rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
+
perlcritic:
perlcritic -2 *.perl
--
1.8.3.1.590.gc07d91b
--
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 v8 6/7] git-remote-mediawiki: Adding git-mw command
From: Benoit Person benoit.per...@ensimag.fr
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implemented. It also provides some generic code
for the verbose and help command line options.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Makefile| 7 ++---
contrib/mw-to-git/git-mw.perl | 60 +++
2 files changed, 64 insertions(+), 3 deletions(-)
create mode 100755 contrib/mw-to-git/git-mw.perl
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index c5e66df..775cb07 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -14,6 +14,7 @@
GIT_MEDIAWIKI_PM=Git/Mediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
+SCRIPT_PERL+=git-mw.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
@@ -27,15 +28,15 @@ install_pm:
install $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
build:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
build-perl-script
install: install_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
install-perl-script
clean:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
clean-perl-script
rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100755
index 000..4a3e4a9
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
@@ -0,0 +1,60 @@
+#!/usr/bin/perl
+
+# Copyright (C) 2013
+# Benoit Person benoit.per...@ensimag.imag.fr
+# Celestin Matte celestin.ma...@ensimag.imag.fr
+# License: GPL v2 or later
+
+# Set of tools for git repo with a mediawiki remote.
+# Documentation bugtracker: https://github.com/moy/Git-Mediawiki/
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+
+# By default, use UTF-8 to communicate with Git and the user
+binmode STDERR, ':encoding(UTF-8)';
+binmode STDOUT, ':encoding(UTF-8)';
+
+# Global parameters
+my $verbose = 0;
+sub v_print {
+ if ($verbose) {
+ return print {*STDERR} @_;
+ }
+ return;
+}
+
+my %commands = (
+ 'help' =
+ [\help, {}, \help]
+);
+
+# Search for sub-command
+my $cmd = $commands{'help'};
+for (0..@ARGV-1) {
+ if (defined $commands{$ARGV[$_]}) {
+ $cmd = $commands{$ARGV[$_]};
+ splice @ARGV, $_, 1;
+ last;
+ }
+};
+GetOptions( %{$cmd-[1]},
+ 'help|h' = \{$cmd-[2]},
+ 'verbose|v' = \$verbose);
+
+# Launch command
+{$cmd-[0]};
+
+## Help Functions
##
+
+sub help {
+ print {*STDOUT} 'END';
+usage: git mw command args
+
+git mw commands are:
+helpDisplay help information about git mw
+END
+ exit;
+}
--
1.8.3.1.590.gc07d91b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] commit: reject invalid UTF-8 codepoints
On Thu, Jul 04, 2013 at 09:58:08PM +0200, Torsten Bögershausen wrote: On 2013-07-04 19.19, brian m. carlson wrote: The commit code already contains code for validating UTF-8, but it does not check for invalid values, such as guaranteed non-characters and surrogates. Fix s/guaranteed non-characters/code points out of range/ The such as is meant to be illustrative, not all-inclusive, and my patch does check for U+FFFE and U+, which are guaranteed non-characters. this by explicitly checking for and rejecting such characters. Do we really reject them, or do we (only) warn about them ? Well, find_invalid_utf8 rejects them as invalid, and verify_utf8 fixes them up as if they were Latin-1, and commit_tree_extended warns about them. My interpretation was from the point of view of the code that I touched (find_invalid_utf8), not the binary. It would be nice if the binary actually rejected it, too, but that isn't within the scope of this patch. Other question: Now that we have a check for codepoints out of range, beyond U+10, do we want to have an additional testcase ? Sure, why not? +test_expect_success 'UTF-8 invalid characters refused' ' May be: test_expect_success 'UTF-8 invalid surrogate' ' Since I'll be adding at least one more unit test, as you requested, I'll change the name. I suppose I might as well add a test for the non-characters as well. Does it make sense to grep on the fly, like this: git commit -a -F $HOME/invalid 21 | grep did not conform I am interested in making sure that git commit succeeds, and using a pipe will cause any failure of git commit to be ignored. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH v8 5/7] git-remote-mediawiki: Factoring code between git-remote-mediawiki and Git::Mediawiki
From: Benoit Person benoit.per...@ensimag.fr
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 77 +-
contrib/mw-to-git/git-remote-mediawiki.perl | 85 +
2 files changed, 89 insertions(+), 73 deletions(-)
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
index 805f42a..47fe4f4 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -18,7 +18,82 @@ require Exporter;
@EXPORT = ();
# Methods which can be called as standalone functions as well:
-@EXPORT_OK = ();
+@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
+}
+
+# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
+use constant SLASH_REPLACEMENT = '%2F';
+
+# Used to test for empty strings
+use constant EMPTY = q{};
+
+# HTTP codes
+use constant HTTP_CODE_OK = 200;
+
+sub clean_filename {
+ my $filename = shift;
+ $filename =~ s{@{[SLASH_REPLACEMENT]}}{/}g;
+ # [, ], |, {, and } are forbidden by MediaWiki, even URL-encoded.
+ # Do a variant of URL-encoding, i.e. looks like URL-encoding,
+ # but with _ added to prevent MediaWiki from thinking this is
+ # an actual special character.
+ $filename =~ s/[\[\]\{\}\|]/sprintf(_%%_%x, ord($))/ge;
+ # If we use the uri escape before
+ # we should unescape here, before anything
+
+ return $filename;
+}
+
+sub smudge_filename {
+ my $filename = shift;
+ $filename =~ s{/}{@{[SLASH_REPLACEMENT]}}g;
+ $filename =~ s/ /_/g;
+ # Decode forbidden characters encoded in clean_filename
+ $filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf('%c', hex($1))/ge;
+ return $filename;
+}
+
+sub connect_maybe {
+ my $wiki = shift;
+ if ($wiki) {
+ return $wiki;
+ }
+
+ my $remote_name = shift;
+ my $remote_url = shift;
+ my ($wiki_login, $wiki_password, $wiki_domain);
+
+ $wiki_login = Git::config(remote.${remote_name}.mwLogin);
+ $wiki_password = Git::config(remote.${remote_name}.mwPassword);
+ $wiki_domain = Git::config(remote.${remote_name}.mwDomain);
+
+ $wiki = MediaWiki::API-new;
+ $wiki-{config}-{api_url} = ${remote_url}/api.php;
+ if ($wiki_login) {
+ my %credential = (
+ 'url' = $remote_url,
+ 'username' = $wiki_login,
+ 'password' = $wiki_password
+ );
+ Git::credential(\%credential);
+ my $request = {lgname = $credential{username},
+ lgpassword = $credential{password},
+ lgdomain = $wiki_domain};
+ if ($wiki-login($request)) {
+ Git::credential(\%credential, 'approve');
+ print {*STDERR} qq(Logged in mediawiki user
$credential{username}.\n);
+ } else {
+ print {*STDERR} qq(Failed to log in mediawiki user
$credential{username} on ${remote_url}\n);
+ print {*STDERR} ' (error ' .
+ $wiki-{error}-{code} . ': ' .
+ $wiki-{error}-{details} . )\n;
+ Git::credential(\%credential, 'reject');
+ exit 1;
+ }
+ }
+
+ return $wiki;
}
1; # Famous last words
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 71baf8a..e40c034 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -14,6 +14,8 @@
use strict;
use MediaWiki::API;
use Git;
+use Git::Mediawiki qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
use DateTime::Format::ISO8601;
use warnings;
@@ -23,9 +25,6 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
-# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT = '%2F';
-
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this content.
use constant DELETED_CONTENT = [[Category:Deleted]]\n;
@@ -40,8 +39,6 @@ use constant NULL_SHA1 =
'';
# Used on Git's side to reflect empty edit messages on the wiki
use constant EMPTY_MESSAGE
[PATCH v8 7/7] git-remote-mediawiki: Add preview subcommand into git mw
From: Benoit Person benoit.per...@ensimag.fr
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any change on the wiki.
This uses Mediawiki's API to render the markup and inserts it in an actual
HTML page from the wiki so that CSS can be rendered properly. Most links
should work when the page exists on the remote.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 3 +-
contrib/mw-to-git/git-mw.perl | 310 -
2 files changed, 311 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
index 47fe4f4..d13c4df 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -19,7 +19,7 @@ require Exporter;
# Methods which can be called as standalone functions as well:
@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
- EMPTY HTTP_CODE_OK);
+ EMPTY HTTP_CODE_OK HTTP_CODE_PAGE_NOT_FOUND);
}
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
@@ -30,6 +30,7 @@ use constant EMPTY = q{};
# HTTP codes
use constant HTTP_CODE_OK = 200;
+use constant HTTP_CODE_PAGE_NOT_FOUND = 404;
sub clean_filename {
my $filename = shift;
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
index 4a3e4a9..28df3ee 100755
--- a/contrib/mw-to-git/git-mw.perl
+++ b/contrib/mw-to-git/git-mw.perl
@@ -12,6 +12,14 @@ use strict;
use warnings;
use Getopt::Long;
+use URI::URL qw(url);
+use LWP::UserAgent;
+use HTML::TreeBuilder;
+
+use Git;
+use MediaWiki::API;
+use Git::Mediawiki qw(clean_filename connect_maybe
+ EMPTY HTTP_CODE_PAGE_NOT_FOUND);
# By default, use UTF-8 to communicate with Git and the user
binmode STDERR, ':encoding(UTF-8)';
@@ -26,9 +34,26 @@ sub v_print {
return;
}
+# Preview parameters
+my $file_name = EMPTY;
+my $remote_name = EMPTY;
+my $preview_file_name = EMPTY;
+my $autoload = 0;
+sub file {
+ $file_name = shift;
+ return $file_name;
+}
+
my %commands = (
'help' =
- [\help, {}, \help]
+ [\help, {}, \help],
+ 'preview' =
+ [\preview, {
+ '' = \file,
+ 'output|o=s' = \$preview_file_name,
+ 'remote|r=s' = \$remote_name,
+ 'autoload|a' = \$autoload
+ }, \preview_help]
);
# Search for sub-command
@@ -47,6 +72,288 @@ GetOptions( %{$cmd-[1]},
# Launch command
{$cmd-[0]};
+# Preview Functions
+
+sub preview_help {
+ print {*STDOUT} 'END';
+USAGE: git mw preview [--remote|-r remote name] [--autoload|-a]
+ [--output|-o output filename] [--verbose|-v]
+ blob | filename
+
+DESCRIPTION:
+Preview is an utiliy to preview local content of a mediawiki repo as if it was
+pushed on the remote.
+
+For that, preview searches for the remote name of the current branch's
+upstream if --remote is not set. If that remote is not found or if it
+is not a mediawiki, it lists all mediawiki remotes configured and asks
+you to replay your command with the --remote option set properly.
+
+Then, it searches for a file named 'filename'. If it's not found in
+the current dir, it will assume it's a blob.
+
+The content retrieved in the file (or in the blob) will then be parsed
+by the remote mediawiki and combined with a template retrieved from
+the mediawiki.
+
+Finally, preview will save the HTML result in a file. and autoload it
+in your default web browser if the option --autoload is present.
+
+OPTIONS:
+-r remote name, --remote remote name
+If the remote is a mediawiki, the template and the parse engine
+used for the preview will be those of that remote.
+If not, a list of valid remotes will be shown.
+
+-a, --autoload
+Try to load the HTML output in a new tab (or new window) of your
+default web browser.
+
+-o output filename, --output output filename
+Change the HTML output filename. Default filename is based on the
+input filename with its extension replaced by '.html'.
+
+-v, --verbose
+Show more information on what's going on under the hood.
+END
+ exit;
+}
+
+sub preview {
+ my $wiki;
+ my ($remote_url, $wiki_page_name);
+ my ($new_content, $template);
+ my $file_content;
+
+ if ($file_name eq EMPTY) {
+ die Missing file argument, see `git mw help`\n;
[PATCH v8 4/7] git-remote-mediawiki: Update tests to run with the new bin-wrapper
From: Benoit Person benoit.per...@ensimag.fr
Until now, if git-remote-mediawiki was not installed, the test suite
copied it to the toplevel directory. This solution pollutes the
directory with untracked files. Plus, we would need to copy the new
git-mw.perl file to test it too.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/t/test-gitmw-lib.sh | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/t/test-gitmw-lib.sh
b/contrib/mw-to-git/t/test-gitmw-lib.sh
index bb76cee..ca6860f 100755
--- a/contrib/mw-to-git/t/test-gitmw-lib.sh
+++ b/contrib/mw-to-git/t/test-gitmw-lib.sh
@@ -62,12 +62,8 @@ test_check_precond () {
test_done
fi
- if [ ! -f $GIT_BUILD_DIR/git-remote-mediawiki ];
- then
- echo No remote mediawiki for git found. Copying it in git
- echo cp $GIT_BUILD_DIR/contrib/mw-to-git/git-remote-mediawiki
$GIT_BUILD_DIR/
- ln -s $GIT_BUILD_DIR/contrib/mw-to-git/git-remote-mediawiki
$GIT_BUILD_DIR
- fi
+ GIT_EXEC_PATH=$(cd $(dirname $0) cd ../.. pwd)
+ PATH=$GIT_EXEC_PATH'/bin-wrapper:'$PATH
if [ ! -d $WIKI_DIR_INST/$WIKI_DIR_NAME ];
then
--
1.8.3.1.590.gc07d91b
--
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] test-lib.sh - cygwin does not have usable FIFOs
Do not use FIFOs on cygwin, they do not work. Cygwin includes
coreutils, so has mkfifo, and that command does something. However,
the resultant named pipe is known (on the Cygwin mailing list at
least) to not work correctly.
This disables PIPE for Cygwin, allowing t0008.sh to complete (all other
tests in that file work correctly).
Signed-off-by: Mark Levedahl mleved...@gmail.com
---
t/test-lib.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 9753641..2d63307 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -885,7 +885,14 @@ test_i18ngrep () {
test_lazy_prereq PIPE '
# test whether the filesystem supports FIFOs
- rm -f testfifo mkfifo testfifo
+ case $(uname -s) in
+ CYGWIN*)
+ false
+ ;;
+ *)
+ rm -f testfifo mkfifo testfifo
+ ;;
+ esac
'
test_lazy_prereq SYMLINKS '
--
1.8.3.2.0.13
--
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] send-email: provide port separately from hostname
From: brian m. carlson sand...@crustytoothpaste.net
If the SMTP port is provided as part of the hostname to Net::SMTP, it passes
the combined string to the SASL provider; this causes GSSAPI authentication to
fail since Kerberos does not want the port information. Instead, pass the port
as a separate argument as is done for SSL connections.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-send-email.perl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..ca86a13 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1199,9 +1199,11 @@ X-Mailer: git-send-email $gitversion
else {
require Net::SMTP;
$smtp_domain ||= maildomain();
- $smtp ||= Net::SMTP-new(smtp_host_string(),
+ $smtp_server_port ||= 25;
+ $smtp ||= Net::SMTP-new($smtp_server,
Hello = $smtp_domain,
-Debug = $debug_net_smtp);
+Debug = $debug_net_smtp,
+Port = $smtp_server_port);
if ($smtp_encryption eq 'tls' $smtp) {
require Net::SMTP::SSL;
$smtp-command('STARTTLS');
--
1.8.3.2.923.g2a18ff8.dirty
--
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] send-email: provide port separately from hostname
brian m. carlson wrote:
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..ca86a13 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1199,9 +1199,11 @@ X-Mailer: git-send-email $gitversion
else {
require Net::SMTP;
$smtp_domain ||= maildomain();
- $smtp ||= Net::SMTP-new(smtp_host_string(),
Hm, so the problem occurs when you give smtp_host_string() to
Net::SMTP-new() as the first argument.
+ $smtp_server_port ||= 25;
So if smtp_host_string() returns a hostname without a port, then
Net::SMTP-new() will connect to port 25 by default?
If the SMTP port is provided as part of the hostname to Net::SMTP, it passes
the combined string to the SASL provider; this causes GSSAPI authentication to
fail since Kerberos does not want the port information. Instead, pass the
port
as a separate argument as is done for SSL connections.
I need to be in a (firewalled?) network that uses Kerberos to
reproduce this, right? Even if I can't reproduce it, the change seems
to be fine.
While we're on the subject, do you know how to get rid of this huge
ugly warning I get everytime I send emails?
***
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
together with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
***
at /home/artagnon/src/git/git-send-email line 1200.
Thanks.
--
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] send-email: provide port separately from hostname
On Fri, Jul 05, 2013 at 04:12:19AM +0530, Ramkumar Ramachandra wrote: Hm, so the problem occurs when you give smtp_host_string() to Net::SMTP-new() as the first argument. Yes. I created a test program, and Net::SMTP was fine as long as I used Port, but failed when I included the port in the hostname string. Arguably this is a bug in Net::SMTP. So if smtp_host_string() returns a hostname without a port, then Net::SMTP-new() will connect to port 25 by default? Correct. Port 25 is the default for Net::SMTP, so there's no change in behavior. I need to be in a (firewalled?) network that uses Kerberos to reproduce this, right? Even if I can't reproduce it, the change seems to be fine. You need to have access to a mail server that will only relay when authenticated, and only accepts GSSAPI. My personal server accepts GSSAPI always and PLAIN only when TLS is enabled, so I just turned off TLS temporarily to test. As for Kerberos, yes, you'd need to have it set up to reproduce this. While we're on the subject, do you know how to get rid of this huge ugly warning I get everytime I send emails? *** Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER together with SSL_ca_file|SSL_ca_path for verification. If you really don't want to verify the certificate and keep the connection open to Man-In-The-Middle attacks please set SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application. *** at /home/artagnon/src/git/git-send-email line 1200. You need to explicitly specify an SSL_verify_mode argument to start_SSL. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: unexpected file deletion after using git rebase --abort
On Thu, Jul 4, 2013 at 3:35 PM, Paul A. Kennedy paken...@pobox.com wrote: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index aca8405..ffaef29 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -238,6 +238,13 @@ leave out at most one of A and B, in which case it defaults to HEAD. will be reset to where it was when the rebase operation was started. + Untracked files added to the index will not be unstaged, and + therefore, not present in the working directory upon abort. + Unstage files before the abort, or stash untracked content before + starting the rebase (see linkgit:git-stash[1]). Dangling blobs + may be found and recovered using fsck and cat-file (see + linkgit:git-fsck[1], linkgit:git-cat-file[1]). + Not commenting about the change in general, just one issue: The transition to dangling blobs seems abrupt and may convey little meaning to non-expert users. Perhaps lead in to that sentence with something along the lines of: If you neglect to unstage untracked files before abort, they become dangling blogs, which may be found ... Also, a bit earlier, perhaps: s/Unstage files/Manually unstage files/ -- 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
