(apology for the empty message again - sticky fingers in smart phone...)
--
On Thu, Oct 30, 2014 08:46 GMT Eric Wong wrote:
>Thanks, I'm not able to reproduce the issue, but can you try the
>following?
>
>diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
>index 75cd
--
On Thu, Oct 30, 2014 08:46 GMT Eric Wong wrote:
>Hin-Tak Leung wrote:
>> Here is the data dumper info . I tried the dumper code on the R repo
>> as well, and saw that against the virtual box repo, there is one
>> curious difference - $self->{last_rev} is a str
Hi Junio, I haven't heard back from Hin-Tak about the last one
("git-svn: coerce check_path and get_log args to int")[1],
but I think it's a harmless defensive patch in case you
want to tag 2.2-rc0 soon.
I'm also leaving "Git.pm: stat the FD to ensure the file is really open"
out for now...
[1] h
"Kyle J. McKay" wrote:
> On Oct 30, 2014, at 15:08, Eric Wong wrote:
> >For a (currently) unknown reason, Git::SVN::Fetcher::close_file
> >sometimes triggers "Bad file descriptor" errors on syswrite when
> >writing symlink contents on the "svn_hash" tempfile.
> >
> >The current IO::Handle::opened
From: "Jeff King"
On Wed, Oct 29, 2014 at 12:16:05PM -0700, Junio C Hamano wrote:
Probably three helper functions:
- The first is to find tops and bottoms (this translates fuzzy
specifications such as "--since 30.days" into a more concrete
revision range "^A ^B ... Z" to establish bund
On Oct 30, 2014, at 15:08, Eric Wong wrote:
For a (currently) unknown reason, Git::SVN::Fetcher::close_file
sometimes triggers "Bad file descriptor" errors on syswrite when
writing symlink contents on the "svn_hash" tempfile.
The current IO::Handle::opened call in Git.pm is not a
sufficient chec
Dear Tim and Johan,
Are either of you aware of any progress (attempted or otherwise) ever made
on "git fossil"? It would be lovely to have this working.
Respectfully,
Tim
--
View this message in context:
http://git.661346.n2.nabble.com/Git-fossil-bridging-tp7599490p7620514.html
Sent from the
Hin-Tak Leung wrote:
> That's quite straight-forward, I think - except for the recent burst (I am
> essentially
> adapting the git 2.1.0 release shipped by the upcoming fedora 21 scheduled
> for christmas)
> I tend to update to the latest fedora release about a week or two after
> release;
> f
On Thu, Oct 30, 2014 at 3:03 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> At some stage it may becomes too many preferences and over-engineered.
>> Maybe I should drop this patch and then just require the plain "if you
>> want a push to be atomic, then use --atomic-push. end." and we
Jeff King writes:
> I think it would be a nice project to convert git to consistently use
> signed 64-bit times internally, and then everything would Just Work
> going back to the beginning of history. But the demand for such a
> feature has been low enough that nobody has really dug in and tried
For a (currently) unknown reason, Git::SVN::Fetcher::close_file
sometimes triggers "Bad file descriptor" errors on syswrite when
writing symlink contents on the "svn_hash" tempfile.
The current IO::Handle::opened call in Git.pm is not a
sufficient check, as the underlying file descriptor is closed
Ronnie Sahlberg writes:
> At some stage it may becomes too many preferences and over-engineered.
> Maybe I should drop this patch and then just require the plain "if you
> want a push to be atomic, then use --atomic-push. end." and we have
> simple and easy to understand semantics.
As I still do
On Thu, Oct 30, 2014 at 05:08:56PM -0400, Dan Johnson wrote:
> > The underlying data representation records time as number of seconds
> > since epoch (1970-01-01). Theoretically the codepaths that read
> > data could consider negative timestamps to represent times before
> > the epoch, but in the
Hi.
On Thu, Oct 30, 2014 at 08:55:13PM +1100, Paul Mackerras wrote:
> It seems to me that we need the trace only for the
> non-array configuration variables; the array case is only
> for the view definitions, and I think we could just set
> the changed flag for a view explicitly in [newviewok].
>
On Thu, Oct 30, 2014 at 1:11 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> Add receive.preferatomicpush setting to receive-pack.c. This triggers
>> a new capability "prefer-atomic-push" to be sent back to the send-pack
>> client, requesting the client, if it supports it, to request
>>
On Wed, Oct 29, 2014 at 12:16:05PM -0700, Junio C Hamano wrote:
> Probably three helper functions:
>
> - The first is to find tops and bottoms (this translates fuzzy
>specifications such as "--since 30.days" into a more concrete
>revision range "^A ^B ... Z" to establish bundle prerequis
On Thu, Oct 30, 2014 at 11:08:17AM -0700, Junio C Hamano wrote:
> The new helper compute_and_write_prerequistes() is ugly, but it
s/quistes/quisites/
The same typo is in the function name in the code.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
On Thu, Oct 30, 2014 at 11:07:39AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] bundle: split out a helper function to create a pack data
s/a pack data/pack data/
> The create_bundle() function, while it does one single logical thing
> and tries to do it well, that single logical t
On Thu, Oct 30, 2014 at 1:04 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> diff --git a/Documentation/git-send-pack.txt
>> b/Documentation/git-send-pack.txt
>> index 2a0de42..8f64feb 100644
>> --- a/Documentation/git-send-pack.txt
>> +++ b/Documentation/git-send-pack.txt
>> @@ -9,7 +9
On Wed, Oct 29, 2014 at 3:31 PM, Junio C Hamano wrote:
> Peter Vojtek writes:
>
>> It seems the commit date can be between 1970 and 2100 (on my 32bit
>> linux),...
>
> The underlying data representation records time as number of seconds
> since epoch (1970-01-01). Theoretically the codepaths tha
On Thu, Oct 30, 2014 at 12:59 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> @@ -337,6 +341,8 @@ int send_pack(struct send_pack_args *args,
>> strbuf_addstr(&cap_buf, " quiet");
>> if (agent_supported)
>> strbuf_addf(&cap_buf, " agent=%s", git_user_agen
Ronnie Sahlberg writes:
> Add receive.preferatomicpush setting to receive-pack.c. This triggers
> a new capability "prefer-atomic-push" to be sent back to the send-pack
> client, requesting the client, if it supports it, to request
> an atomic push.
I can understand a configuration that says "We
Ronnie Sahlberg writes:
> Update receive-pack to use an atomic transaction iff the client negotiated
> that it wanted atomic-push.
> This leaves the default behavior to be the old non-atomic one ref at a
> time update. This is to cause as little disruption as possible to existing
> clients. It is
Ronnie Sahlberg writes:
> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
> index 2a0de42..8f64feb 100644
> --- a/Documentation/git-send-pack.txt
> +++ b/Documentation/git-send-pack.txt
> @@ -9,7 +9,7 @@ git-send-pack - Push objects over Git protocol to another
> r
Merhaba !
Ekim Kampanyasından faydalanmak ve özel ders ingilizce,toefl,ielts , fransızca
eğitimlerimiz için bizimle iletişime geçebilirsiniz
Not: Yerlerimiz SINIRLI sayıdadır.
Saygılarımızla
KANADA KÜLTÜR MERKEZİ
0212 252 90 35-36
--
To unsubscribe from this list: send the line "unsubscri
Ronnie Sahlberg writes:
> @@ -337,6 +341,8 @@ int send_pack(struct send_pack_args *args,
> strbuf_addstr(&cap_buf, " quiet");
> if (agent_supported)
> strbuf_addf(&cap_buf, " agent=%s", git_user_agent_sanitized());
> + if (atomic_push)
> + strbuf_
Ronnie Sahlberg writes:
> diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c
> index b20b1ec..299768e 100644
> --- a/builtin/pack-refs.c
> +++ b/builtin/pack-refs.c
> @@ -10,6 +10,7 @@ static char const * const pack_refs_usage[] = {
> int cmd_pack_refs(int argc, const char **argv, const char
The callers of get_merge_bases() can choose to leave object flags
used during the merge-base traversal by passing cleanup=0 as a
parameter, but in practice a very few callers can afford to do so
(namely, "git merge-base"), as they need to compute merge base in
preparation for other processing of th
Unless there is a good reason to belieave that a particular
invocation of a get_merge_bases*() is the last one that cares about
the object flags the computation of merge bases leaves on the
objects, the "cleanup" parameter should always be true, and I do not
think there is one in this codepath.
Fo
On Wed, Oct 29, 2014 at 11:43 AM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano wrote:
>>
>>> More importantly, when you know that the end result you want to see
>>> is that the old and new log files are bit-for-bit identical, and if
>>> not
>> ---
>>
>> Hi,
>>
>> You were right, one of the functions was calling git_config_parse_key()
>> which was leaking errors to the console. git_config_parse_key() was
>> meant for sanitizing user provided keys only but it was being used
>> internally in a place where only a return value would be eno
Tanay Abhra writes:
> `git_config_parse_key()` is used to sanitize the input key.
> Some callers of the function like `git_config_set_multivar_in_file()`
> get the pre-sanitized key directly from the user so it becomes
> necessary to raise an error specifying what went wrong when the entered
> ke
>From c87ddf6397964154932d49385ed1433b62631f30 Mon Sep 17 00:00:00 2001
From: Tanay Abhra
Date: Thu, 30 Oct 2014 08:54:58 -0700
Subject: [PATCH] config: add show_err flag to git_config_parse_key()
`git_config_parse_key()` is used to sanitize the input key.
Some callers of the function like `git_c
The new helper compute_and_write_prerequistes() is ugly, but it
cannot be avoided. Ideally we should avoid a function that computes
and does I/O at the same time, but the prerequisites lines in the
output needs the human readable title only to help the recipient of
the bundle. The code copies the
Junio C Hamano writes:
> Probably three helper functions:
>
> - The first is to find tops and bottoms (this translates fuzzy
>specifications such as "--since 30.days" into a more concrete
>revision range "^A ^B ... Z" to establish bundle prerequisites),
>which is done by running a "r
2014-10-30 18:44 GMT+03:00 W. Trevor King :
> On Thu, Oct 30, 2014 at 06:39:56PM +0300, Dmitry Oksenchuk wrote:
>> We're in the middle of conversion of a large CVS repository (20
>> years, 70K commits, 1K branches, 10K tags) to Git and considering
>> two separate Git repositories: "historical" with
`git_config_parse_key()` is used to sanitize the input key.
Some callers of the function like `git_config_set_multivar_in_file()`
get the pre-sanitized key directly from the user so it becomes
necessary to raise an error specifying what went wrong when the entered
key is defective.
Other callers l
Hi Christian,
Thanks for your reply.
2014-10-30 19:54 GMT+03:00 Christian Couder :
> On Thu, Oct 30, 2014 at 4:39 PM, Dmitry Oksenchuk
> wrote:
>> We're in the middle of conversion of a large CVS repository (20 years,
>> 70K commits, 1K branches, 10K tags) to Git and considering two
>> separate
Peter Vojtek writes:
> It seems the commit date can be between 1970 and 2100 (on my 32bit
> linux), however man git (section DATE FORMATS) claims ISO 8601
> standard is supported.
The date formats section of "git log" only talks about the output
format (I do not see in "man git" any section abou
Hi,
On Thu, Oct 30, 2014 at 4:39 PM, Dmitry Oksenchuk wrote:
> Hello,
>
> We're in the middle of conversion of a large CVS repository (20 years,
> 70K commits, 1K branches, 10K tags) to Git and considering two
> separate Git repositories: "historical" with CVS history and "working"
> created with
On Mon, Oct 27, 2014 at 8:10 AM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/dir.c b/dir.c
> index 2793e57..55780a7 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -37,7 +37,12 @@ enum path_treatment {
> +static enum path_treatment treat_path_fast(struct dir_struct *dir,
> +
Commit b74884b86 ("untracked cache: make a wrapper around
{open,read,close}dir()", 27-10-2014) added the read_cached_dir()
function as an external symbol.
Noticed by sparse. ("'read_cached_dir' was not declared. Should it
be static?").
Signed-off-by: Ramsay Jones
---
Hi Duy,
If you need to re
On Thu, Oct 30, 2014 at 06:39:56PM +0300, Dmitry Oksenchuk wrote:
> We're in the middle of conversion of a large CVS repository (20
> years, 70K commits, 1K branches, 10K tags) to Git and considering
> two separate Git repositories: "historical" with CVS history and
> "working" created without hist
Hello,
We're in the middle of conversion of a large CVS repository (20 years,
70K commits, 1K branches, 10K tags) to Git and considering two
separate Git repositories: "historical" with CVS history and "working"
created without history from heads of active branches (10 active
branches). This allow
Greetings!
(Sorry for first untitled message)
I have very large git repository (>20Gb) and after repack the size of it
increases by 1.3-2 times.
I try to understand why it is happened and how to solve this matter.
Details
I work in gamedev and we store under git all what we have: source code,
% git foo_bar
error: invalid key: pager.foo_bar
error: invalid key: alias.foo_bar
git: 'foo_bar' is not a git command. See 'git --help'.
git.c calls alias_lookup() and check_pager_config() resulting in calls
to git_config_parse_key() with the above keys. I looked at the code
and it's not immediate
Greetings!
I have very large git repository (>20Gb) and after repack the size of it
increases by 1.3-2 times.
I try to understand why it is happened and how to solve this matter.
Details
I work in gamedev and we store under git all what we have: source code,
textures and other binary data.
Now
To get number of elements in an array git use the ARRAY_SIZE macro defined as:
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
The problem with it is a possibility of mistakenly passing to it a
pointer instead an array.
Use instead a different but compatible ARRAY_SIZE() macro,
which (given a g
Jakub Narębski schrieb am 25.10.2014 um 10:30:
> W dniu 2014-10-22 21:02, Junio C Hamano pisze:
>
>> A mergetag is not fundamentally a "signature" in the above sense,
>> though. It is just a dump of the object content in a regular object
>> header field (hence indented by one SP), and its content
On Sun, Sep 14, 2014 at 11:35:58PM +0300, Max Kirillov wrote:
> When gitk contains some changed parameter, and there is existing
> instance of gitk where the parameter is still old, it is reverted to
> that old value when the instance exits.
>
> Instead, store a parameter in config only it is has
On Sun, Sep 14, 2014 at 11:35:57PM +0300, Max Kirillov wrote:
> Signed-off-by: Max Kirillov
This is a nice simplification, applied, thanks.
Paul.
--
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:/
Hin-Tak Leung wrote:
> Here is the data dumper info . I tried the dumper code on the R repo
> as well, and saw that against the virtual box repo, there is one
> curious difference - $self->{last_rev} is a string rather than a number.
> I tried hacking around doing "$x += 0;" to coerce last_rev
>
And minor reformatting while we're in the area.
Signed-off-by: Eric Wong
---
perl/Git/SVN.pm | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 893b9a8..d9a52a5 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1798,12 +1798,10
Neither find_extra_svk_parents or find_extra_svn_parents ever
used the `$ed' parameter.
Signed-off-by: Eric Wong
---
perl/Git/SVN.pm | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 5f9d469..893b9a8 100644
--- a/perl/Git/SVN.p
54 matches
Mail list logo
