* Error after calling git difftool -d with
From: P. Duijst @ 2016-12-02 12:15 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
Dear,
Incase filenames are used with a quote ' or a bracket [ (and maybe some
more characters), git "diff" and "difftool -y" works fine, but git
*difftool **-d* gives the next error message:
peter@scm_ws_10 MINGW64 /d/Dev/test (master)
$ git diff
diff --git a/Test ''inch.txt b/Test ''inch.txt
index dbff793..41f3257 100644
--- a/Test ''inch.txt
+++ b/Test ''inch.txt
@@ -1 +1,3 @@
+
+ddd
Test error in simple repository
warning: LF will be replaced by CRLF in Test ''inch.txt.
The file will have its original line endings in your working directory.
peter@scm_ws_10 MINGW64 /d/Dev/test (master)
*$ git difftool -d*
*fatal: Cannot open '/d/Dev/test//Test ''inch.txt': No such file or
directory*
*hash-object /d/Dev/test//Test ''inch.txt: command returned error: 128*
peter@scm_ws_10 MINGW64 /d/Dev/test (master)
$
This issue is inside V2.10.x and V2.11.0.
V2.9.0 is working correctly...
I am using git for windows and beyond compare 4.0 as difftool.
Best regards,
Peter
[-- Attachment #2: IssueWithFiles.zip --]
[-- Type: application/zip, Size: 13922 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] convert: git cherry-pick -Xrenormalize did not work
From: Torsten Bögershausen @ 2016-12-02 12:20 UTC (permalink / raw)
To: Junio C Hamano, Jacob Keller; +Cc: Git mailing list, eevee.reply
In-Reply-To: <xmqqtwan8kjv.fsf@gitster.mtv.corp.google.com>
> Yup, this is what I queued.
>
Looks good, thanks you all.
^ permalink raw reply
* Re: "Your branch is ahead of 'origin' by X commits"
From: Matthieu Moy @ 2016-12-02 13:42 UTC (permalink / raw)
To: Alfonsogonzalez, Ernesto (GE Digital); +Cc: git@vger.kernel.org
In-Reply-To: <D465BDE6.B7DE%ernesto.alfonsogonzalez@ge.com>
"Alfonsogonzalez, Ernesto (GE Digital)" <ernesto.alfonsogonzalez@ge.com>
writes:
> Hi,
>
> Git status tells me "Your branch is ahead of 'origin' by 108 commits.²,
> but my local and origin/master are pointing to the same commit.
>
> What am I doing wrong?
>
> $ git diff origin/master
> $ git status
> On branch master
> Your branch is ahead of 'origin' by 108 commits.
This line should say "ahead of 'origin/master'" in common setups, where
'origin/master' is the remote-tracking branch configured as upstream for
'master'.
My guess is that you have a badly configured upstream.
What does "git pull -v" say? What's the content of the [branch "master"]
section of .git/config?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Error after calling git difftool -d with
From: Johannes Schindelin @ 2016-12-02 16:05 UTC (permalink / raw)
To: P. Duijst; +Cc: git
In-Reply-To: <5f630c90-cf54-3a23-c9a9-af035d4514e0@gmail.com>
Hi Peter,
On Fri, 2 Dec 2016, P. Duijst wrote:
> Incase filenames are used with a quote ' or a bracket [ (and maybe some more
> characters), git "diff" and "difftool -y" works fine, but git *difftool **-d*
> gives the next error message:
>
> peter@scm_ws_10 MINGW64 /d/Dev/test (master)
> $ git diff
> diff --git a/Test ''inch.txt b/Test ''inch.txt
> index dbff793..41f3257 100644
> --- a/Test ''inch.txt
> +++ b/Test ''inch.txt
> @@ -1 +1,3 @@
> +
> +ddd
> Test error in simple repository
> warning: LF will be replaced by CRLF in Test ''inch.txt.
> The file will have its original line endings in your working directory.
>
> peter@scm_ws_10 MINGW64 /d/Dev/test (master)
> *$ git difftool -d*
> *fatal: Cannot open '/d/Dev/test//Test ''inch.txt': No such file or
> directory*
> *hash-object /d/Dev/test//Test ''inch.txt: command returned error: 128*
>
> peter@scm_ws_10 MINGW64 /d/Dev/test (master)
> $
>
>
> This issue is inside V2.10.x and V2.11.0.
> V2.9.0 is working correctly...
You say v2.11.0, but did you also try the new, experimental builtin
difftool? You can test without reinstalling:
git -c difftool.useBuiltin=true difftool -d ...
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v7 4/4] transport: add from_user parameter to is_transport_allowed
From: Brandon Williams @ 2016-12-02 17:33 UTC (permalink / raw)
To: Jeff King; +Cc: git, sbeller, bburky, jrnieder
In-Reply-To: <20161202001353.jiw4hjqg75dr6psw@sigill.intra.peff.net>
On 12/01, Jeff King wrote:
> On Thu, Dec 01, 2016 at 03:26:56PM -0800, Brandon Williams wrote:
>
> > > I started taking a look at your http redirect series (I really should
> > > have taking a look at it sooner) and I see exactly what you're talking
> > > about. We can easily move this logic into a function to make it easier
> > > to generate the two whitelists.
> >
> > Thinking about this some more...I was told that having http redirect to
> > file:// could be scary. The way the new protocol configuration is setup
> > we have file:// as a default known-safe protocol. Do we need to worry
> > about this or can we leave this be since this can be overridden by the
> > user?
>
> Hmm. I'm not sure if file:// should actually be USER_ONLY. The submodule
> code allows it, and it's certainly a convenience, but I guess you could
> do tricky things by probing somebody's filesystem with submodules URLs.
> On the other hand, if you are recursively cloning untrusted repos and
> have sensitive contents on disk, you really _should_ be setting up a
> protocol whitelist.
>
> For HTTP redirects within curl, I think it's a non-issue; curl
> automatically disallows file:// for redirects, even without us telling
> it so.
>
> For redirects via http-alternates, it's a bit more tricky, as we feed
> the URL to curl ourselves, so it can't tell the difference between
> trusted and untrusted input. The main protection provided by my series
> is "don't follow http-alternates at all". But assuming you did want to
> use them (by setting http.followRedirects to "true", at least for the
> server in question), we could then feed file:// directly to curl. But I
> think we are still OK, because the restricted CURLOPT_PROTOCOL setting
> would prevent that from working. I.e., git _never_ wants curl to handle
> file://, because it handles it without calling into remote-curl.c at
> all.
>
> So arguably file:// should be USER_ONLY, but I'm not sure how much it
> matters in practice.
Ah ok thanks for the good explanation. I was mostly interested in the
http redirect case which, as you said, becomes a non-issue due to how we
configure curl.
Thanks!
--
Brandon Williams
^ permalink raw reply
* Where is Doc to configure Git + Apache + kerberos for Project level access in repo?
From: ken edward @ 2016-12-02 18:15 UTC (permalink / raw)
To: git
Where is Doc to configure Git + Apache + kerberos for Project level
access in repo?
^ permalink raw reply
* git 2.11.0 error when pushing to remote located on a windows share
From: thomas.attwood @ 2016-12-02 18:02 UTC (permalink / raw)
To: git
After updating git from 2.10.0 to 2.11.0 when trying to push any changes to a repo located in a windows share, the following error occurs:
$ git push origin test
Counting objects: 2, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 284 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 1 (delta 0)
remote: error: object directory /path/to/dir/objects does not exist; check .git/objects/info/alternates.
remote: fatal: unresolved deltas left after unpacking
error: unpack failed: unpack-objects abnormal exit
To //path/to/dir
! [remote rejected] test -> test (unpacker error)
error: failed to push some refs to '//path/to/dir'
No error occurs if pushing to the same repo (a direct copy into a local directory) using 2.11.0.
$ git push local_test test
Counting objects: 2, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 284 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 1 (delta 0)
To C:/path/to/dir
* [new branch] test -> test
---
git remotes:
$ git remote -v
local_test C:/path/to/dir (fetch)
local_test C:/path/to/dir (push)
origin //path/to/dir (fetch)
origin //path/to/dir (push)
---
Using `git fsck --full` in both 2.11.0 and 2.10.0, it doesn't reveal any additional problems.
$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (2710/2710), done.
---
I'm not sure if it's related but ` object directory /path/to/dir/objects does not exist` doesn't contain an expected second slash.
Thomas 'Panda' Attwood.
^ permalink raw reply
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Brandon Williams @ 2016-12-02 18:36 UTC (permalink / raw)
To: Jeff King
Cc: Stefan Beller, Junio C Hamano, git@vger.kernel.org, Jonathan Tan
In-Reply-To: <20161201215934.g7dt5ioekmx6ssii@sigill.intra.peff.net>
On 12/01, Jeff King wrote:
> On Thu, Dec 01, 2016 at 01:56:32PM -0800, Stefan Beller wrote:
>
> > > Bleh. Looks like it happens as part of the recently-added
> > > get_common_dir(). I'm not sure if that is ever relevant for submodules,
> > > but I guess in theory you could have a submodule clone that is part of a
> > > worktree?
> >
> > Sure we can, for a test that we don't have that, see the embedgitdirs series. ;)
> >
> > For now each submodule has its own complete git dir, but the vision
> > would be to have a common git dir for submodules in the common
> > superprojects git dir as well, such that objects are shared actually. :)
>
> Fair enough. Given that it seems to behave OK even in error cases, the
> simple stat() test may be the best option, then. I do think we should
> consider adding a few test cases to make sure it continues to behave in
> the error cases (just because we are relying partially on what git's
> setup code happens to do currently, and we'd want to protect ourselves
> against regressions).
For the naive (ie me), is there a reason why real_path() couldn't be
re-implemented to avoid using chdir? I tried looking into the history of
the function but couldn't find anything explaining why it was done that
way. I assume it has to do with symlinks, but I thought there was a
syscall (readlink?) that could do the resolution.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Jacob Keller @ 2016-12-02 18:44 UTC (permalink / raw)
To: Brandon Williams
Cc: Jeff King, Stefan Beller, Junio C Hamano, git@vger.kernel.org,
Jonathan Tan
In-Reply-To: <20161202183622.GB117792@google.com>
On Fri, Dec 2, 2016 at 10:36 AM, Brandon Williams <bmwill@google.com> wrote:
> On 12/01, Jeff King wrote:
>> On Thu, Dec 01, 2016 at 01:56:32PM -0800, Stefan Beller wrote:
>>
>> > > Bleh. Looks like it happens as part of the recently-added
>> > > get_common_dir(). I'm not sure if that is ever relevant for submodules,
>> > > but I guess in theory you could have a submodule clone that is part of a
>> > > worktree?
>> >
>> > Sure we can, for a test that we don't have that, see the embedgitdirs series. ;)
>> >
>> > For now each submodule has its own complete git dir, but the vision
>> > would be to have a common git dir for submodules in the common
>> > superprojects git dir as well, such that objects are shared actually. :)
>>
>> Fair enough. Given that it seems to behave OK even in error cases, the
>> simple stat() test may be the best option, then. I do think we should
>> consider adding a few test cases to make sure it continues to behave in
>> the error cases (just because we are relying partially on what git's
>> setup code happens to do currently, and we'd want to protect ourselves
>> against regressions).
>
> For the naive (ie me), is there a reason why real_path() couldn't be
> re-implemented to avoid using chdir? I tried looking into the history of
> the function but couldn't find anything explaining why it was done that
> way. I assume it has to do with symlinks, but I thought there was a
> syscall (readlink?) that could do the resolution.
>
> --
> Brandon Williams
The reason as far as I understand it, is that it uses chdir() to
guarantee that it follows symlinks correctly and then looks up the
resulting path after the chdir(). I do not think there is a syscall
that actually correctly works like real_path() does. You *could*
re-write real_path() to do the symlink lookups itself, but as Jeff
recently pointed out, that way lies madness.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Brandon Williams @ 2016-12-02 18:49 UTC (permalink / raw)
To: Jacob Keller
Cc: Jeff King, Stefan Beller, Junio C Hamano, git@vger.kernel.org,
Jonathan Tan
In-Reply-To: <CA+P7+xpoO=ieRyQb8r8Xz12nN10f53LKeVMgAO8XPdSwvG7fuA@mail.gmail.com>
On 12/02, Jacob Keller wrote:
> On Fri, Dec 2, 2016 at 10:36 AM, Brandon Williams <bmwill@google.com> wrote:
> > On 12/01, Jeff King wrote:
> >> On Thu, Dec 01, 2016 at 01:56:32PM -0800, Stefan Beller wrote:
> >>
> >> > > Bleh. Looks like it happens as part of the recently-added
> >> > > get_common_dir(). I'm not sure if that is ever relevant for submodules,
> >> > > but I guess in theory you could have a submodule clone that is part of a
> >> > > worktree?
> >> >
> >> > Sure we can, for a test that we don't have that, see the embedgitdirs series. ;)
> >> >
> >> > For now each submodule has its own complete git dir, but the vision
> >> > would be to have a common git dir for submodules in the common
> >> > superprojects git dir as well, such that objects are shared actually. :)
> >>
> >> Fair enough. Given that it seems to behave OK even in error cases, the
> >> simple stat() test may be the best option, then. I do think we should
> >> consider adding a few test cases to make sure it continues to behave in
> >> the error cases (just because we are relying partially on what git's
> >> setup code happens to do currently, and we'd want to protect ourselves
> >> against regressions).
> >
> > For the naive (ie me), is there a reason why real_path() couldn't be
> > re-implemented to avoid using chdir? I tried looking into the history of
> > the function but couldn't find anything explaining why it was done that
> > way. I assume it has to do with symlinks, but I thought there was a
> > syscall (readlink?) that could do the resolution.
> >
> > --
> > Brandon Williams
>
> The reason as far as I understand it, is that it uses chdir() to
> guarantee that it follows symlinks correctly and then looks up the
> resulting path after the chdir(). I do not think there is a syscall
> that actually correctly works like real_path() does. You *could*
> re-write real_path() to do the symlink lookups itself, but as Jeff
> recently pointed out, that way lies madness.
So is there a reason why the library function realpath() can't be used?
From a cursory look at its man page it seems to do the symlink
resolution.
--
Brandon Williams
^ permalink raw reply
* [PATCH v2] diff: handle --no-abbrev outside of repository
From: Jack Bates @ 2016-12-02 18:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Jack Bates
In-Reply-To: <20161129070637.eult6o3m34r2mima@sigill.intra.peff.net>
The "git diff --no-index" codepath didn't handle the --no-abbrev option.
Also it didn't behave the same as find_unique_abbrev()
in the case where abbrev == 0.
find_unique_abbrev() returns the full, unabbreviated string in that
case, but the "git diff --no-index" codepath returned an empty string.
Signed-off-by: Jack Bates <jack@nottheoilrig.com>
---
diff.c | 6 +++++-
t/t4013-diff-various.sh | 7 +++++++
t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir | 3 +++
t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
t/t4013/diff.diff_--raw_--abbrev=4_initial | 6 ++++++
t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++++++
t/t4013/diff.diff_--raw_initial | 6 ++++++
8 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
create mode 100644 t/t4013/diff.diff_--raw_initial
diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
- hex[abbrev] = '\0';
+ if (abbrev)
+ hex[abbrev] = '\0';
return hex;
}
}
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)
options->file = stdout;
+ options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+ else if (!strcmp(arg, "--no-abbrev"))
+ options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", &arg)) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d7b71a0 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
diff --dirstat master~1 master~2
diff --dirstat initial rearrange
diff --dirstat-by-file initial rearrange
+# --abbrev and --no-abbrev outside of repository
+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
EOF
test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 0000000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:000000 100644 0000... 0000... A dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir b/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
new file mode 100644
index 0000000..e0f0097
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --no-abbrev dir2 dir
+:000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_dir2_dir b/t/t4013/diff.diff_--no-index_--raw_dir2_dir
new file mode 100644
index 0000000..3cb4ee7
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw dir2 dir
+:000000 100644 0000000... 0000000... A dir/sub
+$
diff --git a/t/t4013/diff.diff_--raw_--abbrev=4_initial b/t/t4013/diff.diff_--raw_--abbrev=4_initial
new file mode 100644
index 0000000..c3641db
--- /dev/null
+++ b/t/t4013/diff.diff_--raw_--abbrev=4_initial
@@ -0,0 +1,6 @@
+$ git diff --raw --abbrev=4 initial
+:100644 100644 35d2... 9929... M dir/sub
+:100644 100644 01e7... 10a8... M file0
+:000000 100644 0000... b1e6... A file1
+:100644 000000 01e7... 0000... D file2
+$
diff --git a/t/t4013/diff.diff_--raw_--no-abbrev_initial b/t/t4013/diff.diff_--raw_--no-abbrev_initial
new file mode 100644
index 0000000..c87a125
--- /dev/null
+++ b/t/t4013/diff.diff_--raw_--no-abbrev_initial
@@ -0,0 +1,6 @@
+$ git diff --raw --no-abbrev initial
+:100644 100644 35d242ba79ae89ac695e26b3d4c27a8e6f028f9e 992913c5aa0a5476d10c49ed0f21fc0c6d1aedf3 M dir/sub
+:100644 100644 01e79c32a8c99c557f0757da7cb6d65b3414466d 10a8a9f3657f91a156b9f0184ed79a20adef9f7f M file0
+:000000 100644 0000000000000000000000000000000000000000 b1e67221afe8461efd244b487afca22d46b95eb8 A file1
+:100644 000000 01e79c32a8c99c557f0757da7cb6d65b3414466d 0000000000000000000000000000000000000000 D file2
+$
diff --git a/t/t4013/diff.diff_--raw_initial b/t/t4013/diff.diff_--raw_initial
new file mode 100644
index 0000000..a3e9780
--- /dev/null
+++ b/t/t4013/diff.diff_--raw_initial
@@ -0,0 +1,6 @@
+$ git diff --raw initial
+:100644 100644 35d242b... 992913c... M dir/sub
+:100644 100644 01e79c3... 10a8a9f... M file0
+:000000 100644 0000000... b1e6722... A file1
+:100644 000000 01e79c3... 0000000... D file2
+$
--
2.10.2
^ permalink raw reply related
* [PATCH] unpack-trees: fix grammar for untracked files in directories
From: Stefan Beller @ 2016-12-02 19:17 UTC (permalink / raw)
To: gitster; +Cc: git, dturner, Stefan Beller
Noticed-by: David Turner <dturner@twosigma.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
This was noticed by David when reviewing the submodule checkout series,
though rolling this as an independent fix is better :)
Thanks,
Stefan
t/t7609-merge-co-error-msgs.sh | 2 +-
unpack-trees.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7609-merge-co-error-msgs.sh b/t/t7609-merge-co-error-msgs.sh
index f80bdb81e1..e90413204e 100755
--- a/t/t7609-merge-co-error-msgs.sh
+++ b/t/t7609-merge-co-error-msgs.sh
@@ -105,7 +105,7 @@ test_expect_success 'not uptodate file porcelain checkout error' '
'
cat >expect <<\EOF
-error: Updating the following directories would lose untracked files in it:
+error: Updating the following directories would lose untracked files in them:
rep
rep2
diff --git a/unpack-trees.c b/unpack-trees.c
index ea6bdd20e0..7a6df99d10 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -78,7 +78,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
xstrfmt(msg, cmd, cmd);
msgs[ERROR_NOT_UPTODATE_DIR] =
- _("Updating the following directories would lose untracked files in it:\n%s");
+ _("Updating the following directories would lose untracked files in them:\n%s");
if (!strcmp(cmd, "checkout"))
msg = advice_commit_before_merge
--
2.10.2.613.g22f2156
^ permalink raw reply related
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Jacob Keller @ 2016-12-02 19:20 UTC (permalink / raw)
To: Brandon Williams
Cc: Jeff King, Stefan Beller, Junio C Hamano, git@vger.kernel.org,
Jonathan Tan
In-Reply-To: <20161202184944.GC117792@google.com>
On Fri, Dec 2, 2016 at 10:49 AM, Brandon Williams <bmwill@google.com> wrote:
> On 12/02, Jacob Keller wrote:
>> On Fri, Dec 2, 2016 at 10:36 AM, Brandon Williams <bmwill@google.com> wrote:
>> > On 12/01, Jeff King wrote:
>> >> On Thu, Dec 01, 2016 at 01:56:32PM -0800, Stefan Beller wrote:
>> >>
>> >> > > Bleh. Looks like it happens as part of the recently-added
>> >> > > get_common_dir(). I'm not sure if that is ever relevant for submodules,
>> >> > > but I guess in theory you could have a submodule clone that is part of a
>> >> > > worktree?
>> >> >
>> >> > Sure we can, for a test that we don't have that, see the embedgitdirs series. ;)
>> >> >
>> >> > For now each submodule has its own complete git dir, but the vision
>> >> > would be to have a common git dir for submodules in the common
>> >> > superprojects git dir as well, such that objects are shared actually. :)
>> >>
>> >> Fair enough. Given that it seems to behave OK even in error cases, the
>> >> simple stat() test may be the best option, then. I do think we should
>> >> consider adding a few test cases to make sure it continues to behave in
>> >> the error cases (just because we are relying partially on what git's
>> >> setup code happens to do currently, and we'd want to protect ourselves
>> >> against regressions).
>> >
>> > For the naive (ie me), is there a reason why real_path() couldn't be
>> > re-implemented to avoid using chdir? I tried looking into the history of
>> > the function but couldn't find anything explaining why it was done that
>> > way. I assume it has to do with symlinks, but I thought there was a
>> > syscall (readlink?) that could do the resolution.
>> >
>> > --
>> > Brandon Williams
>>
>> The reason as far as I understand it, is that it uses chdir() to
>> guarantee that it follows symlinks correctly and then looks up the
>> resulting path after the chdir(). I do not think there is a syscall
>> that actually correctly works like real_path() does. You *could*
>> re-write real_path() to do the symlink lookups itself, but as Jeff
>> recently pointed out, that way lies madness.
>
> So is there a reason why the library function realpath() can't be used?
> From a cursory look at its man page it seems to do the symlink
> resolution.
>
> --
> Brandon Williams
I believe it uses the same method and thus wouldn't actually resolve
the issue. But I'm not really 100% sure on this.
Thanks,
Jake
^ permalink raw reply
* RE: [PATCH] unpack-trees: fix grammar for untracked files in directories
From: David Turner @ 2016-12-02 19:23 UTC (permalink / raw)
To: 'Stefan Beller', gitster@pobox.com; +Cc: git@vger.kernel.org
In-Reply-To: <20161202191741.12693-1-sbeller@google.com>
LGTM.
> -----Original Message-----
> From: Stefan Beller [mailto:sbeller@google.com]
> Sent: Friday, December 02, 2016 2:18 PM
> To: gitster@pobox.com
> Cc: git@vger.kernel.org; David Turner; Stefan Beller
> Subject: [PATCH] unpack-trees: fix grammar for untracked files in
> directories
>
> Noticed-by: David Turner <dturner@twosigma.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> This was noticed by David when reviewing the submodule checkout series,
> though rolling this as an independent fix is better :)
>
> Thanks,
> Stefan
>
> t/t7609-merge-co-error-msgs.sh | 2 +-
> unpack-trees.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7609-merge-co-error-msgs.sh b/t/t7609-merge-co-error-
> msgs.sh index f80bdb81e1..e90413204e 100755
> --- a/t/t7609-merge-co-error-msgs.sh
> +++ b/t/t7609-merge-co-error-msgs.sh
> @@ -105,7 +105,7 @@ test_expect_success 'not uptodate file porcelain
> checkout error' '
> '
>
> cat >expect <<\EOF
> -error: Updating the following directories would lose untracked files in
> it:
> +error: Updating the following directories would lose untracked files in
> them:
> rep
> rep2
>
> diff --git a/unpack-trees.c b/unpack-trees.c index ea6bdd20e0..7a6df99d10
> 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -78,7 +78,7 @@ void setup_unpack_trees_porcelain(struct
> unpack_trees_options *opts,
> xstrfmt(msg, cmd, cmd);
>
> msgs[ERROR_NOT_UPTODATE_DIR] =
> - _("Updating the following directories would lose untracked
> files in it:\n%s");
> + _("Updating the following directories would lose untracked
> files in
> +them:\n%s");
>
> if (!strcmp(cmd, "checkout"))
> msg = advice_commit_before_merge
> --
> 2.10.2.613.g22f2156
^ permalink raw reply
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Stefan Beller @ 2016-12-02 19:28 UTC (permalink / raw)
To: Jacob Keller
Cc: Brandon Williams, Jeff King, Junio C Hamano, git@vger.kernel.org,
Jonathan Tan
In-Reply-To: <CA+P7+xoi_UNSv-dKVFWf7T4o3uBtGa0wR6=nnYX+kjzLAmw6ug@mail.gmail.com>
On Fri, Dec 2, 2016 at 11:20 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>
>> So is there a reason why the library function realpath() can't be used?
>> From a cursory look at its man page it seems to do the symlink
>> resolution.
>>
>> --
>> Brandon Williams
>
> I believe it uses the same method and thus wouldn't actually resolve
> the issue. But I'm not really 100% sure on this.
>
> Thanks,
> Jake
I just reviewed 2 libc implementations (glibc and an Android libc) and
both of them
do not use chdir internally, but use readlink and compose the path 'manually'
c.f. http://osxr.org:8080/glibc/source/stdlib/canonicalize.c?v=glibc-2.13
^ permalink raw reply
* Re: EXT: Re: "Your branch is ahead of 'origin' by X commits"
From: Alfonsogonzalez, Ernesto (GE Digital) @ 2016-12-02 18:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git@vger.kernel.org
Hi Matthieu,
It was my mistake, I had a local branch called “origin” which was the
upstream for master.
I sent more details in a later email, reproduced below. Sorry for the
false alarm.
Thanks,
Ernesto
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>
Yes, it looks like I had a local branch “origin” which was behind by 108
commits.
Setting upstream to the local branch correctly states "track local branch
origin”.
It was my mistake, there is no bug.
Thanks,
$ git rev-parse --symbolic-full-name origin
refs/heads/origin
# origin is a local branch
$ git show refs/heads/origin
commit ad8c3ee6cb7740627e4ecddb418c826bc8597d3d # old commit, 108 commits
behind master
$ git branch
...
* master
...
origin
...
$ git show origin
commit ad8c3ee6cb7740627e4ecddb418c826bc8597d3d
Merge: e16bda3 4b7564d
$ git branch --set-upstream-to=origin/master
Branch master set up to track remote branch master from origin
$ git branch --set-upstream-to=origin #correctly says "track local branch
origin"
Branch master set up to track local branch origin.
$ git status
On branch master
Your branch is ahead of 'origin' by 108 commits.
(use "git push" to publish your local commits)
Untracked files:
(use "git add <file>..." to include in what will be committed)
...
nothing added to commit but untracked files present (use "git add" to
track)
$ git branch -d origin
Deleted branch origin (was ad8c3ee).
$
$ git status
On branch master
Your branch is based on 'origin', but the upstream is gone.
(use "git branch --unset-upstream" to fixup)
On 12/2/16, 5:42 AM, "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr> wrote:
>"Alfonsogonzalez, Ernesto (GE Digital)" <ernesto.alfonsogonzalez@ge.com>
>writes:
>
>> Hi,
>>
>> Git status tells me "Your branch is ahead of 'origin' by 108 commits.²,
>> but my local and origin/master are pointing to the same commit.
>>
>> What am I doing wrong?
>>
>> $ git diff origin/master
>> $ git status
>> On branch master
>> Your branch is ahead of 'origin' by 108 commits.
>
>This line should say "ahead of 'origin/master'" in common setups, where
>'origin/master' is the remote-tracking branch configured as upstream for
>'master'.
>
>My guess is that you have a badly configured upstream.
>
>What does "git pull -v" say? What's the content of the [branch "master"]
>section of .git/config?
>
>--
>Matthieu Moy
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www-2Dverimag.imag.fr_
>-7Emoy_&d=DQIDAw&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=izgsnUPc7
>Qu6cAMH0HZnmitAbT-LmaLVojOu8tH2KqE&m=0Kz9dpPPuw6T-zLqzY80QygN-4VoMVQeauR_x
>WR5fN8&s=DnD-WMGSm71Y05CEheJw-NdYA0FVP2ze6KqWxrEKswE&e=
^ permalink raw reply
* [PATCH] t3600: remove useless redirect
From: Stefan Beller @ 2016-12-02 20:05 UTC (permalink / raw)
To: gitster; +Cc: git, bmwill, Stefan Beller
In the next line the `actual` is overwritten again, so no need to redirect
the output of checkout into that file.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t3600-rm.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 14f0edca2b..6e587f956f 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -709,7 +709,7 @@ test_expect_success 'checking out a commit after submodule removal needs manual
git commit -m "submodule removal" submod &&
git checkout HEAD^ &&
git submodule update &&
- git checkout -q HEAD^ 2>actual &&
+ git checkout -q HEAD^ &&
git checkout -q master 2>actual &&
test_i18ngrep "^warning: unable to rmdir submod:" actual &&
git status -s submod >actual &&
--
2.10.2.613.g22f2156
^ permalink raw reply related
* [PATCH 2/4] shallow.c: avoid theoretical pointer wrap-around
From: Rasmus Villemoes @ 2016-12-02 20:31 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Jeff King,
Rasmus Villemoes
In-Reply-To: <1480710664-26290-1-git-send-email-rv@rasmusvillemoes.dk>
The expression info->free+size is technically undefined behaviour in
exactly the case we want to test for. Moreover, the compiler is likely
to translate the expression to
(unsigned long)info->free + size > (unsigned long)info->end
where there's at least a theoretical chance that the LHS could wrap
around 0, giving a false negative.
This might as well be written using pointer subtraction avoiding these
issues.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
---
shallow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/shallow.c b/shallow.c
index e21534a..8b1c35d 100644
--- a/shallow.c
+++ b/shallow.c
@@ -444,7 +444,7 @@ static uint32_t *paint_alloc(struct paint_info *info)
unsigned nr = (info->nr_bits + 31) / 32;
unsigned size = nr * sizeof(uint32_t);
void *p;
- if (!info->slab_count || info->free + size > info->end) {
+ if (!info->slab_count || size > info->end - info->free) {
unsigned alloc_size = size < COMMIT_SLAB_SIZE ?
COMMIT_SLAB_SIZE : size;
info->slab_count++;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] shallow.c: bit manipulation tweaks
From: Rasmus Villemoes @ 2016-12-02 20:31 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Jeff King,
Rasmus Villemoes
In-Reply-To: <1480710664-26290-1-git-send-email-rv@rasmusvillemoes.dk>
First of all, 1 << 31 is technically undefined behaviour, so let's just
use an unsigned literal.
If i is 'signed int' and gcc doesn't know that i is positive, gcc
generates code to compute the C99-mandated values of "i / 32" and "i %
32", which is a lot more complicated than simple a simple shifts/mask.
The only caller of paint_down actually passes an "unsigned int" value,
but the prototype of paint_down causes (completely well-defined)
conversion to signed int, and gcc has no way of knowing that the
converted value is non-negative. Just make the id parameter unsigned.
In update_refstatus, the change in generated code is much smaller,
presumably because gcc is smart enough to see that i starts as 0 and is
only incremented, so it is allowed (per the UD of signed overflow) to
assume that i is always non-negative. But let's just help less smart
compilers generate good code anyway.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
---
shallow.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/shallow.c b/shallow.c
index 8b1c35d..5aec5a5 100644
--- a/shallow.c
+++ b/shallow.c
@@ -464,7 +464,7 @@ static uint32_t *paint_alloc(struct paint_info *info)
* all walked commits.
*/
static void paint_down(struct paint_info *info, const unsigned char *sha1,
- int id)
+ unsigned int id)
{
unsigned int i, nr;
struct commit_list *head = NULL;
@@ -476,7 +476,7 @@ static void paint_down(struct paint_info *info, const unsigned char *sha1,
if (!c)
return;
memset(bitmap, 0, bitmap_size);
- bitmap[id / 32] |= (1 << (id % 32));
+ bitmap[id / 32] |= (1U << (id % 32));
commit_list_insert(c, &head);
while (head) {
struct commit_list *p;
@@ -650,11 +650,11 @@ static int add_ref(const char *refname, const struct object_id *oid,
static void update_refstatus(int *ref_status, int nr, uint32_t *bitmap)
{
- int i;
+ unsigned int i;
if (!ref_status)
return;
for (i = 0; i < nr; i++)
- if (bitmap[i / 32] & (1 << (i % 32)))
+ if (bitmap[i / 32] & (1U << (i % 32)))
ref_status[i]++;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 4/4] shallow.c: remove useless test
From: Rasmus Villemoes @ 2016-12-02 20:31 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Jeff King,
Rasmus Villemoes
In-Reply-To: <1480710664-26290-1-git-send-email-rv@rasmusvillemoes.dk>
It seems to be odd to do x=y if x==y. Maybe there's a bug somewhere near
this, but as is this is somewhat confusing.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
---
shallow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/shallow.c b/shallow.c
index 5aec5a5..7c28239 100644
--- a/shallow.c
+++ b/shallow.c
@@ -513,7 +513,7 @@ static void paint_down(struct paint_info *info, const unsigned char *sha1,
p->item);
if (p->item->object.flags & SEEN)
continue;
- if (*p_refs == NULL || *p_refs == *refs)
+ if (*p_refs == NULL)
*p_refs = *refs;
commit_list_insert(p->item, &head);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] shallow.c: make paint_alloc slightly more robust
From: Rasmus Villemoes @ 2016-12-02 20:31 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Jeff King,
Rasmus Villemoes
I have no idea if this is a real issue, but it's not obvious to me that
paint_alloc cannot be called with info->nr_bits greater than about
4M (\approx 8*COMMIT_SLAB_SIZE). In that case the new slab would be too
small. So just round up the allocation to the maximum of
COMMIT_SLAB_SIZE and size.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
---
shallow.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index 4d0b005..e21534a 100644
--- a/shallow.c
+++ b/shallow.c
@@ -445,11 +445,13 @@ static uint32_t *paint_alloc(struct paint_info *info)
unsigned size = nr * sizeof(uint32_t);
void *p;
if (!info->slab_count || info->free + size > info->end) {
+ unsigned alloc_size = size < COMMIT_SLAB_SIZE ?
+ COMMIT_SLAB_SIZE : size;
info->slab_count++;
REALLOC_ARRAY(info->slab, info->slab_count);
- info->free = xmalloc(COMMIT_SLAB_SIZE);
+ info->free = xmalloc(alloc_size);
info->slab[info->slab_count - 1] = info->free;
- info->end = info->free + COMMIT_SLAB_SIZE;
+ info->end = info->free + alloc_size;
}
p = info->free;
info->free += size;
--
2.1.4
^ permalink raw reply related
* [PATCH] worktree: mark a file-local symbol with static
From: Ramsay Jones @ 2016-12-02 20:55 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---
Hi Stefan,
If you need to re-roll your 'sb/submodule-intern-gitdir'
branch, could you please squash something similar to this
into the relevant patch (commit 2529715dc, "worktree: get
worktrees from submodules", 01-12-2016).
[This is based on pu; ie. on top of merge 86c7f863a, where
Junio as added the 'flags' parameter.]
Thanks!
ATB,
Ramsay Jones
worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/worktree.c b/worktree.c
index d5c71095e..ba393fe5c 100644
--- a/worktree.c
+++ b/worktree.c
@@ -168,7 +168,7 @@ static int compare_worktree(const void *a_, const void *b_)
return fspathcmp((*a)->path, (*b)->path);
}
-struct worktree **get_worktrees_internal(const char *git_common_dir, unsigned flags)
+static struct worktree **get_worktrees_internal(const char *git_common_dir, unsigned flags)
{
struct worktree **list = NULL;
struct strbuf path = STRBUF_INIT;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 1/6] submodules: add helper functions to determine presence of submodules
From: Jacob Keller @ 2016-12-02 21:31 UTC (permalink / raw)
To: Stefan Beller
Cc: Brandon Williams, Jeff King, Junio C Hamano, git@vger.kernel.org,
Jonathan Tan
In-Reply-To: <CAGZ79kYPpc0=NAJaNPW+8faszOPAkq=b3m-EopY5A8oFwh+9=g@mail.gmail.com>
On Fri, Dec 2, 2016 at 11:28 AM, Stefan Beller <sbeller@google.com> wrote:
> On Fri, Dec 2, 2016 at 11:20 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>>
>>> So is there a reason why the library function realpath() can't be used?
>>> From a cursory look at its man page it seems to do the symlink
>>> resolution.
>>>
>>> --
>>> Brandon Williams
>>
>> I believe it uses the same method and thus wouldn't actually resolve
>> the issue. But I'm not really 100% sure on this.
>>
>> Thanks,
>> Jake
>
> I just reviewed 2 libc implementations (glibc and an Android libc) and
> both of them
> do not use chdir internally, but use readlink and compose the path 'manually'
> c.f. http://osxr.org:8080/glibc/source/stdlib/canonicalize.c?v=glibc-2.13
Interesting. Would this be portable to Windows, though?
Thanks,
Jake
^ permalink raw reply
* [PATCH 1/2] update-unicode.sh: automatically download newer definition files
From: Beat Bolli @ 2016-12-02 21:26 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
Checking just for the files' existence is not enough; we should also
download them if a newer version exists on the Unicode servers.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
update_unicode.sh | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index 27af77c..3c84270 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -10,12 +10,8 @@ if ! test -d unicode; then
mkdir unicode
fi &&
( cd unicode &&
- if ! test -f UnicodeData.txt; then
- wget http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt
- fi &&
- if ! test -f EastAsianWidth.txt; then
- wget http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
- fi &&
+ wget -N http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt \
+ http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
if ! test -d uniset; then
git clone https://github.com/depp/uniset.git
fi &&
--
2.7.2
^ permalink raw reply related
* [PATCH 2/2] unicode: update the tables to Unicode 9.0
From: Beat Bolli @ 2016-12-02 21:26 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
In-Reply-To: <1480713995-16157-1-git-send-email-dev+git@drbeat.li>
A rerun of the previously fixed update-unicode.sh produces these new
tables.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
unicode_width.h | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 111 insertions(+), 11 deletions(-)
diff --git a/unicode_width.h b/unicode_width.h
index 47cdd23..73b5fd6 100644
--- a/unicode_width.h
+++ b/unicode_width.h
@@ -25,7 +25,7 @@ static const struct interval zero_width[] = {
{ 0x0825, 0x0827 },
{ 0x0829, 0x082D },
{ 0x0859, 0x085B },
-{ 0x08E4, 0x0902 },
+{ 0x08D4, 0x0902 },
{ 0x093A, 0x093A },
{ 0x093C, 0x093C },
{ 0x0941, 0x0948 },
@@ -120,6 +120,7 @@ static const struct interval zero_width[] = {
{ 0x17C9, 0x17D3 },
{ 0x17DD, 0x17DD },
{ 0x180B, 0x180E },
+{ 0x1885, 0x1886 },
{ 0x18A9, 0x18A9 },
{ 0x1920, 0x1922 },
{ 0x1927, 0x1928 },
@@ -158,7 +159,7 @@ static const struct interval zero_width[] = {
{ 0x1CF4, 0x1CF4 },
{ 0x1CF8, 0x1CF9 },
{ 0x1DC0, 0x1DF5 },
-{ 0x1DFC, 0x1DFF },
+{ 0x1DFB, 0x1DFF },
{ 0x200B, 0x200F },
{ 0x202A, 0x202E },
{ 0x2060, 0x2064 },
@@ -171,13 +172,13 @@ static const struct interval zero_width[] = {
{ 0x3099, 0x309A },
{ 0xA66F, 0xA672 },
{ 0xA674, 0xA67D },
-{ 0xA69F, 0xA69F },
+{ 0xA69E, 0xA69F },
{ 0xA6F0, 0xA6F1 },
{ 0xA802, 0xA802 },
{ 0xA806, 0xA806 },
{ 0xA80B, 0xA80B },
{ 0xA825, 0xA826 },
-{ 0xA8C4, 0xA8C4 },
+{ 0xA8C4, 0xA8C5 },
{ 0xA8E0, 0xA8F1 },
{ 0xA926, 0xA92D },
{ 0xA947, 0xA951 },
@@ -204,7 +205,7 @@ static const struct interval zero_width[] = {
{ 0xABED, 0xABED },
{ 0xFB1E, 0xFB1E },
{ 0xFE00, 0xFE0F },
-{ 0xFE20, 0xFE2D },
+{ 0xFE20, 0xFE2F },
{ 0xFEFF, 0xFEFF },
{ 0xFFF9, 0xFFFB },
{ 0x101FD, 0x101FD },
@@ -228,16 +229,21 @@ static const struct interval zero_width[] = {
{ 0x11173, 0x11173 },
{ 0x11180, 0x11181 },
{ 0x111B6, 0x111BE },
+{ 0x111CA, 0x111CC },
{ 0x1122F, 0x11231 },
{ 0x11234, 0x11234 },
{ 0x11236, 0x11237 },
+{ 0x1123E, 0x1123E },
{ 0x112DF, 0x112DF },
{ 0x112E3, 0x112EA },
-{ 0x11301, 0x11301 },
+{ 0x11300, 0x11301 },
{ 0x1133C, 0x1133C },
{ 0x11340, 0x11340 },
{ 0x11366, 0x1136C },
{ 0x11370, 0x11374 },
+{ 0x11438, 0x1143F },
+{ 0x11442, 0x11444 },
+{ 0x11446, 0x11446 },
{ 0x114B3, 0x114B8 },
{ 0x114BA, 0x114BA },
{ 0x114BF, 0x114C0 },
@@ -245,6 +251,7 @@ static const struct interval zero_width[] = {
{ 0x115B2, 0x115B5 },
{ 0x115BC, 0x115BD },
{ 0x115BF, 0x115C0 },
+{ 0x115DC, 0x115DD },
{ 0x11633, 0x1163A },
{ 0x1163D, 0x1163D },
{ 0x1163F, 0x11640 },
@@ -252,6 +259,16 @@ static const struct interval zero_width[] = {
{ 0x116AD, 0x116AD },
{ 0x116B0, 0x116B5 },
{ 0x116B7, 0x116B7 },
+{ 0x1171D, 0x1171F },
+{ 0x11722, 0x11725 },
+{ 0x11727, 0x1172B },
+{ 0x11C30, 0x11C36 },
+{ 0x11C38, 0x11C3D },
+{ 0x11C3F, 0x11C3F },
+{ 0x11C92, 0x11CA7 },
+{ 0x11CAA, 0x11CB0 },
+{ 0x11CB2, 0x11CB3 },
+{ 0x11CB5, 0x11CB6 },
{ 0x16AF0, 0x16AF4 },
{ 0x16B30, 0x16B36 },
{ 0x16F8F, 0x16F92 },
@@ -262,16 +279,28 @@ static const struct interval zero_width[] = {
{ 0x1D185, 0x1D18B },
{ 0x1D1AA, 0x1D1AD },
{ 0x1D242, 0x1D244 },
+{ 0x1DA00, 0x1DA36 },
+{ 0x1DA3B, 0x1DA6C },
+{ 0x1DA75, 0x1DA75 },
+{ 0x1DA84, 0x1DA84 },
+{ 0x1DA9B, 0x1DA9F },
+{ 0x1DAA1, 0x1DAAF },
+{ 0x1E000, 0x1E006 },
+{ 0x1E008, 0x1E018 },
+{ 0x1E01B, 0x1E021 },
+{ 0x1E023, 0x1E024 },
+{ 0x1E026, 0x1E02A },
{ 0x1E8D0, 0x1E8D6 },
+{ 0x1E944, 0x1E94A },
{ 0xE0001, 0xE0001 },
{ 0xE0020, 0xE007F },
{ 0xE0100, 0xE01EF }
};
static const struct interval double_width[] = {
-{ /* plane */ 0x0, 0x1C },
-{ /* plane */ 0x1C, 0x21 },
-{ /* plane */ 0x21, 0x22 },
-{ /* plane */ 0x22, 0x23 },
+{ /* plane */ 0x0, 0x3D },
+{ /* plane */ 0x3D, 0x68 },
+{ /* plane */ 0x68, 0x69 },
+{ /* plane */ 0x69, 0x6A },
{ /* plane */ 0x0, 0x0 },
{ /* plane */ 0x0, 0x0 },
{ /* plane */ 0x0, 0x0 },
@@ -286,7 +315,40 @@ static const struct interval double_width[] = {
{ /* plane */ 0x0, 0x0 },
{ /* plane */ 0x0, 0x0 },
{ 0x1100, 0x115F },
+{ 0x231A, 0x231B },
{ 0x2329, 0x232A },
+{ 0x23E9, 0x23EC },
+{ 0x23F0, 0x23F0 },
+{ 0x23F3, 0x23F3 },
+{ 0x25FD, 0x25FE },
+{ 0x2614, 0x2615 },
+{ 0x2648, 0x2653 },
+{ 0x267F, 0x267F },
+{ 0x2693, 0x2693 },
+{ 0x26A1, 0x26A1 },
+{ 0x26AA, 0x26AB },
+{ 0x26BD, 0x26BE },
+{ 0x26C4, 0x26C5 },
+{ 0x26CE, 0x26CE },
+{ 0x26D4, 0x26D4 },
+{ 0x26EA, 0x26EA },
+{ 0x26F2, 0x26F3 },
+{ 0x26F5, 0x26F5 },
+{ 0x26FA, 0x26FA },
+{ 0x26FD, 0x26FD },
+{ 0x2705, 0x2705 },
+{ 0x270A, 0x270B },
+{ 0x2728, 0x2728 },
+{ 0x274C, 0x274C },
+{ 0x274E, 0x274E },
+{ 0x2753, 0x2755 },
+{ 0x2757, 0x2757 },
+{ 0x2795, 0x2797 },
+{ 0x27B0, 0x27B0 },
+{ 0x27BF, 0x27BF },
+{ 0x2B1B, 0x2B1C },
+{ 0x2B50, 0x2B50 },
+{ 0x2B55, 0x2B55 },
{ 0x2E80, 0x2E99 },
{ 0x2E9B, 0x2EF3 },
{ 0x2F00, 0x2FD5 },
@@ -313,11 +375,49 @@ static const struct interval double_width[] = {
{ 0xFE68, 0xFE6B },
{ 0xFF01, 0xFF60 },
{ 0xFFE0, 0xFFE6 },
+{ 0x16FE0, 0x16FE0 },
+{ 0x17000, 0x187EC },
+{ 0x18800, 0x18AF2 },
{ 0x1B000, 0x1B001 },
+{ 0x1F004, 0x1F004 },
+{ 0x1F0CF, 0x1F0CF },
+{ 0x1F18E, 0x1F18E },
+{ 0x1F191, 0x1F19A },
{ 0x1F200, 0x1F202 },
-{ 0x1F210, 0x1F23A },
+{ 0x1F210, 0x1F23B },
{ 0x1F240, 0x1F248 },
{ 0x1F250, 0x1F251 },
+{ 0x1F300, 0x1F320 },
+{ 0x1F32D, 0x1F335 },
+{ 0x1F337, 0x1F37C },
+{ 0x1F37E, 0x1F393 },
+{ 0x1F3A0, 0x1F3CA },
+{ 0x1F3CF, 0x1F3D3 },
+{ 0x1F3E0, 0x1F3F0 },
+{ 0x1F3F4, 0x1F3F4 },
+{ 0x1F3F8, 0x1F43E },
+{ 0x1F440, 0x1F440 },
+{ 0x1F442, 0x1F4FC },
+{ 0x1F4FF, 0x1F53D },
+{ 0x1F54B, 0x1F54E },
+{ 0x1F550, 0x1F567 },
+{ 0x1F57A, 0x1F57A },
+{ 0x1F595, 0x1F596 },
+{ 0x1F5A4, 0x1F5A4 },
+{ 0x1F5FB, 0x1F64F },
+{ 0x1F680, 0x1F6C5 },
+{ 0x1F6CC, 0x1F6CC },
+{ 0x1F6D0, 0x1F6D2 },
+{ 0x1F6EB, 0x1F6EC },
+{ 0x1F6F4, 0x1F6F6 },
+{ 0x1F910, 0x1F91E },
+{ 0x1F920, 0x1F927 },
+{ 0x1F930, 0x1F930 },
+{ 0x1F933, 0x1F93E },
+{ 0x1F940, 0x1F94B },
+{ 0x1F950, 0x1F95E },
+{ 0x1F980, 0x1F991 },
+{ 0x1F9C0, 0x1F9C0 },
{ 0x20000, 0x2FFFD },
{ 0x30000, 0x3FFFD }
};
--
2.7.2
^ permalink raw reply related
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