* strange problems applying --no-prefix patch with -p0 and added files
From: Sergey Shelukhin @ 2012-10-24 20:54 UTC (permalink / raw)
To: git
Hello.
I am trying to apply a patch made via {git diff somehash^ somehash >
....} before (same version of Git, same machine). I have no-prefix
enabled by default.
If I try to apply the patch with -p0, it fails.
If I go to a directory where all the changed files are ("src/" below)
to "simulate" the prefix for -p1, it silently does nothing.
Only if I make it a -p1 patch, it actually tries to do apply (and
applies the new files that cause problems in -p0 alright too, if used
with --reject).
I am relatively new to git, so while researching I realized I might be
using wrong ways to do things (e.g. not using cherry-pick), but this
seems like a bug regardless.
Here's the log of my interactions with git:
reznor-mbp:git-hbase-089 sergey$ git version
git version 1.7.10.2 (Apple Git-33)
reznor-mbp:git-hbase-089 sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:git-hbase-089 sergey$ git apply -p0 HBASE-6371.patch
fatal: git apply: bad git-diff - inconsistent new filename on line 128
reznor-mbp:git-hbase-089 sergey$ sed -n 125,129p HBASE-6371.patch
diff --git src/main/java/org/apache/
hadoop/hbase/regionserver/CompactSelection.java
src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
new file mode 100644
index 0000000..a9ee0d4
--- /dev/null
+++ src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
reznor-mbp:git-hbase-089 sergey$ cd src
reznor-mbp:src sergey$ git apply -p1 -v --whitespace=nowarn ../HBASE-6371.patch
[ there's nothing here, e.g. no output ]
reznor-mbp:src sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ../HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:src sergey$ cd ..
reznor-mbp:git-hbase-089 sergey$ sed -E "s/(--git|---) src/\1 a\/src/"
HBASE-6371.patch | sed -E "s/ src\// b\/src\//" >
HBASE-6371-prefix.patch
reznor-mbp:git-hbase-089 sergey$ git apply HBASE-6371-prefix.patch
HBASE-6371-prefix.patch:169: trailing whitespace.
...
error: patch failed:
src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:64
error: src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:
patch does not apply
....
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-24 19:25 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121024171036.GA18880@shrek.podlesie.net>
On Wed, Oct 24, 2012 at 07:10:36PM +0200, Krzysztof Mazur wrote:
> > > - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > > + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > > + ($subject =~ /[^[:ascii:]]/)) {
> >
> > Is that test sufficient? We would also need to encode if it has rfc2047
> > specials, no?
>
> For Subject this should be sufficient. According to RFC822 after
> "Subject:" we have "text" token,
> [...]
> So the problem only exists for broken RFC2047-like texts, but I think
> it's ok to just pass such subjects, in most cases the Subject comes
> from already formatted patch file. I think that we just want to fix Subjects
> without specified encoding here.
Right, but I was specifically worried about raw "=?", which is only an
issue due to rfc2047 itself.
However, reading the patch again, we are already checking for that with
is_rfc2047_quoted. It might miss the case where we have =? but not the
rest of a valid encoded word, but any compliant parser should recognize
that and leave it be.
So I think your original patch is actually correct.
> I think we can go even further, we can just add quote_subject(),
> which performs this test and calls quote_rfc2047() if necessary.
> I'm sending bellow patch that does that.
Yeah, it would still be nice to keep the logic in one place.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index efeae4c..e9aec8d 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -657,9 +657,7 @@ EOT
> $initial_subject = $1;
> my $subject = $initial_subject;
> $_ = "Subject: " .
> - ($subject =~ /[^[:ascii:]]/ ?
> - quote_rfc2047($subject, $compose_encoding) :
> - $subject) .
> + quote_subject($subject, $compose_encoding) .
Hrm. Isn't this one technically a regression if the $subject contains
encoded words? IOW, in this case we feed quote_subject a known-raw
header; any rfc2047 in it would want to be encoded to be preserved.
But in this case:
> @@ -1327,9 +1341,8 @@ foreach my $t (@files) {
> $body_encoding = $auto_8bit_encoding;
> }
>
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> - ($subject =~ /[^[:ascii:]]/)) {
> - $subject = quote_rfc2047($subject, $auto_8bit_encoding);
> + if ($broken_encoding{$t}) {
> + $subject = quote_subject($subject, $auto_8bit_encoding);
> }
We have a possibly already-encoded header, and we would want to avoid
double-encoding it.
In the first case, the "wants quoting" logic should be:
is_rfc2047_quoted($subject) || /[^[:ascii:]]/
and in the latter case it would be:
!is_rfc2047_quoted($subject) && /^[:ascii:]]/
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jens Lehmann @ 2012-10-24 19:15 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Nahor, Phil Hord
In-Reply-To: <1f6ee2966ffe0f58f4b96ae0efb2ffb13e2fa2d8.1351029479.git.wking@tremily.us>
I still fail to see what adding that functionality to the submodule
command buys us (unless we also add code which really uses the branch
setting). What's wrong with doing a simple:
git config -f .gitmodules submodule.<path>.branch <record_branch>
on the command line when you want to use the branch setting for your
own purposes? You could easily wrap that into a helper script, no?
Am 23.10.2012 23:57, schrieb W. Trevor King:
> From: "W. Trevor King" <wking@tremily.us>
>
> This option allows you to record a submodule.<name>.branch option in
> .gitmodules. Git does not currently use this configuration option for
> anything, but users have used it for several things, so it makes sense
> to add some syntactic sugar for initializing the value.
>
> Current consumers:
>
> Ævar uses this setting to designate the upstream branch for pulling
> submodule updates:
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> as he describes in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date: Fri May 21 16:10:10 2010 +0000
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses this setting to
>
> “indicate the branch of a submodule project that when updated will
> trigger automatic update of its registered gitlink.” [1]
>
> I'm not clear on what that means, but they accept special values like
> '.', so their usage is not compatible with Ævar's proposal.
>
> By remaining agnostic on the variable usage, this patch makes
> submodule setup more convenient for all parties.
>
> [1] https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/git-submodule.txt | 11 ++++++++++-
> git-submodule.sh | 19 ++++++++++++++++++-
> t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++
> 3 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b4683bb..f9c74d6 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
> SYNOPSIS
> --------
> [verse]
> -'git submodule' [--quiet] add [-b branch] [-f|--force]
> +'git submodule' [--quiet] add [-b branch] [--record[=<branch>]] [-f|--force]
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> @@ -209,6 +209,15 @@ OPTIONS
> --branch::
> Branch of repository to add as submodule.
>
> +-r::
> +--record::
> + Record a branch name used as `submodule.<path>.branch` in
> + `.gitmodules` for future reference. If you do not list an explicit
> + name here, the name given with `--branch` will be recorded. If that
> + is not set either, `HEAD` will be recorded. Because the branch name
> + is optional, you must use the equal-sign form (`-r=<branch>`), not
> + `-r <branch>`.
> +
> -f::
> --force::
> This option is only valid for add and update commands.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..bc33112 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -5,7 +5,7 @@
> # Copyright (c) 2007 Lars Hjemli
>
> dashless=$(basename "$0" | sed -e 's/-/ /')
> -USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> +USAGE="[--quiet] add [-b branch] [--record[=<branch>]] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> @@ -20,6 +20,8 @@ require_work_tree
>
> command=
> branch=
> +record_branch=
> +record_branch_empty=
> force=
> reference=
> cached=
> @@ -257,6 +259,12 @@ cmd_add()
> branch=$2
> shift
> ;;
> + -r | --record)
> + record_branch_empty=true
> + ;;
> + -r=* | --record=*)
> + record_branch="${1#*=}"
> + ;;
> -f | --force)
> force=$1
> ;;
> @@ -328,6 +336,11 @@ cmd_add()
> git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
> die "$(eval_gettext "'\$sm_path' already exists in the index")"
>
> + if test -z "$record_branch" && test "$record_branch_empty" = "true"
> + then
> + record_branch="${branch:=HEAD}"
> + fi
> +
> if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path" > /dev/null 2>&1
> then
> eval_gettextln "The following path is ignored by one of your .gitignore files:
> @@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
>
> git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
> git config -f .gitmodules submodule."$sm_path".url "$repo" &&
> + if test -n "$branch"
> + then
> + git config -f .gitmodules submodule."$sm_path".branch "$record_branch"
> + fi &&
> git add --force .gitmodules ||
> die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
> }
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index 5397037..88ae74c 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
> (
> cd addtest &&
> git submodule add -b initial "$submodurl" submod-branch &&
> + test -z "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
> git submodule init
> ) &&
>
> @@ -211,6 +212,30 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
> test_cmp empty untracked
> '
>
> +test_expect_success 'submodule add --record' '
> + (
> + cd addtest &&
> + git submodule add -r "$submodurl" submod-record-head &&
> + test "$(git config -f .gitmodules submodule.submod-record-head.branch)" = "HEAD"
> + )
> +'
> +
> +test_expect_success 'submodule add --record --branch' '
> + (
> + cd addtest &&
> + git submodule add -r -b initial "$submodurl" submod-auto-record &&
> + test "$(git config -f .gitmodules submodule.submod-auto-record.branch)" = "initial"
> + )
> +'
> +
> +test_expect_success 'submodule add --record=<name> --branch' '
> + (
> + cd addtest &&
> + git submodule add -r=final -b initial "$submodurl" submod-record &&
> + test "$(git config -f .gitmodules submodule.submod-record.branch)" = "final"
> + )
> +'
> +
> test_expect_success 'setup - add an example entry to .gitmodules' '
> GIT_CONFIG=.gitmodules \
> git config submodule.example.url git://example.com/init.git
>
^ permalink raw reply
* Re: [PATCH 8/8] git-config: use git_config_with_options
From: Ævar Arnfjörð Bjarmason @ 2012-10-24 19:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Git Mailing List, Junio C Hamano
In-Reply-To: <50878BB1.8050902@viscovery.net>
Yeah same here. Thanks for tackling this bug. Looking forward to using
the include mechanism for overriding user.email in future versions.
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-24 19:11 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s2RspCrRXZbRTsVwezyU9X=+8RF=_9Q+3zX75LBJkdoPA@mail.gmail.com>
Felipe Contreras wrote:
> Does it mean that? I don't think so, but let's assume that's the case.
>
> We don't have all those commits; without the marks we have nothing. Or
> what exactly do you mean by 'we'?
Not everyone uses marks.
Ciao,
Jonathan
^ permalink raw reply
* Re: [PATCH] git-submodule add: Record branch name in .gitmodules
From: Jens Lehmann @ 2012-10-24 19:10 UTC (permalink / raw)
To: Nahor; +Cc: git, wking
In-Reply-To: <508713DE.7040801@gmail.com>
Am 24.10.2012 00:02, schrieb Nahor:
> On 2012-10-23 13:36, Jens Lehmann wrote:
>> Am 23.10.2012 21:16, schrieb Nahor:
>>> Last issue, the branch that exists in your local repository may not
>>> exist in someone else's repository, either because the branch is
>>> purely local, or because it has a different name on the remote repo.
>>
>> You'll always face this kind of problems with commits too when using
>> submodules, so I don't see that as a problem here.
>
> Commits can't change or disappear during "normal" git operation (i.e. without using "git push -f" or "git branch -D").
> A commit also has the same id in all the clones repository so there is no issue of a different name between the local and the remote repositories.
But if you forget to push a submodule commit it won't exist in someone
else's repository and so he won't be able to update the submodule after
checking out a commit in the superproject that records that unpushed
submodule commit.
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-24 19:09 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121024180807.GA3338@elie.Belkin>
On Wed, Oct 24, 2012 at 8:08 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Felipe,
>
> Felipe Contreras wrote:
>
>> This test is completely wrong.
>>
>> 1) Where are the marks file?
>> 2) master..master shouldn't export anything
>
> Why shouldn't master..master export anything? It means "update the
> master ref; we already have all commits up to and including master^0".
Does it mean that? I don't think so, but let's assume that's the case.
We don't have all those commits; without the marks we have nothing. Or
what exactly do you mean by 'we'?
Go to your git.git repository, and run this:
% git git init /tmp/git
% git fast-export master^..master | git --git-dir=/tmp/git/.git fast-import
What do you expect? I expect a single commit, and that's what we get,
now do the same with 'master..master', what do you expect?
How about 'git fast-export ^master'? Do you expect to get anything
there? Or what about '^master master'?
Without marks these idioms don't make any sense. Now lets assume that
marks were meant to be there.
If 'master..master' is supposed to update master, then what is
'master' supposed to do?
% git fast-export --{im,ex}port-marks=/tmp/marks master..master
vs.
% git fast-export --{im,ex}port-marks=/tmp/marks master
Either way, my patch will make 'master..master' throw a reset (if the
marks are present, I haven't tried without them), I don't think it
should, but that's a different story, and a different patch fix.
> The underlying problem is that fast-export takes rev-list arguments as
> parameters, which is unfortunately only an approximation to what is
> really intended. Ideally it would separately take a list of refs to
> import and rev-list arguments representing the commits we already
> have.
The commits we already have (exported before) are stored in the marks.
Maybe we can store the refs there as well, but that would not change
the semantics of refspecs, nor the fact that we need the marks.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* git-gui: textconv not used on unstaged files
From: Peter Oberndorfer @ 2012-10-24 18:33 UTC (permalink / raw)
To: git
Hi,
i am using a textconv filter to display .doc files as plain text.
It seems git gui does not use this textconv filter for displaying new
unstaged files
(other files? = _O)
It seems diff.tcl start_show_diff calls show_other_diff because of this.
This manually loads the file and does not care about textconv filters.
Is this manual loading really necessary or can't we just ask git?
If it is can it be modified to use the textconv filter?
Thanks,
Greetings Peter
.gitattributes:
*.doc diff=astextplain
gitconfig:
[diff "astextplain"]
textconv = astextplain
^ permalink raw reply
* Re: [PATCH] git-submodule add: Record branch name in .gitmodules
From: Phil Hord @ 2012-10-24 18:12 UTC (permalink / raw)
To: W. Trevor King, git
In-Reply-To: <20121022225546.GO23101@odin.tremily.us>
On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King <wking@tremily.us> wrote:
> On a tangentially related note, it would be nice to set environment
> variables for each of the settings in submodule.$name during a foreach
> call. Then you could use
>
> git submodule foreach 'git checkout $branch && git pull'
>
> Perhaps you'd want to blacklist/whitelist or downcase settings names
> to avoid things like
>
> [submodule "foo"]
> PATH = /my/rootkit/
>
> but the update line is much cleaner.
This is ugly as can be, but it works in my meagre testing. It defines
"submodule_path=/my/rootkit/" for the above bit of .gitmodules. That
is, it adds definitions for 'submodule_<var-name>' for each <var-name>
in .gitmodules in submodule.$name.<var-name>, but <var-name> is
lowercased and defanged (everything that's not already [a-z0-9] is
replaced with underscore). For example,
git submodule foreach 'echo $submodule_url'
--- >8 ---
diff --git c/git-submodule.sh i/git-submodule.sh
index 6dd2338..79b3467 100755
--- c/git-submodule.sh
+++ i/git-submodule.sh
@@ -416,7 +416,15 @@ cmd_foreach()
prefix="$prefix$sm_path/"
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+ # make all submodule variables
available to scripts
+ eval $(git config -f .gitmodules
--get-regexp "^submodule\.${name}\..*" |
+ sed -e "s|^submodule\.${name}\.||" |
+ while read VAR_NAME VAR_VALUE ; do
+ VAR_NAME=$(printf '%s'
"$VAR_NAME" | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g')
+ printf 'submodule_%s=%s;\n'
"$VAR_NAME" "'$VAR_VALUE'"
+ done)
cd "$sm_path" &&
eval "$@" &&
if test -n "$recursive"
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-24 18:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <CAMP44s1hdZb_7Lv8SEe+MsfC_q-nXsnjJobABFq6eFR_er4TaA@mail.gmail.com>
Hi Felipe,
Felipe Contreras wrote:
> This test is completely wrong.
>
> 1) Where are the marks file?
> 2) master..master shouldn't export anything
Why shouldn't master..master export anything? It means "update the
master ref; we already have all commits up to and including master^0".
The underlying problem is that fast-export takes rev-list arguments as
parameters, which is unfortunately only an approximation to what is
really intended. Ideally it would separately take a list of refs to
import and rev-list arguments representing the commits we already
have.
Hoping that clarifies,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Felipe Contreras @ 2012-10-24 18:02 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> When a revision is specified on the commandline we explicitly output
> a 'reset' command for it if it was not handled already. This allows
> for example the remote-helper protocol to use fast-export to create
> branches that point to a commit that has already been exported.
This simpler patch does the same, doesn't it?
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..3b4c2d6 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,10 +523,13 @@ static void get_tags_and_duplicates(struct
object_array *pending,
typename(e->item->type));
continue;
}
- if (commit->util)
- /* more than one name for the same object */
+ /*
+ * This ref will not be updated through a commit, lets make
+ * sure it gets properly updated eventually.
+ */
+ if (commit->util || commit->object.flags & SHOWN)
string_list_append(extra_refs,
full_name)->util = commit;
- else
+ if (!commit->util)
commit->util = full_name;
}
}
> Initial-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> ---
>
> Most of the hard work for this patch was done by Dscho. The rest of
> it was basically me applying the technique used by jch in c3502fa
> (25-08-2011 do not include sibling history in --ancestry-path).
>
> The if statement dealing with tag_of_filtered_mode is not as
> elegant as either me or Dscho would have liked, but we couldn't
> find a better way to determine if a ref is a tag at this point
> in the code.
Which is needed why?
Right now if I do:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 tag-to-foo1
Where tag-to-foo1 is a tag that that points to foo1, I get a reset for that.
> Additionally, the elem->whence != REV_CMD_RIGHT case should really
> check if REV_CMD_RIGHT_REF, but as this is not provided by the
> ref_info structure this is left as is. A result of this is that
> incorrect input will result in incorrect output, rather than an
> error message. That is: `git fast-export a..<sha1>` will
> incorrectly generate a `reset <sha1>` statement in the fast-export
> stream.
I don't see the point of this.
Besides, you can check the return value of dwim_ref, if it's not 1,
then you shouldn't generate a reset.
> The dwim_ref bit is a double work (it has already been done by the
> caller of this function), but I decided it would be more work to
> pass this information along than to recompute it for the few
> commandline refs that were relevant.
It's already stored in commit->util, you don't need to do that.
As I said, I think the patch above does the trick, and it even has the
advantage of not having the above a..<SHA-1> issues.
Cheers.
--
Felipe Contreras
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-24 17:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-2-git-send-email-srabbelier@gmail.com>
Hi,
Joined late to the party :)
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> This happens only when the corresponding commits are not exported in
> the current fast-export run. This can happen either when the relevant
> commit is already marked, or when the commit is explicitly marked
> as UNINTERESTING with a negative ref by another argument.
>
> This breaks fast-export based remote helpers, as they use marks
> files to store which commits have already been seen. The call graph
> is something as follows:
>
> $ # push master to remote repo
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # make a commit on master and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # run `git branch foo` and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile foo
That is correctly, but try this:
$ git fast-export --{im,ex}port-marks=marksfile foo foo
Now foo is updated.
> When fast-export imports the marksfile and sees that all commits in
> foo are marked as UNINTERESTING (they have already been exported
> while pushing master), it exits without doing anything. However,
> what we want is for it to reset 'foo' to the already-exported commit.
>
> Either way demonstrates the problem, and since this is the most
> succint way to demonstrate the problem it is implemented by passing
> master..master on the commandline.
>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> ---
> t/t9350-fast-export.sh | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
> index 950d0ff..74914dc 100755
> --- a/t/t9350-fast-export.sh
> +++ b/t/t9350-fast-export.sh
> @@ -440,4 +440,15 @@ test_expect_success 'fast-export quotes pathnames' '
> )
> '
>
> +cat > expected << EOF
> +reset refs/heads/master
> +from $(git rev-parse master)
> +
> +EOF
> +
> +test_expect_failure 'refs are updated even if no commits need to be exported' '
> + git fast-export master..master > actual &&
> + test_cmp expected actual
> +'
> +
> test_done
This test is completely wrong.
1) Where are the marks file?
2) master..master shouldn't export anything
3) Why do you expect a SHA-1? It could be a mark.
I decided to write my own this way:
---
cat > expected << EOF
reset refs/heads/master
from ##mark##
EOF
test_expect_failure 'refs are updated even if no commits need to be exported' '
cp tmp-marks /tmp
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master | true &&
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master > actual &&
mark=$(grep $(git rev-parse master) tmp-marks | cut -f 1 -d " ")
sed -i -e "s/##mark##/$mark/" expected &&
test_cmp expected actual
'
---
Yes, it's true this fails, but change to 'master master', and then it works.
This can be easily fixed by this patch:
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..3b4c2d6 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,10 +523,13 @@ static void get_tags_and_duplicates(struct
object_array *pending,
typename(e->item->type));
continue;
}
- if (commit->util)
- /* more than one name for the same object */
+ /*
+ * This ref will not be updated through a commit, lets make
+ * sure it gets properly updated eventually.
+ */
+ if (commit->util || commit->object.flags & SHOWN)
string_list_append(extra_refs,
full_name)->util = commit;
- else
+ if (!commit->util)
commit->util = full_name;
}
}
Now if you specify a ref it will get updated regardless. However, this
points to another bug:
% git fast-export --{im,ex}port-marks=/tmp/marks master ^foo foo.foo
The foo ref will be reset _twice_ because all pending refs after the
first one get reset no matter how they were specified.
That is already the case, my patch will cause this to generate the same output:
% git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
Which is still not got, but not catastrophic by any means.
Cheers.
--
Felipe Contreras
^ permalink raw reply related
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-10-24 17:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DvNSVSUT_9ym52pVaDSNMk10WfaVGhfgQeC8+SOWSpEw@mail.gmail.com>
It all goes to pack_refs() in write_remote_refs called from
update_remote_refs().
On Tue, Oct 23, 2012 at 11:29 PM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz <uri@4refs.com> wrote:
>> I have a large repository which I ran "git gc --aggressive" on that
>> I'm trying to clone on a local file system. I would expect it to
>> complete very quickly with hard links but it's taking about 6min to
>> complete with no checkout (git clone -n). I see the message "Clining
>> into 'repos'... done." appear after a few seconds but then Git just
>> hangs there for another 6min. Any idea what it's doing at this point
>> and how I can speed it up?
>
> "done." is printed by clone_local(), which is called in cmd_clone().
> After that there are just a few more calls. Maybe you could add a few
> printf in between these calls, see which one takes most time?
> --
> Duy
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-24 17:10 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121024084636.GA23500@sigill.intra.peff.net>
On Wed, Oct 24, 2012 at 04:46:36AM -0400, Jeff King wrote:
> On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
>
> > The git-send-email always use RFC2047 subject quoting for files
> > with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
> > even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
> > skipped.
> > [...]
> > - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > + ($subject =~ /[^[:ascii:]]/)) {
>
> Is that test sufficient? We would also need to encode if it has rfc2047
> specials, no?
For Subject this should be sufficient. According to RFC822 after
"Subject:" we have "text" token,
--- from RFC822 ---
/ "Subject" ":" *text
--- from RFC822 ---
and text is defined as:
--- from RFC822 ---
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
--- from RFC822 ---
so only CRLF is not allowed in Subject.
So the problem only exists for broken RFC2047-like texts, but I think
it's ok to just pass such subjects, in most cases the Subject comes
from already formatted patch file. I think that we just want to fix Subjects
without specified encoding here.
In most cases, when git-send-email is used for patches generated
by "git format-patch" we just don't want to corrupt Subject. The
"git format-patch" generates "broken" patches when commit message
uses only ASCII characters and patch contains some non-ASCII characters.
In this case original git-send-email, without this patch, adds RFC2047
quotation for pure ASCII Subject.
>
> It looks like we use the same regex elsewhere. Maybe this would be a
> good chance to abstract out a needs_rfc2047_quoting while we are in the
> area?
It's a good idea, however rules are different for Subject and addresses
(sanitize_address).
I think we can go even further, we can just add quote_subject(),
which performs this test and calls quote_rfc2047() if necessary.
I'm sending bellow patch that does that.
Krzysiek
--
From a1e6eef831275485ec1555d94ff0d9aac852dd12 Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur <krzysiek@podlesie.net>
Date: Wed, 24 Oct 2012 19:08:57 +0200
Subject: [PATCH] git-send-email: introduce quote_subject()
The quote_rfc2047() always adds RFC2047 quoting and to avoid quoting ASCII
subjects, before calling quote_rfc2047() subject must be tested for non-ASCII
characters. To avoid this new quote_subject() function is introduced.
The quote_subject() performs this test and calls quote_rfc2047() only if
necessary.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index efeae4c..e9aec8d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -657,9 +657,7 @@ EOT
$initial_subject = $1;
my $subject = $initial_subject;
$_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject, $compose_encoding) :
- $subject) .
+ quote_subject($subject, $compose_encoding) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
@@ -907,6 +905,22 @@ sub is_rfc2047_quoted {
$s =~ m/^(?:"[[:ascii:]]*"|=\?$token\?$token\?$encoded_text\?=)$/o;
}
+sub subject_needs_rfc2047_quoting {
+ my $s = shift;
+
+ return !is_rfc2047_quoted($s) && ($s =~ /[^[:ascii:]]/);
+}
+
+sub quote_subject {
+ local $subject = shift;
+ my $encoding = shift || 'UTF-8';
+
+ if (subject_needs_rfc2047_quoting($subject)) {
+ return quote_rfc2047($subject, $encoding);
+ }
+ return $subject;
+}
+
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
@@ -1327,9 +1341,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
- ($subject =~ /[^[:ascii:]]/)) {
- $subject = quote_rfc2047($subject, $auto_8bit_encoding);
+ if ($broken_encoding{$t}) {
+ $subject = quote_subject($subject, $auto_8bit_encoding);
}
if (defined $author and $author ne $sender) {
--
1.8.0.3.gf4c35fc
^ permalink raw reply related
* Re: [PATCH v3 5/6] tests: add remote-hg tests
From: Felipe Contreras @ 2012-10-24 15:47 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Junio C Hamano, Johannes Schindelin, Ilari Liusvaara,
Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <CAGdFq_hhjvysViU+rceOcX7L48BkxUbDzKiyT7LakFqz1ikT8A@mail.gmail.com>
On Sun, Oct 21, 2012 at 11:02 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sun, Oct 21, 2012 at 10:49 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> From the original remote-hg.
>>
>> You need git-remote-hg already in your path to run them.
>>
>> I'm not proposing to include this patch like this, but should make it easier to
>> test.
>
> You should also have a look at the tests that were marked as "expected
> to fail", since they point out a bug with fast-export.
What tests? All the tests I see in msysgit are expected to succeed:
https://github.com/msysgit/git/blob/devel/t/t5801-remote-hg.sh
> I'd sent a
> series to fix that, but didn't follow-up to get it merged:
>
> http://thread.gmane.org/gmane.comp.version-control.git/184874
I have read that thread multiple times now, and I still don't see the
problem. Everything works fine in my remote-hg. I still don't
understand what changes are required in upstream that your remote-hg
needs, and the fact that there is no up-to-date remote-hg branch
doesn't help.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] configure: fix some output message
From: Stefano Lattarini @ 2012-10-24 15:34 UTC (permalink / raw)
To: git; +Cc: Stefano Lattarini
Before this change, output from ./configure could contain
botched wording like this:
checking Checking for POSIX Threads with '-pthread'... yes
instead of the intended:
checking for POSIX Threads with '-pthread'... yes
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c85888c..ad215cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1024,7 +1024,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
for opt in -mt -pthread -lpthread; do
old_CFLAGS="$CFLAGS"
CFLAGS="$opt $CFLAGS"
- AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
+ AC_MSG_CHECKING([for POSIX Threads with '$opt'])
AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
@@ -1044,7 +1044,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
else
old_CFLAGS="$CFLAGS"
CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
- AC_MSG_CHECKING([Checking for POSIX Threads with '$PTHREAD_CFLAGS'])
+ AC_MSG_CHECKING([for POSIX Threads with '$PTHREAD_CFLAGS'])
AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
--
1.8.0.rc2.11.gd25c58c
^ permalink raw reply related
* Re: [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2012-10-24 14:29 UTC (permalink / raw)
To: Herman van Rink; +Cc: git list
In-Reply-To: <5082FE13.2000003@initfour.nl>
On Sat, 20 Oct 2012 21:40:03 +0200
Herman van Rink <rink@initfour.nl> wrote:
> On 10/19/2012 03:21 PM, Yann Dirson wrote:
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
> >
> >
> > Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
> > mentions a <refspec> which the synopsis does not show either.
> >
> >
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
> >
>
> The version of subtree in contrib is rather out-dated unfortunately.
>
> I've collected a bunch of patches in
> https://github.com/helmo/git/tree/subtree-updates
Ah, it's nice to see subtree updates. Any plans to get them merged anytime soon ?
I guess you may want to rebase the patches from https://github.com/helmo/git-subtree,
the subtree-updates patch looks like a "subtree merge --squash" result, and is not really
suitable for reviewing on the list.
> The documentation issue is also fixed in there.
>
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: git commit-tree man page
From: Andreas Schwab @ 2012-10-24 13:59 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9BMndLj_nHW=EQbSS96Gp5+5NA3Vyb0r-EfVd+OPyQhnA@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hello,
>
> the man page of git commit-tree SYNOPSIS is:
>
> git commit-tree <tree> [(-p <parent>)...] < changelog
> git commit-tree [(-p <parent>)...] [(-m <message>)...] [(-F
> <file>)...] <tree>
>
> The second form is incorrect: the <tree> must be specified before the options.
> E.g.
>
> $ git commit-tree -m B 88f7dbd47
> fatal: Not a valid object name -m
This has been fixed in 1.7.11.4:
* "git commit-tree" learned a more natural "-p <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git commit-tree man page
From: Angelo Borsotti @ 2012-10-24 12:45 UTC (permalink / raw)
To: git
Hello,
the man page of git commit-tree SYNOPSIS is:
git commit-tree <tree> [(-p <parent>)...] < changelog
git commit-tree [(-p <parent>)...] [(-m <message>)...] [(-F
<file>)...] <tree>
The second form is incorrect: the <tree> must be specified before the options.
E.g.
$ git commit-tree -m B 88f7dbd47
fatal: Not a valid object name -m
$ git commit-tree 88f7dbd47 -m B
2f7619ed932787a128a84c4809d7b72ef38257a5
-Angelo Borsotti
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Catalin Marinas @ 2012-10-24 11:18 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Gleixner, Al Viro, Chris Metcalf, LKML,
linux-arch@vger.kernel.org, Linus Torvalds, git@vger.kernel.org,
Junio C Hamano
In-Reply-To: <20121023212245.GA28828@sigill.intra.peff.net>
On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote:
> On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote:
> > > It is spelled:
> > >
> > > git notes add -m <comment> SHA1
> > >
> > > The resulting notes are stored in a separate revision-controlled branch
> > > and can be pushed and pulled like regular refs. Note, though, that the
> > > default refspecs do not yet include refs/notes, so you'd have to add
> > > them manually. The workflows around notes are not very mature yet, so if
> > > you start using them, feedback would be appreciated.
> >
> > What would be nice is that notes are pushed/pulled automatically with
> > standard git push/fetch/pull commands. Usually git walks the DAG
> > starting with the pulled commit or tag and following the parents. With
> > notes, the reference is reversed, the note pointing to the commit and
> > not the other way around. So handling this automatically in Git would
> > be really useful.
>
> Right, that's what I meant about the refspecs. You can configure git to
> push or pull them automatically, but it is not the default. Something
> like:
>
> git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*'
Yes, but that's a bit more complicated than a simple pull. Anyway, Linus
seems to not be in favour of annotating commits later for adding acks,
so no need for such feature.
> > The other feature I'd like is that notes are automatically folded in
> > the log during git rebase (maybe similar to the squash option). If you
> > rebase, you lose all the notes (though this depends on the workflow,
> > it may not be needed with published branches).
>
> Git-rebase can automatically copy notes from one commit to another
> during a rebase, but you need to set notes.rewriteRef to do so (see "git
> help config" for details). The reason for this conservative default is
> that some notes may not be appropriate for automatic copying (e.g., a
> notes tree containing QA approval should probably be invalidated during
> a rebase, whereas one with commentary probably should).
Thanks, I wasn't aware of this.
> Squashing the notes into the commit message during rebase would be a
> useful feature (at least for some type of notes), but that feature does
> not currently exist (and as far as I recall, this is the first it has
> been proposed).
For some workflow - I post patches to the list, people reply with their
acks, I could just add those to notes and later fold them into the
existing commits before pushing the branch upstream. I guess it may be
just a matter of changing git format-patch to include the notes. I can
later reword he commits and drop the "Notes:" line.
--
Catalin
^ permalink raw reply
* confused by git diff --exit-code
From: Bogolisk @ 2012-10-24 10:33 UTC (permalink / raw)
To: git
With merge conflicts in the work-tree, diff's exit-code seems inconsistent. I
thought --quiet implied --exit-code
/others/foo$ git diff --quiet
/others/foo$ echo $?
1
/others/foo$ git diff --exit-code
diff --cc foo.txt
index f3dc283,bea67fd..0000000
--- a/foo.txt
+++ b/foo.txt
/others/foo$ echo $?
0
/others/foo$ git diff --cc --quiet
/others/foo$ echo $?
0
/others/foo$ git diff --cc --exit-code
diff --cc foo.txt
index f3dc283,bea67fd..0000000
--- a/foo.txt
+++ b/foo.txt
/others/foo$ echo $?
0
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Michael J Gruber @ 2012-10-24 9:46 UTC (permalink / raw)
To: Mat Arge; +Cc: git
In-Reply-To: <1392235.RizYqAYdkC@off17>
Mat Arge venit, vidit, dixit 22.10.2012 15:38:
> Hy!
>
> I would like to sign each commit with a X.509 certificate and a private key
> stored on a PKCS#11 token. I assume that that should be possible somehow using
> a hook which calls openssl. Does somebody know a working implementation of
> this?
>
> cheers
> Mat
>
In principle, we have an almost pluggable architecture. See for example
the latter part of the 2nd post in
http://article.gmane.org/gmane.comp.version-control.git/175127
Unless you want to change git itself, you're probably better off storing
your non-gpg signatures in a note (or a self-created signed tag). To
sign the commit rev, you could sign the output of "git cat-file commit
rev" (or of "git rev-parse rev") and store that signature in a note that
commit. To verify, you verify the note against the commit.
Michael
^ permalink raw reply
* A note from the (interim) maintainer
From: Jeff King @ 2012-10-24 9:01 UTC (permalink / raw)
To: git
Since Junio is gone for a few weeks, I'll be doing my best to fill in.
My plan is to pick up topics from the list and keep development moving
on "master" and "next". I'm not planning on cutting any releases, which
should be fine unless some emergency comes up which would require a
quick v1.8.0.1.
I'll publish my branches at:
git://github.com/peff/git.git
There's nothing new there yet. Now that the 1.8.0 dust has settled, I'm
going to start graduating existing topics to master, according to the
comments from the latest "What's Cooking" messages. I'll also rewind
"next" soon-ish.
I've picked up a few topics from the list already, but there's some
backlog. My goal for Wednesday is to process the rest of that, push out
an integration cycle, and then send out a What's Cooking with the
current state. If you have a topic in flight with no response, I
probably just haven't looked at it yet. If you don't see it in the next
WC, though, I probably missed it and you should resend.
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-24 8:46 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <1351065815-22416-1-git-send-email-krzysiek@podlesie.net>
On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
> The git-send-email always use RFC2047 subject quoting for files
> with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
> even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
> skipped.
> [...]
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> + ($subject =~ /[^[:ascii:]]/)) {
Is that test sufficient? We would also need to encode if it has rfc2047
specials, no?
It looks like we use the same regex elsewhere. Maybe this would be a
good chance to abstract out a needs_rfc2047_quoting while we are in the
area?
Other than that, I did not see anything wrong with the patch.
-Peff
^ permalink raw reply
* Re: [PATCH 7/9] pretty: support padding placeholders, %< %> and %><
From: Jeff King @ 2012-10-24 8:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1348391433-11300-8-git-send-email-pclouds@gmail.com>
On Sun, Sep 23, 2012 at 04:10:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> + else {
> + int sb_len = sb->len, offset;
> + switch (c->flush_type) {
> + case flush_left:
> + offset = padding - len;
> + break;
> + case flush_right:
> + offset = 0;
> + break;
> + case flush_both:
> + offset = (padding - len) / 2;
> + break;
> + case no_flush: /* to make gcc happy */
> + break;
> + }
> + /*
> + * we calculate padding in columns, now
> + * convert it back to chars
> + */
> + padding = padding - len + local_sb.len;
> + strbuf_grow(sb, padding);
> + strbuf_setlen(sb, sb_len + padding);
> + memset(sb->buf + sb_len, ' ', sb->len - sb_len);
> + memcpy(sb->buf + sb_len + offset, local_sb.buf,
> + local_sb.len);
> + }
gcc complains (rightly, I think) that offset can be used uninitialized
in the final line (looks like it is from the no_flush case). If it is a
"can never happen" case that is there to appease gcc in the switch
statement, should we drop a die("BUG: XXX") there? If so, what would the
XXX be?
-Peff
^ 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