This type of functionality is directly supported by the work I've already done
on symlinks here: https://github.com/frogonwheels/git
(branches mrg/symlink-v* )
Even if we agree that symlinks only work to a limited degree, or that there
are definite limitations, and that the default should
Hi Josef,
On Fri, Aug 09, 2013 at 11:20:46AM -0400, Josef 'Jeff' Sipek wrote:
> On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote:
> > ?? 2013-8-9??10:46??Josef 'Jeff' Sipek д
> >
> > > On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
> > >> From: Zheng Liu
> > >>
Ramsay Jones writes:
> On 18/08/2013 08:41 PM, Thomas Gummerer wrote:
>> Cygwin doesn't have uid, gid and ino stats fields. Therefore we should
>> never check them in the match_stat_data when working on the CYGWIN
>> platform.
>
> Hmm, this is simply not true ... ;-)
>
> The need to omit the uid
Hello,
On Mon, Aug 19, 2013 at 3:55 PM, Johan Herland wrote:
> On Mon, Aug 19, 2013 at 10:13 AM, Francis Moreau
> wrote:
>> Hello,
>>
>> Is it possible to keep submodules notes in the super project ?
>
> Not easily. I guess it depends on what you want to use the notes for.
> In order for notes
Eric Sunshine writes:
> On Sun, Aug 18, 2013 at 3:41 PM, Thomas Gummerer wrote:
>> A partially read index file currently cannot be written to disk. Make
>> sure that never happens, by erroring out when a caller tries to write a
>
> s/,//
>
>> partially read index. Do the same when trying to re
The deflate loop in bulk-checkin::stream_to_pack expects to get all bytes
from a file that it requests to read in a single function call. But it
used xread(), which does not give that guarantee. Replace it by
read_in_full().
Signed-off-by: Johannes Sixt
---
The size is limited to sizeof(ibuf) ==
On Tue, Aug 20, 2013 at 10:39 AM, Francis Moreau wrote:
>> On Mon, Aug 19, 2013 at 3:55 PM, Johan Herland wrote:
>> On Mon, Aug 19, 2013 at 10:13 AM, Francis Moreau
>> wrote:
>>> Is it possible to keep submodules notes in the super project ?
>>
>> Not easily. I guess it depends on what you wan
The condition as it is written in that line was most likely intended to
check for the pointer passed to free(), rather than checking for the
'repo_abbrev', which is already checked against being non null at the
beginning of the function.
Signed-off-by: Stefan Beller
---
mailmap.c | 2 +-
1 file
I didn't look at functions above cmd_repack.
Am 20.08.2013 01:23, schrieb Stefan Beller:
+int cmd_repack(int argc, const char **argv, const char *prefix) {
+
+ int pack_everything = 0;
+ int pack_everything_but_loose = 0;
+ int delete_redundant = 0;
+ char *unpack_unreach
Stefan Beller writes:
> The condition as it is written in that line was most likely intended to
> check for the pointer passed to free(), rather than checking for the
> 'repo_abbrev', which is already checked against being non null at the
> beginning of the function.
[...]
> -
On Tue, Aug 20, 2013 at 03:40:02PM +0200, Thomas Rast wrote:
> Stefan Beller writes:
>
> > The condition as it is written in that line was most likely intended to
> > check for the pointer passed to free(), rather than checking for the
> > 'repo_abbrev', which is already checked against being no
General comment: a short comment before each function describing what
the function does would be helpful. This only applies for complex
functions (read_* ones). Of course verify_hdr does not require extra
explanantion.
On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer wrote:
> +static struct dire
On 08/20/2013 03:40 PM, Thomas Rast wrote:
> Stefan Beller writes:
>
>> The condition as it is written in that line was most likely intended to
>> check for the pointer passed to free(), rather than checking for the
>> 'repo_abbrev', which is already checked against being non null at the
>> begin
On Tue, Aug 20, 2013 at 12:08:08PM +0700, Nguyen Thai Ngoc Duy wrote:
> This may provide some clues for those who want to modify smart http
> code as smart http is pretty much undocumented. Smart http "document"
> so far is a few commit messages and the source code.
There was also this:
http:/
On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer wrote:
> +static int read_entry(struct cache_entry **ce, char *pathname, size_t
> pathlen,
> + void *mmap, unsigned long mmap_size,
> + unsigned int first_entry_offset,
> + unsigned int fo
The condition as it is written in that line has already been checked
in the beginning of the function, which was introduced in
8503ee4 (2007-05-01, Fix read_mailmap to handle a caller uninterested
in repo abbreviation)
Helped-by: Jeff King
Helped-by: Thomas Rast
Signed-off-by: Stefan Beller
---
On Tue, Aug 20, 2013 at 9:16 PM, Jeff King wrote:
> On Tue, Aug 20, 2013 at 12:08:08PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> This may provide some clues for those who want to modify smart http
>> code as smart http is pretty much undocumented. Smart http "document"
>> so far is a few commit mess
Stefan Beller writes:
> As I am resending the patch, could somebody please explain me
> the mechanism of the "# repo-abbrev:" line? Even git itself doesn't
> use it in the .mailmap file, but a quick google search shows up only
> kernel repositories.
I had no idea (we really lack documentation on
On Tue, Aug 20, 2013 at 04:18:00PM +0200, Stefan Beller wrote:
> The condition as it is written in that line has already been checked
> in the beginning of the function, which was introduced in
> 8503ee4 (2007-05-01, Fix read_mailmap to handle a caller uninterested
> in repo abbreviation)
>
> Hel
On Tue, Aug 20, 2013 at 01:15:02AM +0200, Erik Faye-Lund wrote:
> This one seems real, although it's quite theoretical. It should only happen
> in cases where the log-message contains "%1", the initial malloc passed and
> reallocing two more bytes failed.
>
> However, what's much more of a disast
On Tue, Aug 20, 2013 at 04:17:07PM +0200, Stefan Beller wrote:
> Stepping two steps back, I am trying to figure out, what this repo_abrev
> thing is doing, as I could find no documentation.
It's meant to abbreviate long pathnames in subject lines. As you noted,
the kernel .mailmap has:
# repo-
On 08/20/2013 04:23 PM, Thomas Rast wrote:
> Stefan Beller writes:
>
>> As I am resending the patch, could somebody please explain me
>> the mechanism of the "# repo-abbrev:" line? Even git itself doesn't
>> use it in the .mailmap file, but a quick google search shows up only
>> kernel repositori
Johannes Sixt writes:
> The deflate loop in bulk-checkin::stream_to_pack expects to get all bytes
> from a file that it requests to read in a single function call. But it
> used xread(), which does not give that guarantee. Replace it by
> read_in_full().
>
> Signed-off-by: Johannes Sixt
> ---
>
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
>
> Are the long forms of options your invention?
I tried to keep strong similarity with the shell script for
ease of review. In the shellscript the options where
put in variables having these names, so for example there was:
-f) no_reuse
TL;DR -- "git apply --reject" implies verbose, but the similar
"git apply --check" does not, which seems inconsistent.
Background: A common (non-git) workflow can be to use "patch --dry-run"
to inspect whether a patch is feasible, and then use patch again
a 2nd time (w/o --dry-run) to actually ap
On Sat, Jul 20, 2013 at 2:22 AM, Jeff King wrote:
> I do plan to finish it eventually, but if anyone else feels like picking
> it up, I'd be glad to review patches and/or share my work-in-progress as
> a starting point.
Hi Jeff,
I have some free time to come, and would like to work on that featur
On Tue, Aug 20, 2013 at 5:00 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> The deflate loop in bulk-checkin::stream_to_pack expects to get all bytes
>> from a file that it requests to read in a single function call. But it
>> used xread(), which does not give that guarantee. Replace it b
On Tue, Aug 20, 2013 at 03:44:16PM +0800, Zheng Liu wrote:
> Hi Josef,
>
> On Fri, Aug 09, 2013 at 11:20:46AM -0400, Josef 'Jeff' Sipek wrote:
> > On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote:
> > > ?? 2013-8-9??10:46??Josef 'Jeff' Sipek д
> > >
> > > > On Fri, Aug 09, 20
On Tue, Aug 20, 2013 at 04:38:17PM +0200, Stefan Beller wrote:
> As proposed I checked recent kernel history and saw:
>
> $ git log --min-parents=2 --oneline
> d6a5e06 Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
> 7067552 Merge branch 'x86-urgent-for-linus' of
>
Jeff King writes:
> It _only_ impacts git-shortlog, not git-log or other traversals. Making
> it an even more dubious feature, IMHO.
I think this was done by an explicit end user request for shortlog.
As you mentioned, merge gives readable merge log messages, but it
deliberately uses the real U
On the repository summary page, leave the owner line out if the
repo does not have an owner, rather than displaying a labelled empty
field. This does not affect the owner column in the projects list
page, which is present unless $omit_owner is true.
Signed-off-by: Tony Finch
---
gitweb/gitweb.pe
The rss_logo CSS style has a fixed width which is too narrow for
the string "OPML". Replace the fixed width with horizontal padding
so the text fits with nice margins.
Signed-off-by: Tony Finch
---
gitweb/static/gitweb.css | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git
The search help link was a superscript question mark right next to
a drop-down menu, which looks misaligned and is a cramped and
awkward click target. Remove the superscript tags and add some
spacing to fix these nits. Add a title attribute to provide an
explanatory mouseover.
Signed-off-by: Tony
Signed-off-by: Tony Finch
---
gitweb/static/gitweb.css | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index a869be1..3b4d833 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -68,12 +68,13 @@ div.page
This is mostly just a repost to un-stall this topic.
I have fixed the tab damage problem spotted by Jakub in the search
help link patch, and I have improved the commit message for the
repository owner patch. No other changes.
Tony Finch (4):
gitweb: Ensure OPML text fits inside its box.
gitwe
On Tue, Aug 20, 2013 at 10:18:08AM -0700, Junio C Hamano wrote:
> As you mentioned, merge gives readable merge log messages, but it
> deliberately uses the real URL, not your personal nickname for the
> remote when writing the title line of a merge, i.e.
>
> Merge [branch of ]
>
> so it w
Paul Gortmaker writes:
> TL;DR -- "git apply --reject" implies verbose, but the similar
> "git apply --check" does not, which seems inconsistent.
Hmmm, I am of two minds. From purely idealistic point of view, I
can see why defaulting both to non-verbose may look a more
attractive way to go, but
Am 20.08.2013 17:00, schrieb Junio C Hamano:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Looking at the grep -C1 output, there are no others.
The only one that looked suspicious was xread in remote-curl.c, but it is
fine (it just eats all data from the input).
Antoine Pelisse writes:
> I was actually wondering when it's better to use xread() over
> read_in_full()?
When the caller wants to do more control over a read that may have
to loop. For example, this loop in builtin/index-pack.c::fill()
do {
ssize_t ret = xread(input_fd
Am 20.08.2013 17:16, schrieb Antoine Pelisse:
I was actually wondering when it's better to use xread() over
read_in_full() ? Considering that we don't know if xread() will read
the whole buffer or not, would it not be better to always use
read_in_full() ?
Of course, you know whether the whole b
Am 20.08.2013 17:08, schrieb Stefan Beller:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
You cannot run_command() and then later read its output! You must split
it into start_command(), read stdout, finish_command().
Thanks for this hint. Could that explain rare non-deterministic failures in
t
Erik Faye-Lund writes:
> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
> index d015e43..0641f4e 100644
> --- a/compat/win32/syslog.c
> +++ b/compat/win32/syslog.c
> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)
> va_end(ap);
>
> while ((pos = strstr(str, "%1
On 13-08-20 01:57 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
>> TL;DR -- "git apply --reject" implies verbose, but the similar
>> "git apply --check" does not, which seems inconsistent.
>
> Hmmm, I am of two minds. From purely idealistic point of view, I
> can see why defaulting both
Hi Paul,
Paul Gortmaker wrote:
> OK, so given your feedback, how do you feel about a patch to the
> documentation that indicates to use "-v" in combination with the
> "--check" to get equivalent "patch --dry-run" behaviour?
Sounds like a good idea to me.
I assume you mean a note in the OPTIONS
Junio C Hamano writes:
> I wonder if there are more like this broken caller or xread and/or
> xwrite.
Here is a result of a quick audit (of 1.8.0.x codebase).
As xwrite() will not be splitting a single-byte request, the patch
to cat-file is more or less a theoretical fix, but if writing the
dat
Am 20.08.2013 17:08, schrieb Stefan Beller:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
Are the long forms of options your invention?
I tried to keep strong similarity with the shell script for
ease of review. In the shellscript the options where
put in variables having these names, so for e
Paul Gortmaker writes:
> OK, so given your feedback, how do you feel about a patch to the
> documentation that indicates to use "-v" in combination with the
> "--check" to get equivalent "patch --dry-run" behaviour? If that
> had existed, I'd have not gone rummaging around in the source, so
> t
On 13-08-20 02:51 PM, Jonathan Nieder wrote:
> Hi Paul,
>
> Paul Gortmaker wrote:
>
>> OK, so given your feedback, how do you feel about a patch to the
>> documentation that indicates to use "-v" in combination with the
>> "--check" to get equivalent "patch --dry-run" behaviour?
>
> Sounds like
On Tue, 20 Aug 2013 12:07:18 -0700
Junio C Hamano wrote:
> Paul Gortmaker writes:
>
> > OK, so given your feedback, how do you feel about a patch to the
> > documentation that indicates to use "-v" in combination with the
> > "--check" to get equivalent "patch --dry-run" behaviour? If that
>
Ted Zlatanov writes:
> A while has passed since contrib/credential/netrc was added. Is it OK to
> promote it to be part of the main installation?
I gave it a quick glance, and it seems to be cleanly written, except
that "EOHIPPUS" (End-of-Hippus? Eohippus the extinct horse?) looked
a bit too st
Thomas Gummerer writes:
> Use the fixed width integer types uint16_t and uint32_t for ondisk
> structures, because unsigned short and unsigned int do not hae a
> guaranteed size.
This sounds like an independent fix to me. I'd queue this early
independent from the rest of the series.
Thanks.
>
Thomas Gummerer writes:
> All fields except index_state->version are reset in discard_index.
> Reset the version too.
What is the practical consequence of not clearing this field? I
somehow have a feeling that this was done deliberately, so that we
can stick to the version of the index file for
Am 20.08.2013 20:52, schrieb Junio C Hamano:
Junio C Hamano writes:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Here is a result of a quick audit (of 1.8.0.x codebase).
As xwrite() will not be splitting a single-byte request, the patch
to cat-file is more or l
Steffen Prohaska writes:
> diff --git a/wrapper.c b/wrapper.c
> index 6a015de..97e3cf7 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -131,6 +131,14 @@ void *xcalloc(size_t nmemb, size_t size)
> }
>
> /*
> + * Limit size of IO chunks, because huge chunks only cause pain. OS X 64-bit
> + * b
Steven Rostedt writes:
>> I do not think it is necessarily a good idea to assume that people
>> who are learning "git apply" know how GNU patch works.
>
> Linus told me that "git apply" was basically a replacement for patch.
> Why would you think it would not be a good idea to assume that people
Tony Finch writes:
> The rss_logo CSS style has a fixed width which is too narrow for
> the string "OPML". Replace the fixed width with horizontal padding
> so the text fits with nice margins.
Makes sense to me (although I do not do css).
>
> Signed-off-by: Tony Finch
> ---
> gitweb/static/gi
Tony Finch writes:
> Signed-off-by: Tony Finch
> ---
> gitweb/static/gitweb.css | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index a869be1..3b4d833 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/g
On Tue, 20 Aug 2013 12:45:03 -0700
Junio C Hamano wrote:
> Steven Rostedt writes:
>
> >> I do not think it is necessarily a good idea to assume that people
> >> who are learning "git apply" know how GNU patch works.
> >
> > Linus told me that "git apply" was basically a replacement for patch.
>
vefduns ydeydir vidrtqf
pwsgn btupecbah vajbmrnms
jsomyc I T Q M J E O N
vvzbxufau V E H T L V H Q L E M B N Q K Y W
bouhepzvsy ssjpna psuwxkokvszytee
kjboc uzbtjb bvgfj
eggdmjlvl D P Y E W N H N L L
dqyqqiuyrjtdbntp S K D E O U C S Z<>
Am 20.08.2013 20:44, schrieb Andreas Schwab:
Erik Faye-Lund writes:
diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
index d015e43..0641f4e 100644
--- a/compat/win32/syslog.c
+++ b/compat/win32/syslog.c
@@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)
va_end(ap)
Duy Nguyen writes:
> General comment: a short comment before each function describing what
> the function does would be helpful. This only applies for complex
> functions (read_* ones). Of course verify_hdr does not require extra
> explanantion.
Yes, makes sense, I'll do that in the re-roll.
>
Duy Nguyen writes:
> On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer wrote:
>> +static int read_entry(struct cache_entry **ce, char *pathname, size_t
>> pathlen,
>> + void *mmap, unsigned long mmap_size,
>> + unsigned int first_entry_offset,
>> +
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
>
>> +packdir = mkpathdup("%s/pack", get_object_directory());
>> +packtmp = mkpathdup("%s/.tmp-%d-pack", packdir, getpid());
>
> Should this not be
>
> packdir = xstrdup(git_path("pack"));
> packtmp = xstrdup(git_path("pack/.tmp-%d-pac
Stefan Beller wrote:
> On 08/20/2013 03:31 PM, Johannes Sixt wrote:
>>> +packdir = mkpathdup("%s/pack", get_object_directory());
>>> +packtmp = mkpathdup("%s/.tmp-%d-pack", packdir, getpid());
>>
>> Should this not be
>>
>> packdir = xstrdup(git_path("pack"));
>> packtmp = xstrdu
On 08/20/2013 11:34 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>> On 08/20/2013 03:31 PM, Johannes Sixt wrote:
>
+packdir = mkpathdup("%s/pack", get_object_directory());
+packtmp = mkpathdup("%s/.tmp-%d-pack", packdir, getpid());
>>>
>>> Should this not be
>>>
>>> pack
Paul Gortmaker writes:
>> Looks good to me. Paul, what do you think?
>
> Yep, I'll write something up tomorrow which loosely matches the above.
Thanks.
--
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
Steven Rostedt writes:
>> > Linus told me that "git apply" was basically a replacement for patch.
>> > Why would you think it would not be a good idea to assume that people
>> > would not be familiar with how GNU patch works?
>>
>> The audience of Git these days are far more widely spread than t
Stefan Beller wrote:
>>> On 08/20/2013 03:31 PM, Johannes Sixt wrote:
Stefan Beller wrote:
> +packdir = mkpathdup("%s/pack", get_object_directory());
> +packtmp = mkpathdup("%s/.tmp-%d-pack", packdir, getpid());
Should this not be
packdir = xstrdup(git_
On Tue, Aug 20, 2013 at 8:44 PM, Andreas Schwab wrote:
> Erik Faye-Lund writes:
>
>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
>> index d015e43..0641f4e 100644
>> --- a/compat/win32/syslog.c
>> +++ b/compat/win32/syslog.c
>> @@ -43,11 +43,14 @@ void syslog(int priority, const cha
On Tue, Aug 20, 2013 at 10:34 PM, René Scharfe wrote:
> Am 20.08.2013 20:44, schrieb Andreas Schwab:
>
>> Erik Faye-Lund writes:
>>
>>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
>>> index d015e43..0641f4e 100644
>>> --- a/compat/win32/syslog.c
>>> +++ b/compat/win32/syslog.c
>>>
So here is an update of git-repack
Thanks for all the reviews and annotations!
I think I got all the suggestions except the
use of git_path/mkpathdup.
I replaced mkpathdup by mkpath where possible,
but it's still not perfect.
I'll wait for the dokumentation patch of Jonathan,
before changing all
On Tue, 20 Aug 2013 14:43:56 -0700
Junio C Hamano wrote:
> But only folks in the kernel circle will be told by Linus the
> similarity between apply and patch, no?
Well, there was a time when Linus was making his rounds showcasing git
more than Linux, to people that were not kernel developers.
This is the beginning of the rewrite of the repacking.
All tests are constantly positive now.
Signed-off-by: Stefan Beller
---
Makefile| 2 +-
builtin.h | 1 +
builtin/repack.c| 361
I was playing with a hook for file size limits that wanted to store the
limit in git-config. It turns out we don't do a very good job of big
integers:
$ git config foo.size 2g
$ git config --int foo.size
-2147483648
Oops. After this series, we properly notice the error:
$ git config --in
When we look at a config value as an integer using the
git_config_int function, we carefully range-check the value
we get and complain if it is out of our range. But the range
we compare to is that of a "long", which we then cast to an
"int" in the function's return value. This means that on
system
On 08/21/2013 12:39 AM, Jeff King wrote:
> I was playing with a hook for file size limits that wanted to store the
> limit in git-config. It turns out we don't do a very good job of big
> integers:
>
> $ git config foo.size 2g
> $ git config --int foo.size
> -2147483648
>
> Oops. After this
Internally we use "unsigned long" to represent large config
values like packed window memory sizes, packfile size
limits, etc. On 32-bit systems, this limits these config
options to 4G (and we detect and complain about overflow).
On 64-bit systems, they get the full 64-bit range.
However, there i
Stefan Beller wrote:
> I think I got all the suggestions except the
> use of git_path/mkpathdup.
> I replaced mkpathdup by mkpath where possible,
> but it's still not perfect.
No, mkpathdup is generally better unless you know what you're doing.
> I'll wait for the dokumentation patch of Jonathan
On Wed, Aug 21, 2013 at 12:44:22AM +0200, Stefan Beller wrote:
> On 08/21/2013 12:39 AM, Jeff King wrote:
> > I was playing with a hook for file size limits that wanted to store the
> > limit in git-config. It turns out we don't do a very good job of big
> > integers:
> >
> > $ git config foo.s
Jeff King wrote:
> I kind of hate the name "--ulong". I wanted to call it "--size" or
> something and abstract away the actual platform representation, and just
> make it "big enough for file sizes".
Yes, something like --size would be more pleasant.
It could still use unsigned long internally.
Erik Faye-Lund writes:
> I don't see how it's undefined. It's using the memory that 'pos'
> *points to* that is undefined, no? The difference between 'pos' and
> 'str' should still be the same, it's not like realloc somehow
> magically updates 'pos'...
It does. Think of segmented architectures,
Jeff King writes:
> I was playing with a hook for file size limits that wanted to store the
> limit in git-config. It turns out we don't do a very good job of big
> integers:
>
> $ git config foo.size 2g
> $ git config --int foo.size
> -2147483648
>
> Oops. After this series, we properly no
Jeff King wrote:
> I added a test. It would not fail on existing 32-bit systems, but would
> on existing LP64 systems. It will pass with the new code on both.
> However, it will fail on ILP64 systems (because their int is large, and
> can represent 3GB). I'm not sure if any such systems are in wid
Junio C Hamano writes:
> Jeff King writes:
>
>> I was playing with a hook for file size limits that wanted to store the
>> limit in git-config. It turns out we don't do a very good job of big
>> integers:
>>
>> $ git config foo.size 2g
>> $ git config --int foo.size
>> -2147483648
>>
>> Oo
Andreas Schwab writes:
> Erik Faye-Lund writes:
>
>> I don't see how it's undefined. It's using the memory that 'pos'
>> *points to* that is undefined, no? The difference between 'pos' and
>> 'str' should still be the same, it's not like realloc somehow
>> magically updates 'pos'...
>
> It does.
On Wed, Aug 21, 2013 at 1:01 AM, Andreas Schwab wrote:
> Erik Faye-Lund writes:
>
>> I don't see how it's undefined. It's using the memory that 'pos'
>> *points to* that is undefined, no? The difference between 'pos' and
>> 'str' should still be the same, it's not like realloc somehow
>> magicall
On 2013-08-14 12:49, Tim Chase wrote:
> c:\temp> git svn clone "file:///x:/path/to/repo/trunk/utils/project1"
>
> but get various failures. My best-effort (above) gets me as far as
> actually starting some sort of clone but it dies with
>
> """
> Permission denied: Can't open '/tmp/report.tmp'
On Wed, Aug 21, 2013 at 3:59 AM, Thomas Gummerer wrote:
>>> +static int read_entries(struct index_state *istate, struct directory_entry
>>> *de,
>>> + unsigned int first_entry_offset, void *mmap,
>>> + unsigned long mmap_size, unsigned int *nr,
>>> +
On 13-08-20 03:54 PM, Steven Rostedt wrote:
> On Tue, 20 Aug 2013 12:45:03 -0700
> Junio C Hamano wrote:
>
>> Steven Rostedt writes:
>>
I do not think it is necessarily a good idea to assume that people
who are learning "git apply" know how GNU patch works.
>>>
>>> Linus told me that "
On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer wrote:
> Respect a GIT_INDEX_VERSION environment variable, when a new index is
> initialized. Setting the environment variable will not cause existing
> index files to be converted to another format for additional safety.
>
> Signed-off-by: Thomas
On Tue, Aug 20, 2013 at 11:25:48AM -0400, Josef 'Jeff' Sipek wrote:
> On Tue, Aug 20, 2013 at 03:44:16PM +0800, Zheng Liu wrote:
> > Hi Josef,
> >
> > On Fri, Aug 09, 2013 at 11:20:46AM -0400, Josef 'Jeff' Sipek wrote:
> > > On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote:
> > > > ??
On Tue, Aug 20, 2013 at 04:06:19PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I was playing with a hook for file size limits that wanted to store the
> > limit in git-config. It turns out we don't do a very good job of big
> > integers:
> >
> > $ git config foo.size 2g
> > $ git
On Tue, Aug 20, 2013 at 04:41:30PM -0700, Junio C Hamano wrote:
> If this applied on the writing side, I would understand it very
> much, i.e.
>
> $ git config --int32 foo.size 2g
> fatal: "2g" is too large to be read as "int32".
It does, by the way. When you request a type on the
On Tue, Aug 20, 2013 at 04:07:49PM -0700, Jonathan Nieder wrote:
> > I added a test. It would not fail on existing 32-bit systems, but would
> > on existing LP64 systems. It will pass with the new code on both.
> > However, it will fail on ILP64 systems (because their int is large, and
> > can rep
On Tue, Aug 20, 2013 at 03:57:45PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I kind of hate the name "--ulong". I wanted to call it "--size" or
> > something and abstract away the actual platform representation, and just
> > make it "big enough for file sizes".
>
> Yes, something li
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> Use the fixed width integer types uint16_t and uint32_t for ondisk
>> structures, because unsigned short and unsigned int do not hae a
>> guaranteed size.
>
> This sounds like an independent fix to me. I'd queue this early
> independent from
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> All fields except index_state->version are reset in discard_index.
>> Reset the version too.
>
> What is the practical consequence of not clearing this field? I
> somehow have a feeling that this was done deliberately, so that we
> can stick
When git is used to track only a subset of a directory, or
there is no sure way to divide files to ignore from files to track,
git user have to live with large number of untracked files. These files
present in file list, and should always be scrolled through
to handle real changes. Situation can be
For long descriptions it would be nice to be able to resize
the comment text field.
Signed-off-by: Max Kirillov
---
git-gui/git-gui.sh | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 89f636f..e2e710e 100755
--- a
Duy Nguyen writes:
> On Mon, Aug 19, 2013 at 2:42 AM, Thomas Gummerer wrote:
>> Respect a GIT_INDEX_VERSION environment variable, when a new index is
>> initialized. Setting the environment variable will not cause existing
>> index files to be converted to another format for additional safety.
1 - 100 of 104 matches
Mail list logo
