On 25/08/14 02:54, tsuna wrote:
On Sun, Aug 24, 2014 at 5:32 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
Again, I don't have access to an OS X system, so I don't know
which package provides libintl/gettext, but it seems to be missing
on your system.
Probably yeah, those libraries
On Sun, Aug 24, 2014 at 06:07:44PM +0200, Steffen Prohaska wrote:
diff --git a/wrapper.c b/wrapper.c
index bc1bfb8..69d1c9b 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -11,14 +11,18 @@ static void (*try_to_free_routine)(size_t size) =
do_nothing;
static void memory_limit_check(size_t
On Sun, Aug 24, 2014 at 06:07:46PM +0200, Steffen Prohaska wrote:
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media.
On Sun, Aug 24, 2014 at 08:22:41PM +0700, Gábor Szeder wrote:
On Aug 23, 2014 12:26 PM, Jeff King p...@peff.net wrote:
Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally
On Sun, Aug 24, 2014 at 04:39:37PM -0700, Junio C Hamano wrote:
On Sun, Aug 24, 2014 at 8:10 AM, Stefan Beller stefanbel...@gmail.com wrote:
for (p = list, i = 0; i cnt; i++) {
- struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ char name[100];
On Sun, Aug 24, 2014 at 07:47:24PM +0530, Arjun Sreedharan wrote:
diff --git a/bisect.c b/bisect.c
index d6e851d..c96aab0 100644
--- a/bisect.c
+++ b/bisect.c
@@ -215,10 +215,13 @@ static struct commit_list *best_bisection_sorted(struct
commit_list *list, int n
}
qsort(array,
On Fri, Aug 22, 2014 at 11:00 AM, Marc Branchaud marcn...@xiplink.com wrote:
A couple of years ago I started to work on such a thing ([1] [2] [3]), mainly
because when we tried to change to relative submodules we got bitten when
someone used clone's -o option so that his super-repo had no
On Mon, Aug 25, 2014 at 3:35 PM, Jeff King p...@peff.net wrote:
On Sun, Aug 24, 2014 at 07:47:24PM +0530, Arjun Sreedharan wrote:
diff --git a/bisect.c b/bisect.c
index d6e851d..c96aab0 100644
--- a/bisect.c
+++ b/bisect.c
@@ -215,10 +215,13 @@ static struct commit_list
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule settings I think a much
much simpler start is to go ahead with a commandline
On Mon, Aug 25, 2014 at 9:29 AM, Robert Dailey rcdailey.li...@gmail.com wrote:
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule
On Mon, Aug 25, 2014 at 04:06:52PM +0200, Christian Couder wrote:
This allocation should be name_len + 1 for the NUL-terminator, no?
I wondered about that too, but as struct name_decoration is defined like this:
struct name_decoration {
struct name_decoration *next;
int
On Aug 25, 2014, at 1:38 PM, Jeff King p...@peff.net wrote:
On Sun, Aug 24, 2014 at 06:07:44PM +0200, Steffen Prohaska wrote:
diff --git a/wrapper.c b/wrapper.c
index bc1bfb8..69d1c9b 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -11,14 +11,18 @@ static void (*try_to_free_routine)(size_t
On Mon, Aug 25, 2014 at 05:06:22PM +0200, Steffen Prohaska wrote:
I think it's reasonable that GIT_ALLOC_LIMIT=0 means no limit, so that
the limit can easily be disabled temporarily.
IMHO, GIT_ALLOC_LIMIT= (i.e., the empty string) would be a good way to
say that (and I guess that even works
Dear Git Developers,
since 1974 researchers and software developers try to ease software
debugging. Over the last years, they created many new tools and
formalized methods. We are interested if these advancements have
reached professional software developers and how they influenced their
Am 23.08.2014 um 13:18 schrieb Jeff King:
On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in
On Aug 25, 2014, at 2:43 PM, Jeff King p...@peff.net wrote:
On Sun, Aug 24, 2014 at 06:07:46PM +0200, Steffen Prohaska wrote:
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for
Jeff,
We have a fix like this in the next set of transaction updates.
https://code-review.googlesource.com/#/c/1012/13/fast-import.c
However, if your concerns are the integrity of the servers and not
taking any chances
you might not want to wait for my patches to graduate.
ronnie sahlberg
On
Jaime Soriano Pastor jsorianopas...@gmail.com writes:
I think this line is dangerous, if add_cache_entry is not able to
remove higher-stages it will be looping forever, as happens in the
case of this thread.
I cannot see why it's even needed, and removing it doesn't break any test.
On Sun,
Print an error before returning when pack_data is NULL ?
Otherwise, LGTM
On Fri, Aug 22, 2014 at 10:27 PM, Jeff King p...@peff.net wrote:
We have a global pointer pack_data pointing to the current
pack we have open. Inside end_packfile we have two new
pointers, old_p and new_p. The latter
On Sat, Aug 23, 2014 at 3:56 AM, Jeff King p...@peff.net wrote:
[+cc spearce, as I think this is a bug in code.google.com's sending
side, and he can probably get the attention of the right folks]
...
My guess is a bug on the sending side. We have seen duplicate pack
objects before, but never
Jaime Soriano Pastor jsorianopas...@gmail.com writes:
Subject: Re: [PATCH 1/2] Check order when reading index
Please be careful when crafting the commit title. This single line
will be the only one that readers will have to identify the change
among hundreds of entries in git shortlog output
The next ref transaction series does a similar change and ends up
removing the function lock_ref_sha1() completely.
https://code-review.googlesource.com/#/c/1017/19/refs.c
So I think we can drop this patch.
ronnie sahlberg
On Fri, Aug 22, 2014 at 10:33 PM, Jeff King p...@peff.net wrote:
We
On Fri, Aug 22, 2014 at 10:23 PM, Jeff King p...@peff.net wrote:
I noticed that git pack-refs --all will pack a top-level ref like
refs/foo, but will not actually prune $GIT_DIR/refs/foo. I do not
see the point in having a policy not to pack refs/foo if --all is
given. But even if we did have
Torsten Bögershausen tbo...@web.de writes:
On 2014-08-23 00.54, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
incorrectly set on Mingw git. However, the Makefile variable is not
propagated to the C
On Fri, Aug 22, 2014 at 10:46 PM, Jeff King p...@peff.net wrote:
On Fri, Aug 22, 2014 at 11:45:15AM -0700, Jonathan Nieder wrote:
Junio C Hamano wrote:
implication of which is that the 'at least one slash'
rule was to expect things are 'refs/anything' so there will be at
Torsten Bögershausen tbo...@web.de writes:
Fix the broken chain
Reported-By: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Please fold this kind of oops fix breakages discovered in the
version that hasn't been reached 'next' to the patch that
Shawn Pearce spea...@spearce.org writes:
A stateless nonce could look like:
nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key )
where site_key is a private key known to the server. It doesn't have
to be per-repo.
receive-pack would then be willing to accept any nonce whose
Stefan Beller stefanbel...@gmail.com writes:
burden is not an issue, as I'll be signing the push certificate
anyway when I push. A signed tag or a signed commit and signed push
certificate solves two completely separate and orthogonal issues.
What happens if you break into GitHub or k.org
Ronnie Sahlberg wrote:
On Fri, Aug 22, 2014 at 10:46 PM, Jeff King p...@peff.net wrote:
Yeah, this weird do not allow refs/foo behavior has continually
confused me. Coincidentally I just noticed a case today where
pack-refs treats refs/foo specially for no good reason:
Jeff King p...@peff.net writes:
On Mon, Aug 25, 2014 at 04:06:52PM +0200, Christian Couder wrote:
This allocation should be name_len + 1 for the NUL-terminator, no?
I wondered about that too, but as struct name_decoration is defined like
this:
struct name_decoration {
struct
Steffen Prohaska proha...@zib.de writes:
Couldn't we do that with an lseek (or even an mmap with offset 0)? That
obviously would not work for non-file inputs, but I think we address
that already in index_fd: we push non-seekable things off to index_pipe,
where we spool them to memory.
It
-Original Message-
From: Junio C Hamano
Sent: Monday, August 25, 2014 13:55
Stefan Beller stefanbel...@gmail.com writes:
burden is not an issue, as I'll be signing the push certificate
anyway when I push. A signed tag or a signed commit and
signed push
certificate solves
On Mon, Aug 25, 2014 at 10:16:52AM -0700, Ronnie Sahlberg wrote:
Print an error before returning when pack_data is NULL ?
I don't think so. We call end_packfile in some code paths (like the die
handler) as close if it's open. So I think it makes sense for it to be
a noop if nothing is open.
On Mon, Aug 25, 2014 at 10:38:56AM -0700, Ronnie Sahlberg wrote:
[1/5]: git-prompt: do not look for refs/stash in $GIT_DIR
[2/5]: pack-refs: prune top-level refs like refs/foo
[3/5]: fast-import: clean up pack_data pointer in end_packfile
[4/5]: fast-import: fix buffer overflow in
Ronnie Sahlberg sahlb...@google.com writes:
There are also a lot of places where we assume that a refs will start
with refs/heads/ and not just refs/
for_each_branch_ref(), log_ref_setup() (so no reflogs) is_branch() to
name a few.
for-each-BRANCH-ref and is-BRANCH are explicitly about
On Mon, Aug 25, 2014 at 11:26:36AM -0700, Jonathan Nieder wrote:
It's still very puzzling to me. The comment came at the same time as
the behavior, in v0.99.9~120 (git-check-ref-format: reject funny ref
names, 2005-10-13). Before that, the behavior was even stranger ---
it checked that
Jeff King p...@peff.net writes:
Since we do not use the value $(LIB_H) unless either
COMPUTE_HEADER_DEPENDENCIES is turned on or the user is
building po/git.pot (where it comes in via $(LOCALIZED_C),
make is smart enough to not even run this find in most
cases. However, we do need to stop
On Mon, Aug 25, 2014 at 12:30:51PM -0700, Junio C Hamano wrote:
Also interestingly, I notice that it is very clear that it is not
LIB_H but ANY_H ;-)
Yeah, it has been that way for quite a while. I don't know if it is that
big a deal, but it would not be unreasonable to do a patch to rename on
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want to steal Arjun's thunder.
Arjun, did my proposal make sense? Do you want to try implementing that?
-Peff
--
On Mon, Aug 25, 2014 at 10:21:58AM -0700, Junio C Hamano wrote:
+ if (ce_stage(ce) = ce_stage(next_ce))
+ die(Unordered stage entries for '%s',
+ ce-name);
Not quite. We do allow multiple higher stage entries; having two or
more
Jeff King wrote:
-LOCALIZED_C := $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H)
+LOCALIZED_C = $(C_OBJ:o=c) $(GENERATED_H)
Why is LIB_H dropped here? This would mean that po/git.pot stops
including strings from macros and static inline functions in headers
(e.g., in parse-options.h).
The rest looks
On Mon, Aug 25, 2014 at 12:46:41PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
-LOCALIZED_C := $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H)
+LOCALIZED_C = $(C_OBJ:o=c) $(GENERATED_H)
Why is LIB_H dropped here? This would mean that po/git.pot stops
including strings from macros and static
On Mon, Aug 25, 2014 at 04:00:42PM -0400, Jeff King wrote:
On Mon, Aug 25, 2014 at 12:46:41PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
-LOCALIZED_C := $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H)
+LOCALIZED_C = $(C_OBJ:o=c) $(GENERATED_H)
Why is LIB_H dropped here? This would
Am 2014-08-19 um 19:51 schrieb Junio C Hamano:
This looks strange and stands out like a sore thumb. Do any of our
other sources do this kind of macro tweaking inside C source before
including git-compat-util.h (or its equivalent like cache.h)?
I haven't checked, but I agree that it's
On Mon, Aug 25, 2014 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote:
Jaime Soriano Pastor jsorianopas...@gmail.com writes:
Subject: Re: [PATCH 1/2] Check order when reading index
Please be careful when crafting the commit title. This single line
will be the only one that readers will
On 26 August 2014 01:05, Jeff King p...@peff.net wrote:
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want to steal Arjun's thunder.
Please feel free to do so.
Jeff King wrote:
It is unfortunately easy for our static header list to grow
stale, as none of the regular developers make use of it.
Instead of trying to keep it up to date, let's invoke find
to generate the list dynamically.
Yep, I like this.
It does mean that people who run make pot have
On Mon, Aug 25, 2014 at 12:44 PM, Jeff King p...@peff.net wrote:
For my own curiosity, how do you get into this situation, and what does
it mean to have multiple stage#1 entries for the same path? What would
git cat-file :1:path output?
That is how we natively (read: not with the funky virtual
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
It is unfortunately easy for our static header list to grow
stale, as none of the regular developers make use of it.
Instead of trying to keep it up to date, let's invoke find
to generate the list dynamically.
Yep, I like this.
Bernhard Reiter ock...@raz.or.at writes:
Yeah, but I still need to wrap the non-tunneled operation in #ifdefs in
case we don't USE_CURL_FOR_IMAP_SEND in which case we fall back to the
handwritten IMAP code, don't I?
We do not mind multiple implementations of the same helper function
that are
Jeff King p...@peff.net writes:
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want to steal Arjun's thunder.
Hmph, would it have to overlap? I think we can
Arjun Sreedharan arjun...@gmail.com writes:
Find and allocate the required amount instead of allocating extra
100 bytes
Signed-off-by: Arjun Sreedharan arjun...@gmail.com
---
Interesting. How much memory do we typically waste (in other words,
how big did cnt grew in your repository where
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Tiny nit: I might use
$(shell $(FIND) * \
-name . -o
-name '.*' -prune -o \
-name t -prune -o \
-name Documentation -prune -o \
-name '*.h' -print)
or
Jeff King p...@peff.net writes:
The string will always be dist= followed by decimal representation of
a count that fits in int anyway, so I actually think use of strbuf is way
overkill (and formatting it twice also is); the patch as posted should be
just fine.
I think you are right, and the
Jonathan Nieder jrnie...@gmail.com writes:
Wouldn't it be sufficient to start digging not from * but from
??*?
Gah, the * was supposed to be . in my examples (though it doesn't
hurt).
find ??* \( -name Documentation -o -name .\?\* \) -prune -o -name \*.h
Heh. Yeah, that would work.
Jiang Xin worldhello@gmail.com writes:
The following changes since commit 49f1cb93a2f11845cfa2723611a729d3d7f02f0d:
Git 2.1.0-rc0 (2014-07-27 15:22:22 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po
for you to fetch changes up to
Steffen Prohaska proha...@zib.de writes:
It is only the path that matters in the decision whether to filter or
not. Clarify this by making path the single argument of
would_convert_to_git().
Signed-off-by: Steffen Prohaska proha...@zib.de
---
I've retitled this as:
convert: drop
On Thu, Jul 3, 2014 at 2:41 PM, Øyvind A. Holm su...@sunbase.org wrote:
On 2 July 2014 16:50, Robert Dailey rcdailey.li...@gmail.com wrote:
I know that with the `git branch` command I can determine which
branches contain a commit. Is there a way to represent this
graphically with `git log`?
Jonathan Nieder wrote:
Ronnie Sahlberg wrote:
ref-transaction-1 (2014-07-16) 20 commits
-
Second batch of ref transactions
- refs.c: make delete_ref use a transaction
- refs.c: make prune_ref use a transaction to delete the ref
59 matches
Mail list logo
