On 25/08/14 02:54, tsuna wrote:
> On Sun, Aug 24, 2014 at 5:32 PM, Ramsay Jones
> 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 don’t seem to be pr
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(si
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 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 externa
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 wrote:
> >> for (p = list, i = 0; i < cnt; i++) {
> >> - struct name_decoration *r = xmalloc(sizeof(*r) + 100);
> >> + char name[100];
> >
> > Would it ma
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
On Fri, Aug 22, 2014 at 11:00 AM, Marc Branchaud 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 "origin" remote
> *and*
On Mon, Aug 25, 2014 at 3:35 PM, Jeff King 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
>> *best_bisection_so
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt 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 setting, like
> Ro
On Mon, Aug 25, 2014 at 9:29 AM, Robert Dailey wrote:
> On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt wrote:
>> New --with--remote parameter for 'git submodule'
>>
>>
>> While having said all that about submodule settings I think a much
>> much simp
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;
>
On Aug 25, 2014, at 1:38 PM, Jeff King 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 size)
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
approach.
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
>> infra
On Aug 25, 2014, at 2:43 PM, Jeff King 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 example
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 Fr
Jaime Soriano Pastor 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, Aug 24, 2014 at 7:5
Print an error before returning when pack_data is NULL ?
Otherwise, LGTM
On Fri, Aug 22, 2014 at 10:27 PM, Jeff King 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 points to pack
On Sat, Aug 23, 2014 at 3:56 AM, Jeff King 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 (AFAIK) co
Jaime Soriano Pastor 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 when trying to
see what
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 wrote:
> We can use lock_a
On Fri, Aug 22, 2014 at 10:23 PM, Jeff King 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 writes:
> On 2014-08-23 00.54, Junio C Hamano wrote:
>> Torsten Bögershausen 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 preprocessor and
On Fri, Aug 22, 2014 at 10:46 PM, Jeff King 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/' so there will be at
>> > least on
Torsten Bögershausen writes:
> Fix the broken && chain
>
> Reported-By: Eric Sunshine
> Signed-off-by: Torsten Bögershausen
> ---
Please fold this kind of "oops fix breakages discovered in the
version that hasn't been reached 'next'" to the patch that
introduces the breakage, with "Helped-by:
Shawn Pearce 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 timestamp
> is wit
Stefan Beller 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 and did
>>
Ronnie Sahlberg wrote:
> On Fri, Aug 22, 2014 at 10:46 PM, Jeff King 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:
>>
>> http://thread.gm
Jeff King 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 {
>> stru
Steffen Prohaska 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 could be
> -Original Message-
> From: Junio C Hamano
> Sent: Monday, August 25, 2014 13:55
>
> Stefan Beller 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 co
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 ov
Ronnie Sahlberg 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 branches and
it i
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 t
Jeff King 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 using t
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 rena
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 o
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 g
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
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?
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 desira
On Mon, Aug 25, 2014 at 7:21 PM, Junio C Hamano wrote:
> Jaime Soriano Pastor 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 h
On 26 August 2014 01:05, Jeff King 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 po
On Mon, Aug 25, 2014 at 12:44 PM, Jeff King 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" stuff
Jonathan Nieder 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.
>
> It
Bernhard Reiter 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 guarded with #
Jeff King 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 queue A
Arjun Sreedharan writes:
> Find and allocate the required amount instead of allocating extra
> 100 bytes
>
> Signed-off-by: Arjun Sreedharan
> ---
Interesting. How much memory do we typically waste (in other words,
how big did "cnt" grew in your repository where you noticed this)?
> bisect.c
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Tiny nit: I might use
>>
>> $(shell $(FIND) * \
>> -name . -o
>> -name '.*' -prune -o \
>> -name t -prune -o \
>> -name Documentation -prune -o \
>> -name '*.h' -print)
>>
>> o
Jeff King 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 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 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 f7fbc357f863ecc5323f3fcf2fc9cbf2aa
Steffen Prohaska 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
> ---
I've retitled this as:
convert: drop arguments other than 'path' f
On Thu, Jul 3, 2014 at 2:41 PM, Øyvind A. Holm wrote:
> On 2 July 2014 16:50, Robert Dailey 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`? Sometimes I just have a commit, and I
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 del
On Mon, Aug 25, 2014 at 09:29:07AM -0500, Robert Dailey wrote:
> On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt wrote:
> > New --with--remote parameter for 'git submodule'
> >
> >
> > While having said all that about submodule settings I think a much
60 matches
Mail list logo
