* Re: zealous git convert determined to set up git server
From: Sitaram Chamarty @ 2011-09-17 2:40 UTC (permalink / raw)
To: Andreas Krey; +Cc: Git List
In-Reply-To: <20110916204032.GA13922@inner.h.iocl.org>
On Sat, Sep 17, 2011 at 2:10 AM, Andreas Krey <a.krey@gmx.de> wrote:
> On Fri, 16 Sep 2011 22:30:35 +0000, Sitaram Chamarty wrote:
> ...
>> Well it *is* pretty darn powerful (I'm the author; allow me some
>> preening!) but I believe the real reason is that it is the most
>> *transparent* solution.
>
> It well looks so, but I have a question: It seems that it assumes a
> flat set of *.git repos. Unfortunately my current setup has the repos
No. Perhaps I should state that explicitly somewhere though...
^ permalink raw reply
* [RFC/PATCH] Configurable hyperlinking in gitk
From: Jeff Epler @ 2011-09-17 2:29 UTC (permalink / raw)
To: git
Many projects use project-specific notations in comments to refer to
bug trackers and the like. One example is the "Closes: #nnnnn"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
---
Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
useful. I made it configurable in the hopes that it might be adopted
upstream. (unfortunately, the configurable version is radically
different from the original hard-coded version, so I can't say this
has had much testing yet)
The definition of the allowed regular expression in the docs
probably needs some refinement. Basically, they have to also be REs
that can be concatenated with the "|" character, which is not true
of REs that begin with the *** flavor selector (which I had not
heard of before rereading `man re_syntax` just now) or (?xyz)
embedded options. Or maybe there's an efficient alternate approach
to scanning for the next non-overlapping match among several
patterns that doesn't involve concatenating the patterns.
I'm not sure about the "one line" restriction; at first I thought
that everything was fed to 'appendwithlinks' in arbitrary chunks,
but not I see that they are mostly logical chunks (and probably only
the comment, not the headers or commit descriptors, will have
anything to linkify). The problem again seems to be how to succinctly
describe what is permitted.
There are probably better names for the configuration options, too.
Suggestions? Problems? Successes?
Jeff
Documentation/config.txt | 31 ++++++++++++++++++-
gitk-git/gitk | 74 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 750c86d..67ed436 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1102,6 +1102,33 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and
is one of "ext" and "pserver") to make them apply only for the given
access method.
+gitk.linkify.<name>.re::
+ Specify a Tcl regular expression (which may not span lines)
+ defining a class of strings to automatically convert to hyperlinks.
+ You must also specify 'gitk.linkify.<name>.sub'.
+
+gitk.linkify.<name>.sub::
+ Specify a substitution that results in the target URL for the
+ related regular expression. Back-references like '\1' refer
+ to capturing groups in the associated regular expression.
+ You must also specify 'gitk.linkify.<name>.re'.
+
+gitk.browser::
+ Specify the browser that will be used to display the linked
+ web page.
+
+For example, to automatically link from Debian-style "Closes: #nnnn"
+message to the Debian BTS,
+
+--------
+ git config gitk.linkify.debian-bts.re 'Closes: #(\d+)'
+ git config gitk.linkify.debian-bts.sub 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'
+--------
+
+Regular expressions are as described in re_syntax(n). Replacements
+are as described in regsub(n). If multiple regular expressions match at
+the same location, it is undefined which match is used.
+
grep.lineNumber::
If set to true, enable '-n' option by default.
@@ -1901,5 +1928,5 @@ user.signingkey::
web.browser::
Specify a web browser that may be used by some commands.
- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
- may use it.
+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],
+ and linkgit:git-help[1] may use it.
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..a21eea1 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} {
# append some text to the ctext widget, and make any SHA1 ID
# that we know about be a clickable link.
proc appendwithlinks {text tags} {
- global ctext linknum curview
+ global ctext linknum curview linkmakers
set start [$ctext index "end - 1c"]
$ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} {
setlink $linkid link$linknum
incr linknum
}
+
+ if {$linkmakers == {}} return
+
+ set link_re {}
+ foreach {re rep} $linkmakers { lappend link_re $re }
+ set link_re "([join $link_re {)|(}])"
+
+ set ee 0
+ while {[regexp -indices -start $ee -- $link_re $text l]} {
+ set s [lindex $l 0]
+ set e [lindex $l 1]
+ set linktext [string range $text $s $e]
+ incr e
+ set ee $e
+
+ foreach {re rep} $linkmakers {
+ if {![regsub $re $linktext $rep linkurl]} continue
+ $ctext tag delete link$linknum
+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"
+ seturllink $linkurl link$linknum
+ incr linknum
+ break
+ }
+ }
}
proc setlink {id lk} {
@@ -6726,6 +6750,52 @@ proc setlink {id lk} {
}
}
+proc get_link_config {} {
+ if {[catch {exec git config -z --get-regexp {^gitk\.linkify\.}} linkers]} {
+ return {}
+ }
+
+ set linktypes [list]
+ foreach item [split $linkers "\0"] {
+ if {$item == ""} continue
+ if {![regexp {gitk\.linkify\.(\S+)\.(re|sub)\s(.*)} $item _ k t v]} {
+ continue
+ }
+ set linkconfig($t,$k) $v
+ if {$t == "re"} { lappend linktypes $k }
+ }
+
+ set linkmakers [list]
+ foreach k $linktypes {
+ if {![info exists linkconfig(sub,$k)]} {
+ puts stderr "Warning: link `$k' is missing a substitution string"
+ } elseif {[catch {regexp -inline -- $linkconfig(re,$k) ""} err]} {
+ puts stderr "Warning: link `$k': $err"
+ } else {
+ lappend linkmakers $linkconfig(re,$k) $linkconfig(sub,$k)
+ }
+ unset linkconfig(re,$k)
+ unset -nocomplain linkconfig(sub,$k)
+ }
+ foreach k [array names linkconfig] {
+ regexp "sub,(.*)" $k _ k
+ puts stderr "Warning: link `$k' is missing a regular expression"
+ }
+ set linkmakers
+}
+
+proc openlink {url} {
+ exec git web--browse --config=gitk.browser $url &
+}
+
+proc seturllink {url lk} {
+ global ctext
+ $ctext tag conf $lk -foreground blue -underline 1
+ $ctext tag bind $lk <1> [list openlink $url]
+ $ctext tag bind $lk <Enter> {linkcursor %W 1}
+ $ctext tag bind $lk <Leave> {linkcursor %W -1}
+}
+
proc appendshortlink {id {pre {}} {post {}}} {
global ctext linknum
@@ -11693,6 +11763,8 @@ if {[tk windowingsystem] eq "win32"} {
focus -force .
}
+set linkmakers [get_link_config]
+
getcommits {}
# Local variables:
--
1.7.0.4
^ permalink raw reply related
* Re: git branch --set-upstream regression in master
From: Jay Soffian @ 2011-09-17 0:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, conrad.irwin
In-Reply-To: <7vy5xocafg.fsf@alter.siamese.dyndns.org>
On Fri, Sep 16, 2011 at 7:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> This used to be possible on the checked out branch:
>>
>> $ git branch --set-upstream origin/master master
>>
>> Now it gives "fatal: Cannot force update the current branch."
>> broken.
>
> Let's do this. I would be happy if I can include it in -rc2 with Tested-by:
> or something ;-)
Tested-by: Jay Soffian
Thanks for the quick turnaround. I'll try to find some time to make
--set-upstream a proper option for post 1.7.7.
j.
^ permalink raw reply
* Re: git branch --set-upstream regression in master
From: Junio C Hamano @ 2011-09-16 23:52 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, conrad.irwin
In-Reply-To: <CAG+J_DyxNpPevwfrJVkv3GBmv0tEXgW2LZtdHgarFoXb9Qqghw@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> This used to be possible on the checked out branch:
>
> $ git branch --set-upstream origin/master master
>
> Now it gives "fatal: Cannot force update the current branch."
> broken.
Let's do this. I would be happy if I can include it in -rc2 with Tested-by:
or something ;-)
-- >8 --
Subject: [PATCH] branch --set-upstream: regression fix
The "git branch" command, while not in listing mode, calls create_branch()
even when the target branch already exists, and it does so even when it is
not interested in updating the value of the branch (i.e. the name of the
commit object that sits at the tip of the existing branch). This happens
when the command is run with "--set-upstream" option.
The earlier safety-measure to prevent "git branch -f $branch $commit" from
updating the currently checked out branch did not take it into account,
and we no longer can update the tracking information of the current branch.
Minimally fix this regression by telling the validation code if it is
called to really update the value of a potentially existing branch, or if
the caller merely is interested in updating auxiliary aspects of a branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 21 ++++++++++++---------
branch.h | 12 +++++++++++-
builtin/branch.c | 2 +-
builtin/checkout.c | 3 ++-
t/t3200-branch.sh | 13 +++++++++++++
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/branch.c b/branch.c
index 1fe3078..4338a90 100644
--- a/branch.c
+++ b/branch.c
@@ -135,23 +135,25 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return 0;
}
-int validate_new_branchname(const char *name, struct strbuf *ref, int force)
+int validate_new_branchname(const char *name, struct strbuf *ref,
+ int force, int attr_only)
{
- const char *head;
- unsigned char sha1[20];
-
if (strbuf_check_branch_ref(ref, name))
die("'%s' is not a valid branch name.", name);
if (!ref_exists(ref->buf))
return 0;
- else if (!force)
+ else if (!force && !attr_only)
die("A branch named '%s' already exists.", ref->buf + strlen("refs/heads/"));
- head = resolve_ref("HEAD", sha1, 0, NULL);
- if (!is_bare_repository() && head && !strcmp(head, ref->buf))
- die("Cannot force update the current branch.");
+ if (!attr_only) {
+ const char *head;
+ unsigned char sha1[20];
+ head = resolve_ref("HEAD", sha1, 0, NULL);
+ if (!is_bare_repository() && head && !strcmp(head, ref->buf))
+ die("Cannot force update the current branch.");
+ }
return 1;
}
@@ -171,7 +173,8 @@ void create_branch(const char *head,
if (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)
explicit_tracking = 1;
- if (validate_new_branchname(name, &ref, force || track == BRANCH_TRACK_OVERRIDE)) {
+ if (validate_new_branchname(name, &ref, force,
+ track == BRANCH_TRACK_OVERRIDE)) {
if (!force)
dont_change_ref = 1;
else
diff --git a/branch.h b/branch.h
index 01544e2..1285158 100644
--- a/branch.h
+++ b/branch.h
@@ -20,8 +20,18 @@ void create_branch(const char *head, const char *name, const char *start_name,
* interpreted ref in ref, force indicates whether (non-head) branches
* may be overwritten. A non-zero return value indicates that the force
* parameter was non-zero and the branch already exists.
+ *
+ * Contrary to all of the above, when attr_only is 1, the caller is
+ * not interested in verifying if it is Ok to update the named
+ * branch to point at a potentially different commit. It is merely
+ * asking if it is OK to change some attribute for the named branch
+ * (e.g. tracking upstream).
+ *
+ * NEEDSWORK: This needs to be split into two separate functions in the
+ * longer run for sanity.
+ *
*/
-int validate_new_branchname(const char *name, struct strbuf *ref, int force);
+int validate_new_branchname(const char *name, struct strbuf *ref, int force, int attr_only);
/*
* Remove information about the state of working on the current
diff --git a/builtin/branch.c b/builtin/branch.c
index 40f885c..5fb3d85 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -566,7 +566,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)
die(_("Invalid branch name: '%s'"), oldname);
}
- validate_new_branchname(newname, &newref, force);
+ validate_new_branchname(newname, &newref, force, 0);
strbuf_addf(&logmsg, "Branch: renamed %s to %s",
oldref.buf, newref.buf);
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ddefec0..909a334 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1072,7 +1072,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch) {
struct strbuf buf = STRBUF_INIT;
- opts.branch_exists = validate_new_branchname(opts.new_branch, &buf, !!opts.new_branch_force);
+ opts.branch_exists = validate_new_branchname(opts.new_branch, &buf,
+ !!opts.new_branch_force, 0);
strbuf_release(&buf);
}
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index cb6458d..7633930 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -554,4 +554,17 @@ test_expect_success 'attempt to delete a branch merged to its base' '
test_must_fail git branch -d my10
'
+test_expect_success 'use set-upstream on the current branch' '
+ git checkout master &&
+ git --bare init myupstream.git &&
+ git push myupstream.git master:refs/heads/frotz &&
+ git remote add origin myupstream.git &&
+ git fetch &&
+ git branch --set-upstream master origin/frotz &&
+
+ test "z$(git config branch.master.remote)" = "zorigin" &&
+ test "z$(git config branch.master.merge)" = "zrefs/heads/frotz"
+
+'
+
test_done
--
1.7.7.rc1.4.g26e426
^ permalink raw reply related
* Re: git branch --set-upstream regression in master
From: Junio C Hamano @ 2011-09-16 23:14 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, conrad.irwin
In-Reply-To: <7v7h58dri4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I took a brief look at --set-upstream codepath, and I have to say that the
> implementation is totally broken with respect to an existing branch.
>
> Given
>
> $ git branch master --set-upstream origin/master
>
> it passes the exact same codepath as
>
> $ git branch master origin/master
>
> uses, only with a different "track" flag, no? That is, it calls a
> function that is meant to _create_ branch "master" from given branch point
> "origin/master", namely create_branch(). And then create_branch(),
> contrary to its name, is littered with "dont_change_ref" special case to
> work it around, depending on the value of "track".
So here is a quick-and-dirty patch, which may or may not compile or pass
tests.
branch.c | 21 ++++++++++++---------
branch.h | 12 +++++++++++-
builtin/branch.c | 2 +-
builtin/checkout.c | 3 ++-
4 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/branch.c b/branch.c
index 478d825..fecedd3 100644
--- a/branch.c
+++ b/branch.c
@@ -135,23 +135,25 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return 0;
}
-int validate_new_branchname(const char *name, struct strbuf *ref, int force)
+int validate_new_branchname(const char *name, struct strbuf *ref,
+ int force, int attr_only)
{
- const char *head;
- unsigned char sha1[20];
-
if (strbuf_check_branch_ref(ref, name))
die("'%s' is not a valid branch name.", name);
if (!ref_exists(ref->buf))
return 0;
- else if (!force)
+ else if (!force && !attr_only)
die("A branch named '%s' already exists.", ref->buf + strlen("refs/heads/"));
- head = resolve_ref("HEAD", sha1, 0, NULL);
- if (!is_bare_repository() && head && !strcmp(head, ref->buf))
- die("Cannot force update the current branch.");
+ if (!attr_only) {
+ const char *head;
+ unsigned char sha1[20];
+ head = resolve_ref("HEAD", sha1, 0, NULL);
+ if (!is_bare_repository() && head && !strcmp(head, ref->buf))
+ die("Cannot force update the current branch.");
+ }
return 1;
}
@@ -171,7 +173,8 @@ void create_branch(const char *head,
if (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)
explicit_tracking = 1;
- if (validate_new_branchname(name, &ref, force || track == BRANCH_TRACK_OVERRIDE)) {
+ if (validate_new_branchname(name, &ref, force,
+ track == BRANCH_TRACK_OVERRIDE)) {
if (!force)
dont_change_ref = 1;
else
diff --git a/branch.h b/branch.h
index 01544e2..1285158 100644
--- a/branch.h
+++ b/branch.h
@@ -20,8 +20,18 @@ void create_branch(const char *head, const char *name, const char *start_name,
* interpreted ref in ref, force indicates whether (non-head) branches
* may be overwritten. A non-zero return value indicates that the force
* parameter was non-zero and the branch already exists.
+ *
+ * Contrary to all of the above, when attr_only is 1, the caller is
+ * not interested in verifying if it is Ok to update the named
+ * branch to point at a potentially different commit. It is merely
+ * asking if it is OK to change some attribute for the named branch
+ * (e.g. tracking upstream).
+ *
+ * NEEDSWORK: This needs to be split into two separate functions in the
+ * longer run for sanity.
+ *
*/
-int validate_new_branchname(const char *name, struct strbuf *ref, int force);
+int validate_new_branchname(const char *name, struct strbuf *ref, int force, int attr_only);
/*
* Remove information about the state of working on the current
diff --git a/builtin/branch.c b/builtin/branch.c
index aa705a0..f49596f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -566,7 +566,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)
die(_("Invalid branch name: '%s'"), oldname);
}
- validate_new_branchname(newname, &newref, force);
+ validate_new_branchname(newname, &newref, force, 0);
strbuf_addf(&logmsg, "Branch: renamed %s to %s",
oldref.buf, newref.buf);
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 3bb6525..5e356a6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1073,7 +1073,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch) {
struct strbuf buf = STRBUF_INIT;
- opts.branch_exists = validate_new_branchname(opts.new_branch, &buf, !!opts.new_branch_force);
+ opts.branch_exists = validate_new_branchname(opts.new_branch, &buf,
+ !!opts.new_branch_force, 0);
strbuf_release(&buf);
}
^ permalink raw reply related
* Re: git branch --set-upstream regression in master
From: Junio C Hamano @ 2011-09-16 22:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, conrad.irwin
In-Reply-To: <CAG+J_DyxNpPevwfrJVkv3GBmv0tEXgW2LZtdHgarFoXb9Qqghw@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> This used to be possible on the checked out branch:
>
> $ git branch master --set-upstream origin/master
>
> Now it gives "fatal: Cannot force update the current branch." which is
> broken. You should be able to setup/change the tracking information on
> the checked out branch.
>
> It's apparently due to ci/forbid-unwanted-current-branch-update.
Does
git branch --set-upstream master origin/master
work? If so then I wouldn't worry too much about it (your "arg then
option" should be forbidden in the longer term anyway). If not, we would
need to patch it.
> (BTW, --set-upstream still needs to be fixed so that these mean the same
> thing:
>
> $ git branch master --set-upstream origin/master
> $ git branch --set-upstream origin/master master
If we are doing anythning, I think it needs to be fixed not to allow the
former, period.
> .. to just allow:
>
> $ git branch --set-upstream origin/master
>
> w/o having to specify the checked-out branch.
That may be a nice feature enhancement, post 1.7.7 release.
I took a brief look at --set-upstream codepath, and I have to say that the
implementation is totally broken with respect to an existing branch.
Given
$ git branch master --set-upstream origin/master
it passes the exact same codepath as
$ git branch master origin/master
uses, only with a different "track" flag, no? That is, it calls a
function that is meant to _create_ branch "master" from given branch point
"origin/master", namely create_branch(). And then create_branch(),
contrary to its name, is littered with "dont_change_ref" special case to
work it around, depending on the value of "track".
^ permalink raw reply
* Re: zealous git convert determined to set up git server
From: Jakub Narebski @ 2011-09-16 22:39 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsTqtW=DD7zFwQLjknJR8g0nnh0WPUPna6_np4bVoGnSntQ@mail.gmail.com>
Joshua Stoutenburg wrote:
> 2011/9/15 Jakub Narebski <jnareb@gmail.com>:
> > I think that either "Pro Git" book, or "The Git Community Book"
> > would be a best source to learn about setting-up git server.
> >
> > I think the simplest solution for git hosting management would be to
> > use gitolite (there are other git repository management software:
> > Gitosis, SCM Manager, Gitblit).
> >
> > If you want to host something like GitHub, there are open source
> > solutions too: Gitorious, InDefero, Girocco + gitweb,...
> >
> > HTH
> > --
> > Jakub Narębski
> >
> >
>
> I totally didn't see "The Git Community Book". There's no link for it
> where I was looking: http://git-scm.com/documentation
I think that link to "Git Community Book" (http://book.git-scm.com) on Git
Documentation page (http://git-scm.com/documentation) got replaced by the
link to "Pro Git" book; I guess becaue the former is not finished and it
doesn't look like it would be finished soon.
[...]
> Question 2: It seems gitolite is the popular choice for git user
> management. Any reason why?
From Gitosis and Gitolite, both git repository management tools, Gitosis
requires setuptools beside Python, and looks like it is not developed
anymore, while Gitolite (which started as rewrite of Gitosis in Perl)
requires only Perl and is actively developed.
Nb. even Gitosis author recommends Gitolite:
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Update (12-12-2010): For additional features not present in gitosis,
check out gitolite.
> Question 3: So, Gitorious is more than just a repository hosting
> website? It's also an open source repository hosting platform, which
> powers the Gitorious website? That's pretty cool.
Yes, GitHub:FI (this one proprietary), Gitorious (powering gitorious.org),
InDefero, Gitblit and Girocco + gitweb (the last one powering http://repo.or.cz)
are all full-fledged git hosting sites, with web interface to view and
manage repositories.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] send-email: Honor multi-part email messages
From: Alexey Shumkin @ 2011-09-16 22:32 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin
"git format-patch --attach/--inline" generates multi-part messages.
Every part of such messages can contain non-ASCII characters with its own
"Content-Type" and "Content-Transfer-Encoding" headers.
But git-send-mail script interprets a patch-file as one-part message
and does not recognize multi-part messages.
So already quoted printable email subject may be encoded as quoted printable
again. Due to this bug email subject looks corrupted in email clients.
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
git-send-email.perl | 5 +++
t/t9001-send-email.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..1abf4a4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1403,12 +1403,17 @@ sub file_has_nonascii {
sub body_or_subject_has_nonascii {
my $fn = shift;
+ my $multipart = 0;
open(my $fh, '<', $fn)
or die "unable to open $fn: $!\n";
while (my $line = <$fh>) {
last if $line =~ /^$/;
+ if ($line =~ /^Content-Type:\s*multipart\/mixed.*$/) {
+ $multipart = 1;
+ }
return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
}
+ return 0 if $multipart;
while (my $line = <$fh>) {
return 1 if $line =~ /[^[:ascii:]]/;
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 579ddb7..151ad35 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1168,4 +1168,70 @@ test_expect_success $PREREQ '--force sends cover letter template anyway' '
test -n "$(ls msgtxt*)"
'
+test_expect_success $PREREQ 'setup multi-part message' '
+cat >multi-part-email-using-8bit <<EOF
+From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
+Message-Id: <bogus-message-id@example.com>
+From: author@example.com
+Date: Sat, 12 Jun 2010 15:53:58 +0200
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?=
+ =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+MIME-Version: 1.0
+Content-Type: multipart/mixed; boundary="------------123"
+
+This is a multi-part message in MIME format.
+--------------1.7.6.3.4.gf71f
+Content-Type: text/plain; charset=UTF-8; format=fixed
+Content-Transfer-Encoding: 8bit
+
+This is a message created with "git format-patch --attach=123"
+---
+ master | 1 +
+ файл | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 master
+ create mode 100644 файл
+
+
+--------------123
+Content-Type: text/x-patch; name="0001-.patch"
+Content-Transfer-Encoding: 8bit
+Content-Disposition: attachment; filename="0001-.patch"
+
+diff --git a/master b/master
+new file mode 100644
+index 0000000..1f7391f
+--- /dev/null
++++ b/master
+@@ -0,0 +1 @@
++master
+diff --git a/файл b/файл
+new file mode 100644
+index 0000000..44e5cfe
+--- /dev/null
++++ b/файл
+@@ -0,0 +1 @@
++содержимое файла
+
+--------------123--
+EOF
+'
+
+test_expect_success $PREREQ 'setup expect' '
+cat >expected <<EOF
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?= =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+EOF
+'
+
+test_expect_success $PREREQ '--attach/--inline also treats subject' '
+ clean_fake_sendmail &&
+ echo bogus |
+ git send-email --from=author@example.com --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --8bit-encoding=UTF-8 \
+ multi-part-email-using-8bit >stdout &&
+ grep "Subject" msgtxt1 >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.7.6.3.4.gf71f
^ permalink raw reply related
* Re: zealous git convert determined to set up git server
From: Ilari Liusvaara @ 2011-09-16 22:22 UTC (permalink / raw)
To: Andreas Krey; +Cc: Sitaram Chamarty, Git List
In-Reply-To: <20110916204032.GA13922@inner.h.iocl.org>
On Fri, Sep 16, 2011 at 10:40:32PM +0200, Andreas Krey wrote:
>
> It well looks so, but I have a question: It seems that it assumes a
> flat set of *.git repos. Unfortunately my current setup has the repos
> in a hierarchy, like area/sub/repo.git, and I don't want everyone to
> change their local repo configs. Is it possible to keep it like that
> (and consequently have 'repo area/sub/repo' lines) when putting it
> under gitolite control?
It is possible to have '/' in repository name in Gitolite. Heck,
most repos I have in Gitolite have '/' in their names...
-Ilari
^ permalink raw reply
* git branch --set-upstream regression in master
From: Jay Soffian @ 2011-09-16 21:43 UTC (permalink / raw)
To: git, Junio C Hamano, conrad.irwin
This used to be possible on the checked out branch:
$ git branch master --set-upstream origin/master
Now it gives "fatal: Cannot force update the current branch." which is
broken. You should be able to setup/change the tracking information on
the checked out branch.
It's apparently due to ci/forbid-unwanted-current-branch-update.
Sorry I don't have time to contribute a patch at the moment.
(BTW, --set-upstream still needs to be fixed so that these mean the same thing:
$ git branch master --set-upstream origin/master
$ git branch --set-upstream origin/master master
and to just allow:
$ git branch --set-upstream origin/master
w/o having to specify the checked-out branch.)
j.
^ permalink raw reply
* Re: [PATCH] Disambiguate duplicate t9160* tests
From: Frederic Heitzmann @ 2011-09-16 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, bjacobs, rchen
In-Reply-To: <7viposdwos.fsf@alter.siamese.dyndns.org>
Le 16/09/2011 23:06, Junio C Hamano a écrit :
> Junio C Hamano<gitster@pobox.com> writes:
>
>> Thanks.
>
> Heh, I spoke too early. It still refers to contents of t/t9160/ directory.
> We would need this squashed into your patch (no need to resend).
>
> t/t9161-git-svn-mergeinfo-push.sh | 2 +-
> t/{t9160 => t9161}/branches.dump | 0
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9161-git-svn-mergeinfo-push.sh b/t/t9161-git-svn-mergeinfo-push.sh
> index 216f3d7..6ef0c0b 100755
> --- a/t/t9161-git-svn-mergeinfo-push.sh
> +++ b/t/t9161-git-svn-mergeinfo-push.sh
> @@ -10,7 +10,7 @@ test_description='git-svn svn mergeinfo propagation'
>
> test_expect_success 'load svn dump' "
> svnadmin load -q '$rawsvnrepo' \
> - < '$TEST_DIRECTORY/t9160/branches.dump'&&
> + < '$TEST_DIRECTORY/t9161/branches.dump'&&
> git svn init --minimize-url -R svnmerge \
> -T trunk -b branches '$svnrepo'&&
> git svn fetch --all
> diff --git a/t/t9160/branches.dump b/t/t9161/branches.dump
> similarity index 100%
> rename from t/t9160/branches.dump
> rename to t/t9161/branches.dump
Ooops ! I checked 'make test', but missed the most obvious change.
Sorry for this.
--
Fred
^ permalink raw reply
* Re: [PATCH v3] git svn dcommit: new option --interactive.
From: Junio C Hamano @ 2011-09-16 21:08 UTC (permalink / raw)
To: Frédéric Heitzmann; +Cc: git, normalperson
In-Reply-To: <1316206921-29311-1-git-send-email-frederic.heitzmann@gmail.com>
I am not accepting any new features at this point in the release cycle, so
please do not Cc me unless it is a patch to fix regression or minor
documentation.
Thanks.
^ permalink raw reply
* Re: [PATCH] Disambiguate duplicate t9160* tests
From: Junio C Hamano @ 2011-09-16 21:06 UTC (permalink / raw)
To: Frédéric Heitzmann; +Cc: git, bjacobs, rchen
In-Reply-To: <7vty8cdxun.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks.
Heh, I spoke too early. It still refers to contents of t/t9160/ directory.
We would need this squashed into your patch (no need to resend).
t/t9161-git-svn-mergeinfo-push.sh | 2 +-
t/{t9160 => t9161}/branches.dump | 0
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9161-git-svn-mergeinfo-push.sh b/t/t9161-git-svn-mergeinfo-push.sh
index 216f3d7..6ef0c0b 100755
--- a/t/t9161-git-svn-mergeinfo-push.sh
+++ b/t/t9161-git-svn-mergeinfo-push.sh
@@ -10,7 +10,7 @@ test_description='git-svn svn mergeinfo propagation'
test_expect_success 'load svn dump' "
svnadmin load -q '$rawsvnrepo' \
- < '$TEST_DIRECTORY/t9160/branches.dump' &&
+ < '$TEST_DIRECTORY/t9161/branches.dump' &&
git svn init --minimize-url -R svnmerge \
-T trunk -b branches '$svnrepo' &&
git svn fetch --all
diff --git a/t/t9160/branches.dump b/t/t9161/branches.dump
similarity index 100%
rename from t/t9160/branches.dump
rename to t/t9161/branches.dump
^ permalink raw reply related
* [PATCH v3] git svn dcommit: new option --interactive.
From: Frédéric Heitzmann @ 2011-09-16 21:02 UTC (permalink / raw)
To: gitster; +Cc: git, normalperson, Frédéric Heitzmann
Allow the user to check the patch set before it is commited to SNV. It is
then possible to accept/discard one patch, accept all, or quit.
This interactive mode is similar with 'git send email' behaviour. However,
'git svn dcommit' returns as soon as one patch is discarded.
Part of the code was taken from git-send-email.perl (see 'ask' function)
Tests several combinations of potential answers to
'git svn dcommit --interactive'. For each of them, test whether patches
were commited to SVN or not.
Thanks-to Eric Wong <normalperson@yhbt.net> for the initial idea.
Reviewed-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
---
Minor change from v2 : rename t9160... to t9162... to avoid name
collision
ref: <1316202903-5085-1-git-send-email-frederic.heitzmann@gmail.com>
Documentation/git-svn.txt | 8 +++
git-svn.perl | 76 +++++++++++++++++++++++++++++++-
t/t9162-git-svn-dcommit-interactive.sh | 64 +++++++++++++++++++++++++++
3 files changed, 147 insertions(+), 1 deletions(-)
create mode 100644 t/t9162-git-svn-dcommit-interactive.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 08cad6d..c8f0883 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -234,6 +234,14 @@ svn:mergeinfo property in the SVN repository when possible. Currently, this can
only be done when dcommitting non-fast-forward merges where all parents but the
first have already been pushed into SVN.
+--interactive;;
+ Ask the user to confirm that a patch set should actually be sent to SVN.
+ For each patch, one may answer "yes" (accept this patch), "no" (discard this
+ patch), "all" (accept all patches), or "quit".
+ +
+ 'git svn dcommit' returns immediately if answer if "no" or "quit", without
+ commiting anything to SVN.
+
'branch'::
Create a branch in the SVN repository.
diff --git a/git-svn.perl b/git-svn.perl
index 351e743..121332d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -87,7 +87,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag, $_merge_info);
+ $_git_format, $_commit_url, $_tag, $_merge_info, $_interactive);
$Git::SVN::_follow_parent = 1;
$SVN::Git::Fetcher::_placeholder_filename = ".gitignore";
$_q ||= 0;
@@ -163,6 +163,7 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
'mergeinfo=s' => \$_merge_info,
+ 'interactive|i' => \$_interactive,
%cmt_opts, %fc_opts } ],
branch => [ \&cmd_branch,
'Create a branch in the SVN repository',
@@ -256,6 +257,27 @@ my %cmd = (
{} ],
);
+use Term::ReadLine;
+package FakeTerm;
+sub new {
+ my ($class, $reason) = @_;
+ return bless \$reason, shift;
+}
+sub readline {
+ my $self = shift;
+ die "Cannot use readline on FakeTerm: $$self";
+}
+package main;
+
+my $term = eval {
+ $ENV{"GIT_SVN_NOTTY"}
+ ? new Term::ReadLine 'git-svn', \*STDIN, \*STDOUT
+ : new Term::ReadLine 'git-svn';
+};
+if ($@) {
+ $term = new FakeTerm "$@: going non-interactive";
+}
+
my $cmd;
for (my $i = 0; $i < @ARGV; $i++) {
if (defined $cmd{$ARGV[$i]}) {
@@ -366,6 +388,36 @@ sub version {
exit 0;
}
+sub ask {
+ my ($prompt, %arg) = @_;
+ my $valid_re = $arg{valid_re};
+ my $default = $arg{default};
+ my $resp;
+ my $i = 0;
+
+ if ( !( defined($term->IN)
+ && defined( fileno($term->IN) )
+ && defined( $term->OUT )
+ && defined( fileno($term->OUT) ) ) ){
+ return defined($default) ? $default : undef;
+ }
+
+ while ($i++ < 10) {
+ $resp = $term->readline($prompt);
+ if (!defined $resp) { # EOF
+ print "\n";
+ return defined $default ? $default : undef;
+ }
+ if ($resp eq '' and defined $default) {
+ return $default;
+ }
+ if (!defined $valid_re or $resp =~ /$valid_re/) {
+ return $resp;
+ }
+ }
+ return undef;
+}
+
sub do_git_init_db {
unless (-d $ENV{GIT_DIR}) {
my @init_db = ('init');
@@ -746,6 +798,28 @@ sub cmd_dcommit {
"If these changes depend on each other, re-running ",
"without --no-rebase may be required."
}
+
+ if (defined $_interactive){
+ my $ask_default = "y";
+ foreach my $d (@$linear_refs){
+ print "debug : d = $d\n";
+ my ($fh, $ctx) = command_output_pipe(qw(show --summary), "$d");
+ while (<$fh>){
+ print $_;
+ }
+ command_close_pipe($fh, $ctx);
+ $_ = ask("Commit this patch to SVN? ([y]es (default)|[n]o|[q]uit|[a]ll): ",
+ valid_re => qr/^(?:yes|y|no|n|quit|q|all|a)/i,
+ default => $ask_default);
+ die "Commit this patch reply required" unless defined $_;
+ if (/^[nq]/i) {
+ exit(0);
+ } elsif (/^a/i) {
+ last;
+ }
+ }
+ }
+
my $expect_url = $url;
my $push_merge_info = eval {
diff --git a/t/t9162-git-svn-dcommit-interactive.sh b/t/t9162-git-svn-dcommit-interactive.sh
new file mode 100644
index 0000000..e38d9fa
--- /dev/null
+++ b/t/t9162-git-svn-dcommit-interactive.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Frédéric Heitzmann
+
+test_description='git svn dcommit --interactive series'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ svn_cmd mkdir -m"mkdir test-interactive" "$svnrepo/test-interactive" &&
+ git svn clone "$svnrepo/test-interactive" test-interactive &&
+ cd test-interactive &&
+ touch foo && git add foo && git commit -m"foo: first commit" &&
+ git svn dcommit
+ '
+
+test_expect_success 'answers: y [\n] yes' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "y
+
+y" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn)
+ )
+ '
+
+test_expect_success 'answers: yes yes no' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+yes
+no" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: yes quit' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+quit" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: all' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "all" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_done
--
1.7.7.rc0.200.g2f9e2e
^ permalink raw reply related
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Junio C Hamano @ 2011-09-16 20:53 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <CAGdFq_jc4YDaD+NL6_+buCrOt2yAK+-_MDOJQU5qnS13P65CzQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> ... Should we have some way to queue patches like
> this, or would someone have to resend after the appropriate release?
For this particular case, I do not think it is worth _my_ time to keep
maintaining that patch.
It is understandable that a new person will be hurt if
$ git ls-remote -h
does not give a short-help message and instead try to contact and show the
origin repository which may not even exist, and that is why I sent a fix.
But would anybody gets hurt if
$ git ls-remote -h origin
$ git ls-remote -h git://git.kernel.org/pub/git/git.git
kept working as they do today, given that we do not advertise -h as
a synonym in "git ls-remote -h" output?
That is why I said "I am not opposed to", and not "I'd volunteer to do
that". It's not worth my time, but since you brought it up, you may care
more about it.
^ permalink raw reply
* Re: [PATCH/RFC] bash: add --word-diff option to diff [AND --set-upstream TO push] auto-completion
From: Jonathan Nieder @ 2011-09-16 20:47 UTC (permalink / raw)
To: Rodrigo Rosenfeld Rosas; +Cc: SZEDER Gábor, Thomas Rast, git
In-Reply-To: <4E737199.1000107@yahoo.com.br>
Rodrigo Rosenfeld Rosas wrote:
> While on the topic, it would also be interesting to add "--set-upstream" to
> "git push" autocompletion. Don't you agree?
Yes, of course.
^ permalink raw reply
* Re: [PATCH] Disambiguate duplicate t9160* tests
From: Junio C Hamano @ 2011-09-16 20:41 UTC (permalink / raw)
To: Frédéric Heitzmann; +Cc: git, bjacobs, rchen
In-Reply-To: <1316202903-5085-1-git-send-email-frederic.heitzmann@gmail.com>
Thanks.
^ permalink raw reply
* Re: zealous git convert determined to set up git server
From: Andreas Krey @ 2011-09-16 20:40 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git List
In-Reply-To: <CAMK1S_jK2w8v4ushsZztQ0QY-eZq8axso-DpmCCvA=Gp7iXkBg@mail.gmail.com>
On Fri, 16 Sep 2011 22:30:35 +0000, Sitaram Chamarty wrote:
...
> Well it *is* pretty darn powerful (I'm the author; allow me some
> preening!) but I believe the real reason is that it is the most
> *transparent* solution.
It well looks so, but I have a question: It seems that it assumes a
flat set of *.git repos. Unfortunately my current setup has the repos
in a hierarchy, like area/sub/repo.git, and I don't want everyone to
change their local repo configs. Is it possible to keep it like that
(and consequently have 'repo area/sub/repo' lines) when putting it
under gitolite control?
Andreas
^ permalink raw reply
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Sverre Rabbelier @ 2011-09-16 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uvgfcur.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Sep 16, 2011 at 22:31, Junio C Hamano <gitster@pobox.com> wrote:
> I am not opposed to. We should do the usual "start from warning and then
> deprecate" dance, but I do not think we would want to have a "I want the
> old behaviour, please keep it" configuration, especially if we are talking
> about a big version bump like 2.0.
>
> The first step would look something like this, on top of the previous
> patch.
Makes sense.
I remember some sort of "this is for post 1.7.x" section in what's
cooking at some point. Should we have some way to queue patches like
this, or would someone have to resend after the appropriate release?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Junio C Hamano @ 2011-09-16 20:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <CAGdFq_hug3zNwvDZ3c8iG-F8jJSuxsuFghMWtWTmUTdfTrWiqg@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Fri, Sep 16, 2011 at 21:35, Junio C Hamano <gitster@pobox.com> wrote:
>> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>> Should we really have "-h" as a short for anything other than "--help"
>>> in the first place?
> ...
> Does git 2.0 count?
I am not opposed to. We should do the usual "start from warning and then
deprecate" dance, but I do not think we would want to have a "I want the
old behaviour, please keep it" configuration, especially if we are talking
about a big version bump like 2.0.
The first step would look something like this, on top of the previous
patch.
builtin/ls-remote.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 41c88a9..dabe21e 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -28,6 +28,12 @@ static int tail_match(const char **pattern, const char *path)
return 0;
}
+static void warn_h_deprecation(void)
+{
+ warning("Using -h as synonym for --heads is deprecated");
+ warning("and will be removed in future versions of Git.");
+}
+
int cmd_ls_remote(int argc, const char **argv, const char *prefix)
{
int i;
@@ -64,6 +70,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
}
if (!strcmp("--heads", arg) || !strcmp("-h", arg)) {
flags |= REF_HEADS;
+ if (!arg[2])
+ warn_h_deprecation();
continue;
}
if (!strcmp("--refs", arg)) {
^ permalink raw reply related
* Re: [PATCH] gitweb: Strip non-printable characters from syntax highlighter output
From: Junio C Hamano @ 2011-09-16 20:24 UTC (permalink / raw)
To: Jakub Narebski
Cc: Christopher M. Fuhrman, git, Christopher Wilson, Sylvain Rabot
In-Reply-To: <201109162058.51132.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> So actually now I see that while this line is good to have in esc_html(),
> it is not really necessary in sanitize().
>
> But anyway we don't want to replace undef with an empty string; undef is
> (usually) an error, and we want to catch it, not to hide it.
Heh, get off your high horse---whoever wrote such a caller that calls the
subroutine and uses its result without checking it against undef is not
qualified to make such a statement. I do not think letting "perl -w"
notice and complain about an attempt to concatenate undef with string
counts as "catching" it.
^ permalink raw reply
* Re: [PATCH] mergetool: Use args as pathspec to unmerged files
From: Junio C Hamano @ 2011-09-16 20:17 UTC (permalink / raw)
To: Jonathon Mah; +Cc: git, Dan McGee, David Aguilar
In-Reply-To: <C5AD8BFC-DA48-4CE9-B821-D0076825F33C@JonathonMah.com>
Jonathon Mah <me@JonathonMah.com> writes:
> Mergetool now treats its path arguments as a pathspec (like other git
> subcommands), restricting action to the given files and directories.
> Files matching the pathspec are filtered so mergetool only acts on
> unmerged paths; previously it would assume each path argument was in an
> unresolved state, and get confused when it couldn't check out their
> other stages.
>
> Running "git mergetool subdir" will prompt to resolve all conflicted
> blobs under subdir.
>
> Signed-off-by: Jonathon Mah <me@JonathonMah.com>
It looks like this simplifies the code quote a bit and make the result
easier to follow ;-) Nicely done.
As nobody reads from a pipe in while loop and runs merge_file or prompt
inside, there no longer is a reason to redirect the original standard
input and make it available, hence we could perhaps add this patch on top
of your change.
Ack from mergetool/difftool folks?
Thanks.
git-mergetool.sh | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 83551c7..0a06bde 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -362,20 +362,18 @@ if test -z "$files" ; then
exit 0
fi
-# Save original stdin
-exec 3<&0
-
printf "Merging:\n"
printf "$files\n"
IFS='
-'; for i in $files
+'
+for i in $files
do
if test $last_status -ne 0; then
- prompt_after_failed_merge <&3 || exit 1
+ prompt_after_failed_merge || exit 1
fi
printf "\n"
- merge_file "$i" <&3
+ merge_file "$i"
last_status=$?
if test $last_status -ne 0; then
rollup_status=1
^ permalink raw reply related
* [PATCH] Disambiguate duplicate t9160* tests
From: Frédéric Heitzmann @ 2011-09-16 19:55 UTC (permalink / raw)
To: git; +Cc: gitster, bjacobs, rchen, Frédéric Heitzmann
1e5814f created t9160-git-svn-mergeinfo-push.sh on 11/9/7
40a1530 createds t9160-git-svn-preserve-empty-dirs.sh on 11/7/20
The former test script is renumbered to t9161.
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
---
I did not find any explicit objection in t/README but it looks odd.
...nfo-push.sh => t9161-git-svn-mergeinfo-push.sh} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t9160-git-svn-mergeinfo-push.sh => t9161-git-svn-mergeinfo-push.sh} (100%)
diff --git a/t/t9160-git-svn-mergeinfo-push.sh b/t/t9161-git-svn-mergeinfo-push.sh
similarity index 100%
rename from t/t9160-git-svn-mergeinfo-push.sh
rename to t/t9161-git-svn-mergeinfo-push.sh
--
1.7.7.rc0.200.g2f9e2e
^ permalink raw reply
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Sverre Rabbelier @ 2011-09-16 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehzgfffw.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Sep 16, 2011 at 21:35, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>> Should we really have "-h" as a short for anything other than "--help"
>> in the first place?
>
> You have been here long enough to know the answer to that question, no?
Yeah, you're right :).
> The answer would be different if you are starting a new project from
> scratch and if you are talking about a project with existing userbase.
Does git 2.0 count?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Junio C Hamano @ 2011-09-16 19:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <CAGdFq_h474OrLzP+CHj_eSdSp53n8x7jz1ORT16dOhvRdQMP+g@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Should we really have "-h" as a short for anything other than "--help"
> in the first place?
You have been here long enough to know the answer to that question, no?
The answer would be different if you are starting a new project from
scratch and if you are talking about a project with existing userbase.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox