* Re: OS X and umlauts in file names
From: Martin Langhoff @ 2009-11-25 10:19 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <46a038f90911250207o214b3952s67a022a017dbe2d9@mail.gmail.com>
On Wed, Nov 25, 2009 at 11:07 AM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 9:50 AM, Thomas Singer
> <thomas.singer@syntevo.com> wrote:
>> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
>> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
>
> does a find * | xargs git add work?
Also, you can try with `find * -print0 | git-update-index --add
--stdin -z `. Find should report the exact filename that the OS has,
and git should add it as it is.
Background: git-add used to be a trivial shell script wrapping around
git-update-index. If you have a git checkout, try:
git show f25933987f29070e9cd79dfddf03018010e82e80:git-add.sh
If git cannot track this file in a pure OSX world, there is a good
chance it's a bug in git.
In in this narrow test case (single machine, running OSX) git *must*
be able to do the right thing. If you work on multi-platform projects
however, there is a good chance a Windows or Linux user will commit a
file with a name that _when you checkout on OSX_, OSX will save with a
different (but "equivalent") name due to its funny decomposition
rules. And all sorts of "fun" will ensue.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: git send-email --notmuch expr
From: Jakub Narebski @ 2009-11-25 10:16 UTC (permalink / raw)
To: Jed Brown; +Cc: git, Pierre Habouzit
In-Reply-To: <87d4375ne0.fsf@59A2.org>
Jed Brown <jed@59A2.org> writes:
> } elsif (/^(?:To|Cc|Bcc):/i) {
> print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
> next;
> }
>
> This regex doesn't match these headers (is the leading ?: a typo?) so
> there is no warning.
(?: ... ) is in Perl non-capturing grouping
>From perlre(1)
"(?:pattern)"
"(?imsx-imsx:pattern)"
This is for clustering, not capturing; it groups subexpressions
like "()", but doesn't make backreferences as "()" does.
So it is not a bug, and it definitely should match... unless implicit
variable $_ (the default input and pattern-searching space) got
mangled. It would be better to use explicit form:
$variable =~ /pattern/
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What is the best way to synchronize two *bare* repositories with each other?
From: Alex Riesen @ 2009-11-25 10:14 UTC (permalink / raw)
To: Liebich, Wolfgang; +Cc: git@vger.kernel.org
In-Reply-To: <7FF082147E322048955113B6CB87A7C0081731C659@MCHP058A.global-ad.net>
On Tue, Nov 24, 2009 at 22:19, Liebich, Wolfgang
<wolfgang.liebich@siemens-enterprise.com> wrote:
> Hi,
> Let's say I have two bare git repositories, bareA and bareB.
> I also have a third non-bare repo, lets call it workA. Coworkers also have their working repositories, they all
> synchronize back to repoA.
> My work repo can only synchronize directly with repoB.
> What is the best way to keep repoA and repoB synchronized to each other?
Take a look at "--mirror" option of "git clone" (it sets up a remote
with references
mapping like this: refs/*:refs/*).
^ permalink raw reply
* Re: Git repository mesh?
From: Alex Riesen @ 2009-11-25 10:08 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0911242007t1294bddej87b48691ea283e21@mail.gmail.com>
On Wed, Nov 25, 2009 at 05:07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I work on a few machines so I have repositories on all of them. One
> repository can pull from or push to any other repositories (in case of
> push, it pushes on remote branches). I avoid a central repository
> because it's quite inconvenient when you just need to push some
> changes to a machine, you have to push it to the central repository
> then pull from that (and if the central repository is on WAN, double
> inconvenient). Maybe this model is just plain wrong, but it'd be fun
> to see if Git can work with this model.
You can always use fetch (and pull) without specifying a remote:
$ git fetch host:/path/repo some-branch
$ git log ..FETCH_HEAD # git merge FETCH_HEAD
Maybe fetch should be extended to record this operation in .git/config?
$ git fetch ---save=host-some host:/path/repo some-branch some-branch
$ git remote -v
...
host-some host:/path/repo (fetch)
$
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Martin Langhoff @ 2009-11-25 10:07 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0CEFCA.5020605@syntevo.com>
On Wed, Nov 25, 2009 at 9:50 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
does a find * | xargs git add work?
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: OS X and umlauts in file names
From: B Smith-Mannschott @ 2009-11-25 9:51 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0CEFCA.5020605@syntevo.com>
On Wed, Nov 25, 2009 at 09:50, Thomas Singer <thomas.singer@syntevo.com> wrote:
> I've did following:
>
> toms-mac-mini:git-umlauts tom$ ls
> Überlänge.txt
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
>
> Note, that I copy-pasted the file name which 'git status' showed to the
> stage command. IMHO, this should work, especially, because different people
> said Git would treat the file name as byte-array without interpreting it in
> some kind.
>
> From the user with the German OS X (for which the staging is said to work),
> I've got the output of 'env' and hence also tried
>
> export LANG=de_DE.UTF-8
>
> before doing the above steps, but with the same results. :(
The problem you are having is not because of the *encoding*, it's the
Normalization form that's messing things up. The fact is that in
Unicode there are two ways to represent many -- but not all --
accented characters.
- "composed": one code point for the accented character)
- "decomposed": two code points: one for the base letter, one or more
combining characters for the accents.
The composed code points are really just backward compatibility to
legacy encodings (like LATIN-1). If you want to actually support
(rather than just tolerate) unicode you have to know how to deal with
the decomposed form, and once you can do that there's little point
beyond backward compatibility in continuing to use composed form
internally.
The Subversion people have run into this same problem because they
made the same error of assuming that any given sequence of glyphs has
only one possible representation as unicode code points and thus only
one representation as UTF-8 bytes. Dionisos has done written up the
issues involved here:
http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames
// Ben
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-25 8:50 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0911231403100.14365@iabervon.org>
I've did following:
toms-mac-mini:git-umlauts tom$ ls
Überlänge.txt
toms-mac-mini:git-umlauts tom$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: "U\314\210berla\314\210nge.txt"
#
toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
Note, that I copy-pasted the file name which 'git status' showed to the
stage command. IMHO, this should work, especially, because different people
said Git would treat the file name as byte-array without interpreting it in
some kind.
From the user with the German OS X (for which the staging is said to work),
I've got the output of 'env' and hence also tried
export LANG=de_DE.UTF-8
before doing the above steps, but with the same results. :(
--
Tom
Daniel Barkalow wrote:
> On Mon, 23 Nov 2009, Thomas Singer wrote:
>
>> I'm on an English OS X 10.6.2 and I created a sample file with umlauts in
>> its name (Überlänge.txt). When I try to stage the file in the terminal, I
>> can't complete the file name by typing the Ü and hitting the tab key, but I
>> can complete it by typing an U and hitting the tab key.
>
> You've already got a bug before involving git at all. You create a
> file "Überlänge.txt", but OS X writes "U:berla:nge.txt" (typing the
> combining character umlaut as : so that you can see the difference), and
> the directory listing doesn't contain any files that start with Ü, so the
> terminal already can't find the file you created. Obviously, git is going
> to have all the problems that the OS-provided readline library has, and
> you're not going to be able to get predictable results in any case where
> user-supplied filenames are compared with directory listings.
>
> Part of the problem is that OS X does a canonicalization that is not what
> anybody else does, so you hit the problem every single time, but the
> fundamental issue is that there isn't any way to tell, when you create a
> file, what name that file will be listed under.
>
> Note that this isn't a matter of characters to byte sequences. OS X
> actually uses different characters for the filename in its listings than
> you've used.
>
> If there's a difference between German and English versions, I suspect
> that it's actually that you're not using a German keyboard with a key
> that, under OS X, produces the two-character sequence U:, but using some
> method that produces the single character Ü. I'd guess that your SmartGit
> problem is that Java is converting the U: that the user typed into Ü, and
> passing it to the OS, which turns it back into U: and then doesn't list
> the file that Java thinks the user asked for.
>
> -Daniel
> *This .sig left intentionally blank*
^ permalink raw reply
* Re: Git repository mesh?
From: Sergio @ 2009-11-25 8:42 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0911242007t1294bddej87b48691ea283e21@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
> Hi,
>
> I work on a few machines so I have repositories on all of them. One
> repository can pull from or push to any other repositories (in case of
> push, it pushes on remote branches). I avoid a central repository
> because it's quite inconvenient when you just need to push some
> changes to a machine, you have to push it to the central repository
> then pull from that (and if the central repository is on WAN, double
> inconvenient). Maybe this model is just plain wrong, but it'd be fun
> to see if Git can work with this model.
>
> The first thing that annoys me is remote repository management.
> Everytime I add a new repository to the mesh, I need to update .config
> of all repositories.
If I remember correctly, there was in the past the idea of allowing some limited
shell variable substitution in the config file.
This would allow to have a single config for all the machines with remote
entries. Something like
[remote "host1"]
url = ssh://host1/path
fetch = +refs/heads/*:refs/remotes/host1/*
push = +refs/heads/*:refs/remotes/$hostname/*
[remote "host2"]
url = ssh://host2/path
fetch = +refs/heads/*:refs/remotes/host2/*
push = +refs/heads/*:refs/remotes/$hostname/*
...
In other terms, admitting that all the candidate machines are known at the very
start, you could start a repo on any of the host, placing in the config file all
the possible hosts. Moreover, not needing to have a different config for each
host may make it easier to manage (propagate by simple scp) or even to version
control.
To the best of my knowledge the idea was not implemented in the end, but I think
that a patch for variable substitution in the config file might still be found
on the ML.
Sergio
^ permalink raw reply
* [PATCH] git-am: don't ignore --keep (-k) option
From: Jim Meyering @ 2009-11-25 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vmy2b76ji.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jim Meyering <meyering@redhat.com> writes:
>> Before this change, a [...] prefix would be removed only as long as
>> its length did not exceed 2/3 of the subject length. Now, when the
>> bracketed quantity starts with PATCH, it is removed unconditionally.
>> Otherwise, the existing behavior remains unchanged.
>
> Thanks, I think this is a good idea in general, but have two comments.
>
> - I am not sure how this should play with 17635fc (mailinfo: -b option
> keeps [bracketed] strings that is not a [PATCH] marker, 2009-07-15).
Ah ha! I see you've already scratched this itch,
and more thoroughly, to boot. Also, I prefer your
removal of the hard-to-describe 2/3 threshold.
> - Regardless of interaction with 17635fc, Things like [RFC PATCH]
> [SECURITY PATCH] might want a similar treatment.
As your patch does.
I started looking at git-am.sh and spotted what appears to be a typo.
There is only that one use of $keep_subject, so its value currently
comes from the environment.
>From 02f7e6433b5db8b18a4cccf58c302159c2f54fa5 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Wed, 25 Nov 2009 09:10:46 +0100
Subject: [PATCH] git-am: don't ignore --keep (-k) option
Fix typo in variable name: s/keep_subject/keep/.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 151512a..f353e73 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -578,7 +578,7 @@ do
sed -e '1,/^$/d' >"$dotest/msg-clean"
else
SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
- case "$keep_subject" in -k) SUBJECT="[PATCH] $SUBJECT" ;; esac
+ case "$keep" in -k) SUBJECT="[PATCH] $SUBJECT" ;; esac
(printf '%s\n\n' "$SUBJECT"; cat "$dotest/msg") |
git stripspace > "$dotest/msg-clean"
--
1.6.6.rc0.236.ge0b94
^ permalink raw reply related
* Re: Git repository mesh?
From: Nguyen Thai Ngoc Duy @ 2009-11-25 8:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Git Mailing List
In-Reply-To: <vpqaaybf37f.fsf@bauges.imag.fr>
On Wed, Nov 25, 2009 at 2:55 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> Never used Mercurial but the idea of "git in" and "git out" to see how
>> many commits ahead/behind would be nice.
>
> In Git, you'd run "git fetch" to get everything locally, and then
>
> git log ..origin/master => what origin/master has that you don't
> git log origin/master.. => what you have that origin/master doesn't
>
> (and you can define aliases for that)
But I have many origins (any repository could be origin). "git status"
also have this kind of information, but only for "origin".
--
Duy
^ permalink raw reply
* Re: Git repository mesh?
From: Matthieu Moy @ 2009-11-25 7:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0911242007t1294bddej87b48691ea283e21@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Never used Mercurial but the idea of "git in" and "git out" to see how
> many commits ahead/behind would be nice.
In Git, you'd run "git fetch" to get everything locally, and then
git log ..origin/master => what origin/master has that you don't
git log origin/master.. => what you have that origin/master doesn't
(and you can define aliases for that)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Private remote repo setup
From: Johannes Sixt @ 2009-11-25 6:37 UTC (permalink / raw)
To: Derek D; +Cc: git
In-Reply-To: <loom.20091124T195818-835@post.gmane.org>
Derek D schrieb:
> Hi all, I am new to Git and I am getting quite frustrated with setting a repo
> on my server so that people with Windows machines can ssh to it and contribute.
>
> This is what I am doing:
> On the server:
> #git --bare init
^
This looks like you were root when you ran the command.
> Initialized empty Git repository in /opt/apps/git-test/
>
> In tortoiseGIT I go to git clone, provide correct url:
> ssh://user@domain/opt/apps/git-test/
> tortoiseGIT asks me for a password, I provide it, it's correct, the repository
> gets created on the local machine and...
>
> fatal: '/opt/apps/git-test': unable to chdir or not a git archive
> Initialized empty Git repository in C:/path/.git/
> fatal: The remote end hung up unexpectedly
> Failed
>
> What happened there?
I guess that user does not have sufficient permissions to peek inside
/opt/apps/git-test.
-- Hannes
^ permalink raw reply
* Git repository mesh?
From: Nguyen Thai Ngoc Duy @ 2009-11-25 4:07 UTC (permalink / raw)
To: Git Mailing List
Hi,
I work on a few machines so I have repositories on all of them. One
repository can pull from or push to any other repositories (in case of
push, it pushes on remote branches). I avoid a central repository
because it's quite inconvenient when you just need to push some
changes to a machine, you have to push it to the central repository
then pull from that (and if the central repository is on WAN, double
inconvenient). Maybe this model is just plain wrong, but it'd be fun
to see if Git can work with this model.
The first thing that annoys me is remote repository management.
Everytime I add a new repository to the mesh, I need to update .config
of all repositories. Putting part of $GIT_DIR/config into working
directory may help (though there will be security concerns, perhaps
only remote.* should be allowed in in-tree config file). Next thing is
sometimes I want to see how many commits ahead/behind other
repositories, from a repository. "git status" does not help much.
Never used Mercurial but the idea of "git in" and "git out" to see how
many commits ahead/behind would be nice.
Has anyone done something like this? Any suggestions?
--
Duy
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Stephen Boyd @ 2009-11-25 4:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200911250145.16472.jnareb@gmail.com>
Jakub Narebski wrote:
>
> Debugging this is serious PITA. After fix below it appears that this bug
> is some intermittent bug, depending on XMLHttpRequest timing. It more
> often than not (at least when I tried to debug it using build-in IE8
> debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,
> revision.c (once even it did fail when first running for given file, and
> then running correctly when reloading from debugger; fun it is not).
>
> It does consistently fail for gitweb/gitweb.perl... but when I tried
> to debug it IE8 would hang up when trying to use debugger (with around
> 600MB available RAM). Perhaps somebody else would have more luck...
Interesting. I don't have time to look into this until early December,
but if it's still around then I'll take a look. I wonder if IE6 or IE7
works (I don't think everyone is on version 8 yet).
^ permalink raw reply
* [PATCHv2 2/2] gitweb.js: fix padLeftStr() and its usage
From: Stephen Boyd @ 2009-11-25 3:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <1258659887-5244-3-git-send-email-bebarino@gmail.com>
It seems that in Firefox-3.5 inserting with javascript inserts the
literal instead of a space. Fix this by inserting the unicode
representation for instead.
Also fix the off-by-one error in the padding calculation that was
causing one less space to be inserted than was requested by the caller.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Cc: Jakub Narebski <jnareb@gmail.com>
---
Fixed the commit message and squashed in the off-by-one bug.
gitweb/gitweb.js | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 02454d8..9214497 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -31,19 +31,19 @@
/**
* pad number N with nonbreakable spaces on the left, to WIDTH characters
- * example: padLeftStr(12, 3, ' ') == ' 12'
- * (' ' is nonbreakable space)
+ * example: padLeftStr(12, 3, '\u00A0') == '\u00A012'
+ * ('\u00A0' is nonbreakable space)
*
* @param {Number|String} input: number to pad
* @param {Number} width: visible width of output
- * @param {String} str: string to prefix to string, e.g. ' '
+ * @param {String} str: string to prefix to string, e.g. '\u00A0'
* @returns {String} INPUT prefixed with (WIDTH - INPUT.length) x STR
*/
function padLeftStr(input, width, str) {
var prefix = '';
width -= input.toString().length;
- while (width > 1) {
+ while (width > 0) {
prefix += str;
width--;
}
@@ -158,7 +158,7 @@ function updateProgressInfo() {
if (div_progress_info) {
div_progress_info.firstChild.data = blamedLines + ' / ' + totalLines +
- ' (' + padLeftStr(percentage, 3, ' ') + '%)';
+ ' (' + padLeftStr(percentage, 3, '\u00A0') + '%)';
}
if (div_progress_bar) {
--
1.6.6.rc0
^ permalink raw reply related
* [PATCH 2/2] Documentation for format-patch --notmuch.
From: Jed Brown @ 2009-11-25 2:50 UTC (permalink / raw)
To: git; +Cc: madcoder, Jed Brown
In-Reply-To: <1259117447-23052-1-git-send-email-jed@59A2.org>
---
Documentation/git-format-patch.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f1fd0df..aaa472d 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -171,6 +171,13 @@ will want to ensure that threading is disabled for `git send-email`.
to any configured headers, and may be used multiple times.
For example, `--add-header="Organization: git-foo"`
+--notmuch=<expr>::
+ Generate headers appropriate for a reply to a notmuch search for the
+ given expression. Usually an expression of the form id:<Message-ID>
+ will be used to match an exact message. The reply will set
+ In-Reply-To, References, To, Cc, Bcc, and possibly other headers
+ (depending on notmuch configuration).
+
--cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
--
1.6.5.3
^ permalink raw reply related
* [PATCH 1/2] Added the --notmuch option to git format-patch.
From: Jed Brown @ 2009-11-25 2:50 UTC (permalink / raw)
To: git; +Cc: madcoder, Jed Brown
In-Reply-To: <87d4375ne0.fsf@59A2.org>
The typical use case for this is
git format-patch --notmuch id:<MESSAGE-ID>
which will format your patch with all threading, references, and To, Cc
fields appropriate for a reply to the given message.
---
builtin-log.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 33fa6ea..9a44955 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -754,6 +754,53 @@ static const char *clean_message_id(const char *msg_id)
return xmemdupz(a, z - a);
}
+static int get_notmuch_reply(struct strbuf *buf, struct string_list *ref_message_ids, const char *query)
+{
+ struct child_process notmuch;
+ struct strbuf notmuch_out;
+ char *p, *other_headers, *rstart;
+ ssize_t len;
+ const char *argv[] = {"notmuch", "reply", "--format=headers-only", query, NULL};
+
+ memset(¬much, 0, sizeof(notmuch));
+
+ notmuch.argv = argv;
+ notmuch.no_stdin = 1;
+ notmuch.out = -1;
+
+ if (start_command(¬much))
+ return error("could not run notmuch.");
+
+ strbuf_init(¬much_out, 4096);
+ len = strbuf_read(¬much_out, notmuch.out, 4096);
+ close(notmuch.out);
+
+ if (finish_command(¬much) || !len || len < 0)
+ return error("notmuch did not return any headers");
+
+ /* Harvest the referenced message IDs, all on the first line */
+ p = notmuch_out.buf;
+
+ if (!strncmp(p, "References: ", sizeof("References: ")))
+ return error("notmuch response malformed");
+
+ other_headers = strstr(p, "To: ");
+ if (!other_headers)
+ return error("notmuch provided no other headers");
+
+ while ((rstart = strchr(p, '<')) && (p = strchr(rstart, '>')) && p < other_headers-1) {
+ if (!p)
+ error("notmuch returned malformed references");
+ p++;
+ *p++ = 0;
+ string_list_append(clean_message_id(rstart), ref_message_ids);
+ }
+ /* Add everything after the first line */
+ strbuf_addstr(buf, other_headers);
+ strbuf_release(¬much_out);
+ return 0;
+}
+
static const char *set_outdir(const char *prefix, const char *output_directory)
{
if (output_directory && is_absolute_path(output_directory))
@@ -893,7 +940,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
int boundary_count = 0;
int no_binary_diff = 0;
struct commit *origin = NULL, *head = NULL;
- const char *in_reply_to = NULL;
+ const char *in_reply_to = NULL, *notmuch = NULL;
struct patch_ids ids;
char *add_signoff = NULL;
struct strbuf buf = STRBUF_INIT;
@@ -940,6 +987,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
PARSE_OPT_NONEG, cc_callback },
OPT_STRING(0, "in-reply-to", &in_reply_to, "message-id",
"make first mail a reply to <message-id>"),
+ OPT_STRING(0, "notmuch", ¬much, "query",
+ "make first mail a reply to messages matched by <query>"),
{ OPTION_CALLBACK, 0, "attach", &rev, "boundary",
"attach the patch", PARSE_OPT_OPTARG,
attach_callback },
@@ -1015,8 +1064,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
strbuf_addch(&buf, '\n');
}
- rev.extra_headers = strbuf_detach(&buf, NULL);
-
if (start_number < 0)
start_number = 1;
@@ -1135,12 +1182,18 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
numbered = 1;
if (numbered)
rev.total = total + start_number - 1;
- if (in_reply_to || thread || cover_letter)
+ if (in_reply_to || thread || cover_letter || notmuch)
rev.ref_message_ids = xcalloc(1, sizeof(struct string_list));
if (in_reply_to) {
const char *msgid = clean_message_id(in_reply_to);
string_list_append(msgid, rev.ref_message_ids);
}
+ if (notmuch) {
+ get_notmuch_reply(&buf, rev.ref_message_ids, notmuch);
+ }
+
+ rev.extra_headers = strbuf_detach(&buf, NULL);
+
rev.numbered_files = numbered_files;
rev.patch_suffix = fmt_patch_suffix;
if (cover_letter) {
--
1.6.5.3
^ permalink raw reply related
* git send-email --notmuch expr
From: Jed Brown @ 2009-11-25 2:49 UTC (permalink / raw)
To: git, Pierre Habouzit
Notmuch is a new mail system with fast indexing and tagging, see
notmuchmail.org. It has a command-line tool to build replies to emails,
and I wrote a patch to format-patch that enables
git format-patch --notmuch EXPR
where EXPR is any notmuch query, but usually id:<Message-ID> to match a
specific message. This will set up several headers, notably
In-Reply-To, References, To, Cc, Bcc. This works great, and the the
patch follows this message.
But I really want
git send-email --notmuch EXPR
This sort-of works, but the interactive part prompts for the various
headers (even though format-patch supplies them), and then duplicates
the To header (both the possibly empty field the user provided, plus the
one coming from format-patch). I had a brief look at
git-send-email.perl, and I'm a little confused.
} elsif (/^(?:To|Cc|Bcc):/i) {
print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
next;
}
This regex doesn't match these headers (is the leading ?: a typo?) so
there is no warning. But it's important that these headers *not* be
ignored, getting them set automatically is a key feature of the
--notmuch option. I'm having trouble discerning whether I would cause
problems by just using these headers coming out of format-patch.
Presumably there was a reason why they were (intended to be) explicitly
ignored, and my poor perl skills are not helping. Could someone
enlighten me?
Jed
^ permalink raw reply
* Re: commit --quiet option
From: bill lam @ 2009-11-25 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywj76k4.fsf@alter.siamese.dyndns.org>
On Tue, 24 Nov 2009, Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
>
> > In git version 1.6.6.rc0.15.g4fa8a0 using the --quiet option it still
> > show some output. Is that intended? Specifically I would like to
> > exclude message about the untracked files when using --quite option.
>
> Given that you are getting "you told me to make a commit without preparing
> anything to commit" error message, I think it can be argued in both ways.
>
> $ git commit -q -uno -m 'meaningless message'
>
> would omit the listing of Untracked files; a better alternative, depending
> on what are listed in the section (I take "a123" is an example made-up for
> reproduction recipe, and you are probably getting something like 'foo.bak'
> in real life), might be to update your .gitignore, though.
That git-commit is intended to run inside a cron job for backup from
home folder and .files, so 'commit' is better than 'meaningless
message'. .gitignore is already maintained however those 'a123' is a
real life example, they are artifacts of '3m post-it' files because I
rarely use clipboard (c-ins/c-ins) to copy text from one application
into another.
Thanks for tips on -uno option.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] t1200: fix a timing dependent error
From: Junio C Hamano @ 2009-11-25 1:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Stephen Boyd, Junio C Hamano
In-Reply-To: <20091125080808.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> The fourth test of show-branch in t1200 test was failing but only
> sometimes. It only failed when two commits created in an earlier
> test had different timestamps. When they were created within the
> same second, the actual output matched the expected output.
Ahh, I actually saw this breakage once, suspected it would be something
like that, but didn't have enough energy/time to dig into it myself.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 1:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Stephen Boyd, git
In-Reply-To: <20091125100104.6117@nanako3.lavabit.com>
On Wed, 25 Nov 2009, Nanako Shiraishi wrote:
> Quoting Jakub Narebski <jnareb@gmail.com>
>
> > On Sat, 21 Nov 2009, Jakub Narebski wrote:
> >
> > Below the same patch is in the form of a proper commit; although the title
> > (subject) of this commit could be better...
>
> Does this replace the first of the previous two-patch series? Is
> Stephen's second patch still needed (with his fix)?
No, it replaces neither first patch of Stephen's two patch series that
started this thread, namely "gitweb.js: fix null object exception in
initials calculation" (which is about initials of committer... if they
exist), nor the follow-up fix of off-by-one bug in padLeftStr.
This is fix of an independent issue (even if it occurs only in IE8).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] shortlog: respect commit encoding
From: Junio C Hamano @ 2009-11-25 1:12 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Jiri Kosina
In-Reply-To: <1259075555-7831-1-git-send-email-u.kleine-koenig@pengutronix.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
> Before this change the author was taken from the raw commit without
> reencoding.
I see people often begin with "before this change" and stop the log
message after making a statement of a fact. I mildly dislike this style,
especially when the resulting message does not state that it is bad (and
if necessary why it is bad) nor state in what way the code after the
change is good.
Don't take the author name information without re-encoding
from the raw commit object buffer.
is easier to read, at least for me.
> while (*buffer && *buffer != '\n') {
> const char *eol = strchr(buffer, '\n');
>
> - if (eol == NULL)
> + if (eol == NULL) {
> eol = buffer + strlen(buffer);
> - else
> + } else
> eol++;
> if (!prefixcmp(buffer, "author "))
What is this hunk for?
> @@ -157,20 +162,20 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
> die("Missing author: %s",
> sha1_to_hex(commit->object.sha1));
> if (log->user_format) {
> - struct strbuf buf = STRBUF_INIT;
> struct pretty_print_context ctx = {0};
> ctx.abbrev = DEFAULT_ABBREV;
> ctx.subject = "";
> ctx.after_subject = "";
> ctx.date_mode = DATE_NORMAL;
> + pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
> + buffer = ufbuf.buf;
> +
> + } else if (*buffer)
> buffer++;
> +
You probably wanted to add an extra pair of {} around this "else
if" clause instead, not the earlier one.
Otherwise the change looks good from my cursory look.
> diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
> index 405b971..118204b 100755
> --- a/t/t4201-shortlog.sh
> +++ b/t/t4201-shortlog.sh
> @@ -51,5 +51,29 @@ git log HEAD > log
> GIT_DIR=non-existing git shortlog -w < log > out
>
> test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
> +iconvfromutf8toiso885915() {
> + printf "%s" "$@" | iconv -f UTF-8 -t ISO-8859-15
> +}
A bad use of "$@" that expands to $# individual words; you meant
to say "$*".
Could we please have the following inside its own test, so that
any failure while preparing the test data is caught as an error?
> +git reset --hard "$commit"
> +git config --unset i18n.commitencoding
> +echo 2 > a1
> +git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1
> +
> +git config i18n.commitencoding "ISO-8859-15"
> +echo 3 > a1
> +git commit --quiet -m "$(iconvfromutf8toiso885915 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso885915 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1
> +git config --unset i18n.commitencoding
> +
> +git shortlog HEAD~2.. > out
> +
> +cat > expect << EOF
> +Jöhännës "Dschö" Schindëlin (2):
> + set a1 to 2 and some non-ASCII chars: Äßø
> + set a1 to 3 and some non-ASCII chars: áæï
> +
> +EOF
> +
> +test_expect_success 'shortlog encoding' 'test_cmp expect out'
t3900-i18n-commit already uses 8859-1 so if it is not too much to
ask, it would be much nicer to have these test work between UTF-8
and 8859-1, not -15.
That way, I do not have to worry about breaking tests for people
who were able to run existing iconv tests because they do not have
working 8859-15.
Thanks
^ permalink raw reply
* Re: [PATCH] mailinfo: remove [PATCH...] prefix from Subject regardless of length
From: Junio C Hamano @ 2009-11-25 1:10 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <874ookp4u8.fsf@meyering.net>
Jim Meyering <meyering@redhat.com> writes:
> Before this change, a [...] prefix would be removed only as long as
> its length did not exceed 2/3 of the subject length. Now, when the
> bracketed quantity starts with PATCH, it is removed unconditionally.
> Otherwise, the existing behavior remains unchanged.
Thanks, I think this is a good idea in general, but have two comments.
- I am not sure how this should play with 17635fc (mailinfo: -b option
keeps [bracketed] strings that is not a [PATCH] marker, 2009-07-15).
- Regardless of interaction with 17635fc, Things like [RFC PATCH]
[SECURITY PATCH] might want a similar treatment.
^ permalink raw reply
* Re: commit --quiet option
From: Junio C Hamano @ 2009-11-25 1:10 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091124051622.GB18003@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> In git version 1.6.6.rc0.15.g4fa8a0 using the --quiet option it still
> show some output. Is that intended? Specifically I would like to
> exclude message about the untracked files when using --quite option.
Given that you are getting "you told me to make a commit without preparing
anything to commit" error message, I think it can be argued in both ways.
$ git commit -q -uno -m 'meaningless message'
would omit the listing of Untracked files; a better alternative, depending
on what are listed in the section (I take "a123" is an example made-up for
reproduction recipe, and you are probably getting something like 'foo.bak'
in real life), might be to update your .gitignore, though.
> $ git commit -q -m commit
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: .git-completion.bash
> # modified: bin/mirrorgit
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # a123
> no changes added to commit (use "git add" and/or "git commit -a")
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Nanako Shiraishi @ 2009-11-25 1:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git
In-Reply-To: <200911250145.16472.jnareb@gmail.com>
Quoting Jakub Narebski <jnareb@gmail.com>
> On Sat, 21 Nov 2009, Jakub Narebski wrote:
>
> Below the same patch is in the form of a proper commit; although the title
> (subject) of this commit could be better...
Does this replace the first of the previous two-patch series? Is Stephen's second patch still needed (with his fix)?
Quoting Stephen Boyd <bebarino@gmail.com>
> Jakub Narebski wrote:
>> I have tested gitweb with both of your patches applied, serving gitweb
>> as CGI script using Apache 2.0.54 on Linux, and viewing from separate
>> computer on MS Windows XP, with the following results:
>>
>> * For the following browsers blame_incremental view on gitweb/gitweb.perl
>> file produces correct output, but for progress info which instead of
>> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
>
> This is due to an off-by-one error in the while loop. This should fix
> it. I'll probably squash this into patch 2 and resend.
>
> --->8----
>
> diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
> index 30597dd..9214497 100644
> --- a/gitweb/gitweb.js
> +++ b/gitweb/gitweb.js
> @@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {
> var prefix = '';
>
> width -= input.toString().length;
> - while (width > 1) {
> + while (width > 0) {
> prefix += str;
> width--;
> }
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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