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 writes:
>
> > On Wed, Apr 16,
2014-04-18 2:08 GMT+08:00 Junio C Hamano :
> Jiang Xin 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 the following
>> code block, th
On 2014-04-16 16:45, Jonathan Nieder wrote:
Hi,
a...@bellandwhistle.net wrote:
In particular, 'exclude' is spottily documented.
Where did you expect to read about it? I see some mention of
.git/info/exclude in the gitignore(5) page, but I wouldn't be
surprised if there's room for improvemen
On Apr 17, 2014, at 10:15, Junio C Hamano wrote:
I think just the s/from/to/ would fix it so it does not give me the
wrong impression, but that doesn't mean that would not confuse
everyone else. ;)
Yeah, let's do that. Thanks for carefully reading them.
I'd think it makes it clearer to sa
On Fri, Apr 18, 2014 at 2:40 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>>first run second (cached) run
>> gentoo-x86500 ms 71.6 ms
>> wine 140 ms 9.72 ms
>> webkit125 ms 6.88 ms
>> linux-2.6 106 ms
On Thu, Apr 17, 2014 at 10:04:52AM -0700, Junio C Hamano wrote:
> Commit A can be described in terms of both v3.4 and v9.0, and it may
> be closer to v9.0 than v3.4, and under that definition "we pick the
> closest tag", the current "describe --contains" behaviour may be
> correct, but from the hu
On Thu, Apr 17, 2014 at 11:52:56PM +0200, Johannes Schindelin wrote:
> > I tried running the test on my Linux box, but it doesn't fail with the
> > existing recursive code.
>
> I cannot recall how I came to choose 64, but I *think* I only tested on
> Windows, and I *think* I reduced the number of
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 submodule work tree including any loca
Hi Peff,
On Thu, 17 Apr 2014, Jeff King wrote:
> On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote:
>
> > > bash -c "ulimit -s 64 && git tag --contains HEAD" >actual &&
> > [...]
> > Please see https://github.com/msysgit/git/c63d196 for the fixup, and
> > https://github.com/m
On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote:
> > bash -c "ulimit -s 64 && git tag --contains HEAD" >actual &&
> [...]
> Please see https://github.com/msysgit/git/c63d196 for the fixup, and
> https://github.com/msysgit/git/compare/tag-contains%5E...tag-contains for
> the
Am 17.04.2014 21:23, schrieb Junio C Hamano:
> "W. Trevor King" writes:
>
>> There have been a number of submodule series in
>> flight recently, and I'm having trouble keeping track of them all ;).
>
> Unfortunately I share that same feeling X-<.
>
> Could you guys collectively summarize what i
Michael Haggerty writes:
> On 04/16/2014 08:56 PM, Ronnie Sahlberg wrote:
>> Move the check for the lock failure to happen immediately after
>> lock_any_ref_for_update().
>> Previously the lock and the check-if-lock-failed was separated by a handful
>> of string manipulation statements.
>
> Pleas
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 submodule work tree including any local modifications (and
>>even the whole history if it uses a .git di
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Hopefully we can merge a few more topics slated for 'master' before
cutting an early preview release -rc0 tomorrow. Many of the topics
that are
On 04/17/14 17:45, Jens Lehmann wrote:
Am 17.04.2014 10:02, schrieb Gerhard Gappmeier:
Hi all
in our cross-platform projects we always have a certain Windows-only
submodule, which contains all the compatibility stuff and missing libraries for
Windows.
When cloning such a repository on a Linux
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/replace.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b62420a..d8bd6ee 100644
--- a/builtin/replace.c
+++ b/builtin
Switch to using ref transactions in walker_fetch(). As part of the refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail we would end up returning from
the function without free()ing the msg string.
Signed-off-by: Ronnie S
Change branch.c to use ref transactions when doing updates.
Signed-off-by: Ronnie Sahlberg
---
branch.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..45c7766 100644
--- a/branch.c
+++ b/branch.c
@@ -226,7 +226,7 @@ void c
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
fast-import.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index fb4738d..466dfe3 100644
--- a/fast-import.c
+++ b/fast-imp
Change commit.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/commit.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d9550c5..b8e4389 100644
--- a/builtin/commit.c
+
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg
---
sequencer.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index bde5f04..fa14ac0 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -272,17 +27
Do basic error checking in ref_transaction_create() and make it return
status. Update all callers to check the result of ref_transaction_create()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 4 +++-
refs.c | 17 +++--
refs.h | 8
3
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/tag.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 40356e3..dbeacc5 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -4
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 11 +++
refs.c | 9 +++--
refs.h | 10 +---
ref_transaction_create|delete|update has no need to modify the sha1
arguments passed to it so it should use const unsigned char* instead
of unsigned char*.
Some functions, such as fast_forward_to(), already have its old/new
sha1 arguments as consts. This function will at some point need to
use ref
Change ref_transaction_delete() to do basic error checking and return
status. Update all callers to check the return for ref_transaction_delete()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 5 +++--
refs.c | 15 ++-
refs.h | 8
3 f
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref transaction API. There
are still three more places where write_ref_sha1() is called from outside
of refs.c but those all will require more complex work and review so those
ch
Nguyễn Thái Ngọc Duy writes:
>first run second (cached) run
> gentoo-x86500 ms 71.6 ms
> wine 140 ms 9.72 ms
> webkit125 ms 6.88 ms
> linux-2.6 106 ms 16.2 ms
>
> Basically untracked time is cut to one tent
"W. Trevor King" writes:
> There have been a number of submodule series in
> flight recently, and I'm having trouble keeping track of them all ;).
Unfortunately I share that same feeling X-<.
Could you guys collectively summarize what issues each of these
in-flight topics try to address and how
Andreas Schwab writes:
> Junio C Hamano writes:
> ...
>> When your project does not mind basing the description on rc tags,
>> between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if
>> we would want to say that "the former is not so longer than the
>> latter, so use that", or what
Matthieu Moy writes:
> Elia Pinto writes:
>
>> The Git CodingGuidelines prefer the $(...) construct for command
>> substitution instead of using the backquotes `...`.
>
> For patches 1 to 14:
>
> Reviewed-by: Matthieu Moy
>
> (reviewed the patches in my mailer, and the "diff --color-words=." af
Jiang Xin writes:
> 2014-04-17 13:37 GMT+08:00 Jiang Xin :
>> When generate git.pot, many irrelevant comments are extracted as references
>> for translators, but one useful comment is lost. This series patches will
>> fix this issue.
>
> Brief changes of po/git.pot after applied these patches:
Jiang Xin 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 the following
> code block, the comment in line 2 will be extracted as comment f
Stepan Kasal writes:
> From: RomanBelinsky
> Date: Tue, 11 Feb 2014 18:23:02 +0200
>
> fix parsing error for dates like:
> 2014-01-07T5:58:36.048176Z
> previous regex can parse only:
> 2014-01-07T05:58:36.048176Z
> reproduced in my svn repository during conversion.
>
> Signed-off-by: Stepan Kasa
"W. Trevor King" writes:
> On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote:
>> * jl/submodule-recursive-checkout (2013-12-26) 5 commits
>> - Teach checkout to recursively checkout submodules
>> - submodule: teach unpack_trees() to update submodules
>> - submodule: teach unpack_t
Stepan Kasal writes:
> On Wed, Apr 16, 2014 at 12:13:21PM -0700, Junio C Hamano wrote:
>> Interesting. What other strange forms can they record in their
>> repositories, I have to wonder. Can they do
>> 2014-01-07T5:8:6.048176Z
>> for example?
>
> Roman Belinsky, the author of this fix, wit
Hi Peff,
On Wed, 16 Apr 2014, Jeff King wrote:
> On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
>
> > From: Jean-Jacques Lafay at Sat, 10 Nov 2012 18:36:10 +0100
> >
> > In large repos, the recursion implementation of contains(commit,
> > commit_list) may result in a stack overfl
Junio C Hamano writes:
> I also think this illustrates my earlier point. Depending on the
> project and the expectation of the users, which tags are good
> candidates as anchor points differ. Your example using --match
> probably shows a good direction to go in---somehow tell Git which
> tags to
"Kyle J. McKay" writes:
> Either "return to the function that dot-sourced us" or "return from
> the dot command that dot-sourced us",
> but using the original wording
> implies to me that the function that dot-sourced us will return as
> soon as the dot-sourced script executes the return and tha
Andreas Schwab writes:
> Junio C Hamano writes:
>
>> And you are right that the commit is contained in v3.4, so we also
>> should be able to describe it as v3.4~479^2~9^2 as well.
>
> IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git
> describe --contains --match=v3.4\* return
"Luis R. Rodriguez" 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 need close to 500 hops),
>
> Ah! Thanks for explaining this mysterious puzzle to me. I'm a bit
On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote:
> * jl/submodule-recursive-checkout (2013-12-26) 5 commits
> - Teach checkout to recursively checkout submodules
> - submodule: teach unpack_trees() to update submodules
> - submodule: teach unpack_trees() to repopulate submodules
>
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 submodule work tree including any local modifications (and
>even the whole history if it uses a .git directory instead of a
>gitfile!) is simply remo
Am 17.04.2014 10:02, schrieb Gerhard Gappmeier:
> Hi all
>
> in our cross-platform projects we always have a certain Windows-only
> submodule, which contains all the compatibility stuff and missing libraries
> for
> Windows.
>
> When cloning such a repository on a Linux machine the typical pro
On Thu, Apr 17, 2014 at 01:42:42PM +0200, Johan Herland wrote:
> >> +# T2: Test with submodule..url != submodule's remote.origin.url.
> >> Does
> >> +# "submodule update --remote" sync with submodule..url, or with
> >> the
> >> +# submodule's origin? (or with the submodule's current branc
On 17/04/2014 14:47, Torsten Bögershausen wrote:
./uniset/uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c
200B isn't a special case any more, as its database properties have been
changed, so you can slightly simplify this command (both in the commit
message and the comments).
And wh
Unicode 6.3 defines more code points as combining or accents. For
example, the character "ö" could be expressed as an "o" followed by
U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above). We should
consider that such a sequence of two codepoints occupies one display
column for the alignment p
TL;DR: I believe the update-related submodule..* options
(.branch, .update, .url, and even the --remote option) are
slowly growing into a separate DSL for specfying how to update
submodules. This adds a confusing and opaque layer in front of
what is essentially git commands run by "git submodule up
Elia Pinto writes:
> The Git CodingGuidelines prefer the $(...) construct for command
> substitution instead of using the backquotes `...`.
For patches 1 to 14:
Reviewed-by: Matthieu Moy
(reviewed the patches in my mailer, and the "diff --color-words=." after
applying in addition)
--
Matthi
Hi all
in our cross-platform projects we always have a certain Windows-only
submodule, which contains all the compatibility stuff and missing libraries for
Windows.
When cloning such a repository on a Linux machine the typical procedure is:
git clone git@server:project.git
cd project
git submod
Junio C Hamano writes:
> And you are right that the commit is contained in v3.4, so we also
> should be able to describe it as v3.4~479^2~9^2 as well.
IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git
describe --contains --match=v3.4\* returns. This path is only a few
commits
51 matches
Mail list logo
