2014-04-18 2:08 GMT+08:00 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
When extract l10n messages, we use --add-comments option to keep
comments right above the l10n messages for references. But sometimes
irrelevant comments are also extracted. For example in
Hello,
cc'ing Roman, the original author. (I should have done that
in the first post, sorry. I have also forwarded him another
mail from this thread, asking him for author's sign off.)
On Thu, Apr 17, 2014 at 10:39:49AM -0700, Junio C Hamano wrote:
Stepan Kasal ka...@ucw.cz writes:
On
When show blame information with relative time, the UTF-8 characters in
`time_str` will break the alignment of columns after the date field.
This is because the `time_buf` padding with spaces should have a
constant display width, not a fixed strlen size. So we should call
utf8_strwidth() instead
Am 13.04.2014 00:45, schrieb Ronald Weiss:
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
Git add currently doesn't honor ignore from .gitmodules or .git/config,
which is related functionality, however I'd like to change that in
another patch, coming
Am 13.04.2014 00:49, schrieb Ronald Weiss:
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but didn't allow to override it from command line.
This patch depends on Jens Lehmann's
Am 13.04.2014 01:41, schrieb Ronald Weiss:
On 8. 4. 2014 20:26, Jens Lehmann wrote:
Am 07.04.2014 23:46, schrieb Ronald Weiss:
Then, on top of that, I'll prepare patches for add to honor ignore
from .gitmodules, and -f implying --ignore-submodules. That might need
more discussion, let's see.
Am 17.04.2014 23:55, schrieb W. Trevor King:
On Thu, Apr 17, 2014 at 11:08:06PM +0200, Jens Lehmann wrote:
Am 17.04.2014 18:41, schrieb W. Trevor King:
On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:
*) When a submodule is replaced with a tracked file of the same name
the
On Thu, Apr 17, 2014 at 11:30:04PM +0200, Jens Lehmann wrote:
- Heiko's config cache for submodules patch
Needed for my recursive checkout series to populate new submodules.
Which will be followed by my recursive fetch series, which is also the
last part of what started with this:
I like that strbuf is getting used more than it used to, and I think
that is a good general trend to help git rid of and/or avoid buffer
overflows and arbitrary limits on strings.
It is unfortunate that it is currently impossible to use a strbuf
without doing a memory allocation. So code like
With git status, writing refreshed index takes 252ms per total 1s,
361s/1.4s, 86ms/360ms on gentoo-x86, webkit and linux-2.6 respectively
(*). It's takes a significant amount of time from git status. And
this happens whenever you touch a single tracked file, then do git
status. We tried to solve
On Fri, Apr 18, 2014 at 3:44 PM, Jiang Xin worldhello@gmail.com wrote:
When show blame information with relative time, the UTF-8 characters in
`time_str` will break the alignment of columns after the date field.
This is because the `time_buf` padding with spaces should have a
constant
Jeff King p...@peff.net writes:
---A---B---C-D---E---F (maint, v3.4)
\ \ /
\ ---G-H---I (master, v4.0)
\ / /
--J---
The fix is J, and it got merged up to maint at D, and to master at H.
v4.0 does not contain v3.4. What's the best
Jiang Xin worldhello@gmail.com writes:
I am not very happy with this change, as it would force us to
special case Translators comment to follow a non-standard
multi-line comment formatting convention. Is there a way to tell
xgettext to accept both of these forms?
/*
Duy Nguyen pclo...@gmail.com writes:
On Fri, Apr 18, 2014 at 3:44 PM, Jiang Xin worldhello@gmail.com wrote:
When show blame information with relative time, the UTF-8 characters in
`time_str` will break the alignment of columns after the date field.
This is because the `time_buf` padding
Michael Haggerty mhag...@alum.mit.edu writes:
The Idea
I would like to see strbuf enhanced to allow it to use memory that it
doesn't own (for example, stack-allocated memory), while (optionally)
allowing it to switch over to using allocated memory if the string grows
past the size
Duy Nguyen pclo...@gmail.com writes:
The major cost of writing an index is the SHA-1 hashing. The bigger
the written part is, the higher cost we pay. So what if we write
stat-only data to a separate file? Think of it as an index extension,
only it stays outside the index. On webkit with 182k
Junio C Hamano gits...@pobox.com writes:
Documentation/CodingGuidelines may want to have a sentence of two to
explain this, though.
After re-reading what I sent out, I realized that the way I singled
out multi-line comments was misleading. Here is an updated version.
-- 8 --
Subject: [PATCH]
An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
A major version bump between v1.x.x series and the upcoming v2.0.0
means there are a handful of backward incompatible UI improvements,
but for most people, all the tricky preparation for the transition
would
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is at v2.0.0-rc0, an early preview
release. There are a handful of topics still in 'next' (and a few
that are
Dear Git Community
I've spent almost a day to find an answer to this question:
We already have trusted Certificates from a CA. Can we use them instead of an
additional PGP key?
We already have:
- s/mime certificate
- web server ssl/tls certificate
- XMPP Jabber ssl/tls certificate
- Object
On 04/18/2014 07:21 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The Idea
I would like to see strbuf enhanced to allow it to use memory that it
doesn't own (for example, stack-allocated memory), while (optionally)
allowing it to switch over to using
On Fri, Apr 18, 2014 at 10:04:50PM +0200, Thomas Schittli wrote:
We already have trusted Certificates from a CA. Can we use them
instead of an additional PGP key?
Git wants a key that can be used by GnuPG, and X.509 certificates can't
be. It invokes the gpg binary that's in your path, so X.509
SHA-1 is clearly on its way out. I know that there has been discussion
in the past about moving to different algorithms. I'm not interested in
having that discussion now.
I'd like to introduce a set of preprocessor constants that we'd use
instead of hard-coded 20s and 40s everywhere. That way,
Hi,
brian m. carlson wrote:
I'd like to introduce a set of preprocessor constants that we'd use
instead of hard-coded 20s and 40s everywhere.
Lukewarm on that. It's hard to do consistently and unless they're
named well it can be harder to know what something like
BINARY_OBJECT_NAME_LENGTH
On Thu, Apr 17, 2014 at 10:04 AM, Junio C Hamano gits...@pobox.com wrote:
Luis R. Rodriguez mcg...@do-not-panic.com writes:
And between v3.4 and v3.5-rc1, the latter is a closer anchor point
for that commit (v3.5-rc1 only needs about 200 hops to reach the
commit, while from v3.4 you would
Luis R. Rodriguez mcg...@do-not-panic.com writes:
I think ultimately this reveals that given that tags *can* be
arbitrary and subjective,...
Yes; see the part at the bottom.
Commit A can be described in terms of both v3.4 and v9.0,
And in the real example case, why *would* c5905afb' be be
Jeff King wrote:
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
As you can see; some branches are published, others are not. The ones that
are
not published don't have a @{publish}, and `git branch -v` doesn't show
them.
Why is that hard to understand?
Do you
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
These patches add support for remote helpers --force, --dry-run, and
reporting
forced update.
Changes since v8:
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -734,7 +734,7 @@ static int
brian m. carlson wrote:
I'd like to introduce a set of preprocessor constants that we'd use
instead of hard-coded 20s and 40s everywhere.
I agree that it would help code clarity to have symbolic constants for
these numbers.
On 04/19/2014 12:40 AM, Jonathan Nieder wrote:
Lukewarm on that.
On Sat, Apr 19, 2014 at 12:08 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Fri, Apr 18, 2014 at 3:44 PM, Jiang Xin worldhello@gmail.com wrote:
When show blame information with relative time, the UTF-8 characters in
`time_str` will break the alignment
On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Let the brainstorming (and bikeshedding) begin!
1. GIT_OID_RAWSZ / GIT_OID_HEXSZ
2. OID_RAWSZ / OID_HEXSZ
3. OID_BINARY_LEN / OID_ASCII_LEN
4. BINARY_OID_LEN / ASCII_OID_LEN
5. sizeof(oid) / ASCII_OID_LEN
--
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/18/2014 07:21 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The Idea
I would like to see strbuf enhanced to allow it to use memory that it
doesn't own (for example, stack-allocated memory), while
Duy Nguyen pclo...@gmail.com writes:
On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Let the brainstorming (and bikeshedding) begin!
1. GIT_OID_RAWSZ / GIT_OID_HEXSZ
2. OID_RAWSZ / OID_HEXSZ
3. OID_BINARY_LEN / OID_ASCII_LEN
4. BINARY_OID_LEN /
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
These patches add support for remote helpers --force, --dry-run, and
reporting
forced update.
Changes since v8:
--- a/transport-helper.c
+++
On Sat, Apr 19, 2014 at 8:06 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Let the brainstorming (and bikeshedding) begin!
1. GIT_OID_RAWSZ / GIT_OID_HEXSZ
2. OID_RAWSZ /
On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano gits...@pobox.com wrote:
An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
This is supposed to have _all_ the v2.0 topics, correct?
I'm unable to find the commit that actually _changes_ the default
prefix
Junio C Hamano wrote:
Gábor Szeder sze...@ira.uka.de writes:
words[] is just fine, we never modify it after it is filled by
_get_comp_words_by_ref() at the very beginning.
Hmph. I would have understood if the latter were we never look at
it (to decide what to do). we never modify it
37 matches
Mail list logo
