tbo...@web.de:
+static inline int buffer_has_utf16_bom(const void *buf, size_t len) {
+ const unsigned char *text = (unsigned char *)buf;
+ if (!text || len < 2)
+return 0;
+ if (text[0] == 0xff && text[1] == 0xfe)
+return 1;
+ if (text[0] == 0xfe && text[1] == 0xff)
+return 1;
Elijah Newren:
Sure, take a look at the big-repo-small-cherry-pick branch of
https://github.com/newren/git
With those changes, the time usage is the same as if I set
merge.renameLimit=1 for the repository, and the end result is identical:
$ time
Elijah Newren:
I would be very interested to hear how my rename detection
performance patches work for you; this kind of usecase was the exact
one it was designed to help the most. See
https://public-inbox.org/git/20171110222156.23221-1-new...@gmail.com/
I'd be happy to try them out. Is
Kevin Willford:
Since this is happening during a merge, you might need to use merge.renameLimit
or the merge strategy option of -Xno-renames. Although the code does fallback
to use the diff.renameLimit but there is still a lot that is done before even
checking
the rename limit so I would
Derrick Stolee:
Git is spending time detecting renames, which implies you probably
renamed a folder or added and deleted a large number of files. This
rename detection is quadratic (# adds times # deletes).
Yes, a couple of directories with a lot of template files have been
renamed (and
Jeff King:
Can you get a backtrace? I'd do something like:
Seems that it spends most time in diffcore_count_changes(), that is
where it hits whenever I hit Ctrl+C (various line numbers 199-207 in
diffcore-delta.c; this is on the v2.15.0 tag).
(gdb) bt
#0 diffcore_count_changes
Hi!
On a big repository (57000 files, 2,5 gigabytes in .git/objects), git
cherry-pick is very slow for me (v2.15.0). This is cherry-picking a
one-file change, where the file is in the same place on both branches,
and which applies cleanly (I am backporting a few fixes to a
maintenance
So, I set the wrong value for a configuration option, and git tells me:
$ git config branch.autoSetupRebase false
$ git log
error: malformed value for branch.autosetuprebase
fatal: bad config variable 'branch.autosetuprebase' in file '.git/config' at
line 24
That's fine. However, when
René Scharfe:
Sure, but if we were to start emitting zip64 records regardless of
the size of entries then we'd break compatibility. We should have a
very good reason for doing that. (I don't see the need so far.)
Sure, sounds good.
The type of descriptor to use depends on the presence of
René Scharfe:
Sizes can be stored in zip64 entries even if they are lower (from a
paragraph about the data descriptor):
"4.3.9.2 When compressing files, compressed and uncompressed sizes
should be stored in ZIP64 format (as 8 byte values) when a
file's size exceeds 0x.
René Scharfe:
I struggled with that sentence as well. There is no explicit
"format" field AFAICS.
Exactly. I interpret that as it is in zip64 format if there are any
zip64 structures in the archive (especially if there is a zip64
end of central directory locator).
Or in other words: A
René Scharfe:
This needs to be >=. The spec says that if the value is 0x, there
should be a zip64 record with the actual size (even if it is 0x).
Could you please cite the relevant part?
4.4.8 compressed size: (4 bytes)
4.4.9 uncompressed size: (4 bytes)
"If an archive is in
René Scharfe:
@@ -433,6 +446,11 @@ static int write_zip_entry(struct archiver_args *args,
free(deflated);
free(buffer);
+ if (offset > 0x) {
+ zip64_dir_extra_payload_size += 8;
+ zip_dir_extra_size += 2 + 2 +
Johannes Sixt:
There is no "zip64 central directory". There is a "zip64 end of central
directory record";
Not strange that I was confused and couldn't find it, then... :-)
All right, I need to fix up my patch to make sure I add the zip64
extra record to both the central directory entry and
Johannes Sixt:
Let's get the naming straight: There is no "zip64 local header". There is a
"zip64 extra record" for the "zip local header".
Indeed, sorry for the confusion. That's what I get for trying to write
coherent email at half past midnight :-)
The zip64 extra data record has an
René Scharfe:
The offset is declared as unsigned int, so will wrap on most platforms
before reaching the clamp check. At least InfoZIP's unzip can handle
that, but it's untidy.
Right, that needs to be changed into unsigned long and clamped, just
like the original and compressed file sizes
If the size of the files in the archive cannot be expressed in 32 bits, or
the offset in the zip file itself, add zip64 local headers with the actual
size. If we do find such entries, we also set a flag to force the creation
of a zip64 end of central directory record.
Signed-off-by: Peter
If the size of the files in the archive cannot be expressed in 32 bits, or
the offset in the zip file itself, add zip64 local headers with the actual
size. If we do find such entries, we also set a flag to force the creation
of a zip64 end of central directory record.
Signed-off-by: Peter
Ralf Thielow:
Since translations are made in one commit, this commit is messed up
with the msgmerge update so when you look at the commit later,
you'll have a hard time to find out what the actual changes in
translations were.
You can always use something like podiff
(Attached gzipped to avoid character encoding issues)
0001-gitk-sv.po-Update-Swedish-translation-311t.patch.gz
Description: application/gzip
Hi!
After upgrading Git to 2.6.3 (from 2.5.0), gitk refuses to start when
trying to load the Swedish translation if I pass it a commit range:
$ gitk v2.5.0..v2.6.3
Error in startup script: bad menu entry index "Ändra vy..."
while executing
".bar.view entryconf [mca "Edit view..."]
$ git commit -m b
[master dee7ec1] b
1 file changed, 1 insertion(+)
create mode 100644 b.txt
$ git show --pretty=fuller
commit dee7ec1cda74a8abd7f26c60ee1e83f73bb31194 (HEAD - master)
Author: Peter Krefting peter.kreft...@bridgetech.tv
AuthorDate: 2015-04-15 09:04:34 +0200
Hi!
Please find attached (for text encoding reasons) an update to the
Swedish translation for git-gui.
--
\\// Peter - http://www.softwolves.pp.se/
0001-git-gui-sv.po-Update-Swedish-translation-547t0f0u.patch.gz
Description: [PATCH] git-gui: sv.po: Update Swedish translation (547t0f0u)
Please find attached (for text encoding reasons) an update to the
Swedish translation for gitk.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-sv.po-Update-Swedish-translation-305t0f0u.patch.gz
Description: Binary data
Junio C Hamano:
Having said that, disabling --amend and forcing to use --force or
something when it is clear that the user is attempting something
unusual is a good idea. But I am not sure what the definition of
unusual should be.
For commit --amend, I would say it would refuse to amend if
Kyle J. McKay:
I think something like this might do what you want:
git for-each-ref --format='%(refname)' refs/tags | \
while read t; do
if ! git merge-base --is-ancestor $t HEAD; then
echo ${t#refs/tags/}
fi
done
That works like a charm, thank you!
--
\\// Peter -
Hi!
Using git branch --no-merged I can get a list of branches that I
have that I haven't merged into my current branch. git tag doesn't
have such an option, is there a way to achieve something similar
listing tags that point to commits that aren't in my history?
Background: In my $DAYJOB
Jiang Xin:
Because I update the .po files with msgmerge, this update also
brings some format changes, so not panic. :) What I changed are:
Swedish (sv) looks fine, thanks!
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the
Graeme Geldenhuys:
This works very well. The only problem we have so far is that if we have
files with spaces in the name (eg: SQL update scripts), then the command
breaks.
If you add -z to the git diff command-line, it will give you the names
with nul terminators instead. If you couple
Fabian Ruch:
2. Notice ourselves that the end-result of the whole squash is an
empty commit, and stop to let the user deal with it.
This patch chooses the second alternative. Either way seems OK. The
crucial consensus of the discussion was to silently throw away empty
interim
Jeff King:
If that is the case, though, I wonder if we should actually be adding it
as a git-protocol header so that all transports can benefit (i.e., we
could be localizing human-readable error messages in upload-pack,
receive-pack, etc).
That would be very nice, thre is a lot of language
Yi EungJun:
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
This one seems to fix all the issues I had with the first patch,
thanks!
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this
Yi EungJun:
Example:
LANGUAGE= -
LANGUAGE=ko - Accept-Language: ko; q=1.000, *; q=0.001
LANGUAGE=ko:en - Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001
Avoid adding q=1.000. It is redundant (the default for any
unqualified language names is 1.0, and additionally there has
Robert Dailey:
Is there a way to graphically see what is the nearest named ref to
the specified commit in the logs?
git log --graph --decorate commit..
will display all the commits that happened after the commit commit,
with the branch names indicated, with lines indicating the ancestry.
Phil Hord:
Did you have a series of three commits being squashed in your to-do
list? I mean, did you have a list like this:
pick ... do foo
squash ... revert do foo
squash ... What I really meant to do.
Yes, that is exactly what I had. Plus an extra commit that I moved to
the end,
Hi!
I am rebasing a branch to combine a couple of commits. One is a revert
of a previous commit. Since there are commits in-between, I do
squash to make sure I get everything, and then add the actual change
on top of that. The problem is that rebase stops with a confusing
error message (from
Phil Hord:
What does it mean when you say it worked as expected? Did it leave
the empty commit, omit the empty commit, or leave some un-squashed
commit?
Actually, it did not work as expected I noted afterward, it just
dropped the reversion commit, and did not squash the next commit into
it
Stepan Kasal:
+ warning(Your console font probably doesn\'t support Unicode. If
+ you experience strange characters in the output, consider
+ switching to a TrueType font such as Lucida Console!);
As you mention this is an old patch series, but I would
Stepan Kasal:
+ /* only called from console_thread, so a static buffer will do */
+ static wchar_t wbuf[2 * BUFFER_SIZE + 1];
Wouldn't BUFFER_SIZE + 1 (or even BUFFER_SIZE) do here? If you convert
from up to BUFFER_SIZE octets of UTF-8 input, you should never get
back more than
Kyle J. McKay:
I think that a strict reading of RFC 2616 allows text/plain ; charset=utf-8
as well as text/plain;charset=utf-8 and text/plain; charset=utf-8.
It does indeed, and I have seen servers send both variants, so they do
need to be catered for.
The number of servers that would
Kyle J. McKay:
+ if (!*charset)
+ *charset = xstrdup(iso8859-1);
Actually the name should be ISO-8859-1. See RFC 2616 section 3.7.1. Since
it's case insensitive iso-8859-1 would be fine too.
You'd be amazed at what you see in the wild... I'd recommend going
with the
Jeff King:
I was really hoping to avoid getting into all of the real-world
messiness that a real http client needs to deal with (as opposed to just
following the standards).
Yeah, I agree, you're probably fine without all this detail in over
99% of the cases where this code would ever be
Michael Wagner:
Decoding the UTF-8 encoded file name (again with an additional print
statement):
$ REQUEST_METHOD=GET
QUERY_STRING='p=notes.git;a=blob_plain;f=work/G%C3%83%C2%BCtekriterien.txt;hb=HEAD'
./gitweb.cgi
work/Gütekriterien.txt
Content-disposition: inline;
Torsten Bögershausen:
The function git_wcwidth() returns for a given unicode code point the
width on the display:
-1 for control characters,
0 for combining or other non-visible code points
1 for e.g. ASCII
2 for double-width code points.
This all looks sane, but the problem is that this is
Junio C Hamano:
But why does the workflow need --date=now in the first place?
I tend to do this quite a lot, after fixing up a commit using rebase,
I notice that the commit date is when I first started fixing the
issue, even if that was a week or so ago. I then like to reset the
commit
Torsten Bögershausen:
Some of the code points which have 0 length on the display are called
combining, others are called vowels or accents.
E.g. 5BF is not marked any of them, but if you look at the glyph, it should
be combining (please correct me if that is wrong).
All combining characters
Torsten Bögershausen:
diff --git a/utf8.c b/utf8.c
index a831d50..77c28d4 100644
--- a/utf8.c
+++ b/utf8.c
Is there a script that generates this code from the Unicode database
files, or did you hand-update it?
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list:
Nguy?n Thái Ng?c Duy:
I can't think of any case that progress lines are for machine. It
started because of the only local untranslated line in git clone.
But I think we should do all at once.
Indeed, a good move. Anything that is to be displayed to the end user
should be subject to
Matthieu Moy:
One option is to have the symlink in the other direction: make
/etc/foo a symlink to $GIT_WORKTREE/foo and version the later.
I do that for the software that supports it, but ssh, for instance, is
very picky that ~/.ssh is a directory and such. And at least one of
the other
Johan Herland:
I believe a preferable way to manage dotfiles in Git, is to have a
script that does the necessary setup/installation from the repo
(that lives in some subdirectory of ~) and into ~.
Yeah, but then I have copies of the files, instead of having the files
themselves under
Hi!
Is there a (per-repo) setting to get Git to follow symlinks in the
working directory, i.e., to not store the symlinks themselves but
rather work on what they point to?
Background: I have a repository that stores a number of my dotfiles,
shared between all my machines (Linux, OSX,
Mandeep Sandhu:
Here's what I did when I was in topicA:
$ git rebase dev stable topicA
(this was suggested in the manpage as well).
I guess you also had an --onto in there, as the above would throw a
syntax error. As long as the branches are in order, I cannot see how
that wouldn't do what
Thomas Rast:
Have you tried moving away .git/gitk.cache?
If that fixes it, perhaps you can share it for inspection.
Yes, I did, just after I sent off that email. It did not fix the
problem, however.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the
Hi!
In my local clone of git.git, currently with the v1.8.4-rc2 tag
checked out and built (and installed on the system), starting up gitk
yields an empty window, with a dialog in front of it:
error
Can't parse git log output: { }
[ OK ]
Has anyone else seen this, and know what might
and corrected by Peter Krefting.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Peter Krefting pe...@softwolves.pp.se
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Peter Krefting:
- /* U+FFFE and U+ are guaranteed non-characters. */
- if ((codepoint 0x1e) == 0xfffe)
+ /* U+xxFFFE and U+xx are guaranteed non-characters. */
+ if ((codepoint 0xe) == 0xfffe
Andreas Amann:
+set difffile $diffidtext [file tail $flist_menu_file]
+set difffile [tk_getSaveFile -initialfile $difffile -title Save file as
-parent .]
+if {$difffile eq {}} {
+ return
+}
+save_file_from_commit $diffid:$flist_menu_file $difffile revision $diffid
I
Unicode clause D14 defines all characters U+nFFFE and U+n (where
0 = n = 10h) as well as the range U+FDD0..U+FDEF as non-characters,
reserved for internal use only. Disallow these characters in commit
messages as they are normally not recommended for interchange.
Signed-off-by: Peter
brian m. carlson:
+ /* U+FFFE and U+ are guaranteed non-characters. */
+ if ((codepoint 0x1e) == 0xfffe)
+ return bad_offset;
I missed this the first time around: All Unicode characters whose
lower 16-bits are FFFE or are
brian m. carlson:
+ /* Check the value here */
+ if (codepoint = 0xd800 codepoint = 0xdfff)
+ return bad_offset;
if ((x 0xF800) == 0xD800)
is slightly shorter, albeit a bit more difficult to read.
Please also consider adding some
brian m. carlson:
int offset = 0;
+ static const unsigned int max_codepoint[] = {
+ 0x7f, 0x7ff, 0x, 0x1f
+ };
Since Unicode is not defined beyond U+10, you can easily make the
last range end at U+10FFF. Doing that, ...
if
Vicent Martí:
I'm aware of that, but Git needs to build with glibc 2.7+ (or was it
2.6?), hence the need for this compat layer.
Right. But perhaps the compatibility layer could provide the
functionality with the names available in the later glibc versions
(and on *BSD)? That would make it
Vicent Marti:
The POSIX standard doesn't currently define a `nothll`/`htonll`
function pair to perform network-to-host and host-to-network swaps
of 64-bit data. These 64-bit swaps are necessary for the on-disk
storage of EWAH bitmaps if they are not in native byte order.
endian(3) claims
Junio C Hamano:
But my understanding is that the reordering using printf() is the
mechanism we suggest l10n folks to use when the order of parameters
given to printf does not match the preferred word order in the
message in their language.
It's documented in the gettext manual, and seems to
Ramkumar Ramachandra:
+ on_what = _(rebase in progress; onto );
Could you please add a
/* TRANSLATORS: Followed by branch name. */
or something similar here (and possibly to the other on_whats in the
function)?
Ideally, the %s for the branch name should be
Mathieu Lienard--Mayor:
+ /*
+* If the file stopped-sha does not exist
+* we go back to the old output saying a commit
+* instead of providing the commit's SHA1.
+*/
+ if (!stopped_sha) {
+ stopped_sha = a commit;
+
Mathieu Liénard--Mayor:
Actually, at first I dealt with it this way:
status_printf_ln(s, color,
_(Splitting %s while rebasing branch '%s' on '%s'.),
stopped_sha ? stopped_sha : _(a commit),
);
Would this be more suitable for translators ?
Ramkumar Ramachandra:
Yeah. We generally prefer the long-form equivalents while doing
completions, but these blame options do not have equivalent
long-forms.
Perhaps that is the real bug, then. -M and -C already have long names
for diff (and its friends), perhaps blame should have the same
René Scharfe:
While we're add it,
add → at
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Klavs Rommedahl:
I just downloaded your Windows version, and got a virus attack, and a trojan.
So sad to try a new world on the net, and then getting attacked. What to do
? Any clues ?
Which URL did you download from, exactly?
The patch is attached gzipped to avoid character encoding issues.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-Update-Swedish-translation-304t.patch.gz
Description: [PATCH] gitk: Update Swedish translation (304t)
Felipe Contreras:
% git log --oneline -1 v1.8.1.5^..v1.8.1.6
% git log --oneline --reverse -1 v1.8.1.5^..v1.8.1.6
I expect to get a different output, and not both showing v1.8.1.6.
Wouldn't you agree?
Quoting the manual page:
Commit Limiting
Besides specifying a range of commits that
Jiang Xin:
The following changes since commit f94c3251e1400c3cf349f7f84fea4db66b540113:
Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to
Eric S. Raymond:
and (b) include the removal of import-directories.perl in my
integration patch.
Yes, please.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
Eric S. Raymond:
git-weave(1)
Yes, there are scripts in contrib that do similar things.
I was just about to say that the import direction of this seems to
fill the same need as contrib/fast-import/import-directories.perl that
I submitted a few years back.
Your version seems only to be
I'll see if I can come up with a patch that cater for both use-cases.
I see that I forgot to Cc you; please see the patch series starting
with the Subject [RFC PATCH 0/2] Localize log output, which I posted
here yesterday.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from
-1.8.0
with an updated Swedish translation.
Peter Krefting (2):
Use localized date in log output
Localize diff and log output
builtin/apply.c | 2 +-
builtin/commit.c | 4 +--
builtin/log.c| 6 ++--
commit.h | 3 +-
date.c | 4 ++-
diff.c | 22
When outputting a normal log, without having specified which date format
to use, we should output the current user locale's default format. Do this
by initializing LC_TIME properly and using strftime() to format the date.
---
date.c| 4 +++-
gettext.c | 1 +
strbuf.c | 10 ++
The output of git diff --stat, git show --stat and git log should be
translated to the local user language. The output of git format-patch
should not, however. Add localization where needed, and add a flag for
making sure that format-patch's output remains in English.
This partially reverts
David Soria Parra:
- if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field)
+ if (GREP_HEADER_FIELD_MAX = p-field)
A friend taught me this trick, which will check that it isn't negative
for compilers that have the enumeration be signed (notably MSVC),
while not
David Soria Parra:
The enum grep_header_field is unsigned.
Enumerations can be either unsigned or signed, it is up to the
compiler to decide. Even if you assign only positive number to named
enumeration values, there are compilers that make them signed. I've
been bitten by that enough.
Nguyen Thai Ngoc Duy:
It's the result of this discussion [1]. I don't remember exactly the
open issues. But I think it involves drawing a line between team
language vs local language, whether team language can be anything
other than English, the maintenance cost for supporting it
Like I said,
Hi!
The output of git format-patch and git diff --stat no longer
becomes localized when using 1.8.0.rc2, compared to 1.7.12
Running both versions of git format-patch -1 from the same
repository, with the same settings otherwise, has 1.7.12 output the
diffstat summary in Swedish, while
skillz...@gmail.com:
I frequently see rebase fail after applying several commits because
git thinks there are local changes.
What operating system are you running on? I have seen simlar issues on
Windows, which has a case-insensitive file system, in repositories
where file names have either
These files are from rsync.git commit
f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
before rsync turned GPL-3.
However:
diff --git a/test-wildmatch.c b/test-wildmatch.c
[...]
+ * This program is free software; you can redistribute it and/or modify
+ * it under the
This patch updates the Swedish translation for gitk. To avoid the
UTF-8 encoding of the file to be mangled by my email software, the
patch is attached gzip'ed.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-Update-Swedish-translation-296t.patch.gz
Description: Binary data
Junio C Hamano:
I do not think there is any issue with conflicting patch or merge
caused by applying this to maint, but I CC'ed Jiang to let him know
what is going on.
You might get a conflict in the header (in the PO-Revision-Date
line). The fixed message itself is already in the 1.8.0.rc0
Nguyen Thai Ngoc Duy:
I'm just thinking whether it's a good idea to add a section in the
end of each command's man page to list all relevant config keys to
that command, somewhat similar to see also section.
Yes, please. Discoverability of configuration settings is not very
good at the
Fix bad translation of Receiving objects.
Signed-off-by: Peter Krefting pe...@softwolves.pp.se
---
po/sv.po | 4 ++--
1 fil ändrad, 2 tillägg(+), 2 borttagningar(-)
Dear Junio,
could you please apply this patch to the 1.7.12 maintenance branch, if
you intend to do more releases past
Andrew Wong:
Instead of rebasing to HEAD~, you should be able to do:
git rebase -i HEAD
Would you look at that, that actually works. So much for not testing
that. Thanks, that makes it a lot easier.
Instead of appending your own recipe, you could also abuse the EDITOR
environment
Hi!
At $DAYJOB, we have a lot of code flowing from a central repository
to repositories which hold refinitions and ports of the code from the
central repository. Often enough the people working on the porting
repositories find bugs in the code from the central repository, and
want to submit
91 matches
Mail list logo
