prefixcmp() and suffixcmp() cannot be really used as comparison
functions as they are not antisymmetric:
prefixcmp("foo", "foobar") < 0
prefixcmp("foobar", "foo") == 0
So they are not suitable as functions for passing to qsort.
And in fact they are used nowhere as comparison funct
As starts_with() and ends_with() have been used to
replace prefixcmp() and suffixcmp() respectively,
we can now remove them.
Signed-off-by: Christian Couder
---
git-compat-util.h | 2 --
strbuf.c | 18 --
2 files changed, 20 deletions(-)
diff --git a/git-compat-util.h
This is a new patch series along the lines Junio suggested in this
thread:
http://thread.gmane.org/gmane.comp.version-control.git/238054/
I send it now because I saw a 1.8.5 tag.
The patches in this series can be related to what Junio suggested
this way:
* A set of clean-up patches to normaliz
Commit 8cc5b290 (git merge -X, 25 Nov 2009) introduced
suffixcmp() with nearly the same implementation as postfixcmp()
that already existed since commit 211c8968 (Make git-remote a
builtin, 29 Feb 2008).
The only difference between the two implementations is that,
when the string is smaller than t
To be able to automatically convert prefixcmp() to starts_with()
we need first to make sure that prefixcmp() is always used in
the same way.
So let's remove " != 0" after prefixcmp().
Signed-off-by: Christian Couder
---
environment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Greetings,
I found this probable bug:
https://gist.github.com/anonymous/01979fd9e6e285df41a2
Cheers, Ingy döt Net
--
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://vger.kernel.org/majordomo-info.h
Bug 6530 [1] in glibc causes "git show v0.99.6~1" to fail with error
"your vsnprintf is broken". The workaround avoids that, but it
corrupts system error messages in non-C locales.
The bug has been fixed since 2.17. We could know running glibc version
with gnu_get_libc_version(). But version is no
On Sun, Dec 1, 2013 at 6:01 AM, Torsten Bögershausen wrote:
> On 2013-11-30 13.01, Nguyễn Thái Ngọc Duy wrote:
>> Bug 6530 [1] causes "git show v0.99.6~1" to fail with error "your
> causes or caused (as we have a work around?)
>> vsnprintf is broken". The workaround avoids that, but it corrupts
>>
On Fri, Nov 29, 2013 at 2:22 PM, Øystein Walle wrote:
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index debda7a..0568ec5 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog'
> '
> grep quux bazzy
> gnu_glibc_version()=2.11.3 /* Ubuntu 10.4, no updates */
Sorry, Copy-paste error:
2.11.1
--
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://vger.kernel.org/majordomo-info.html
On 2013-11-30 13.01, Nguyễn Thái Ngọc Duy wrote:
> Bug 6530 [1] causes "git show v0.99.6~1" to fail with error "your
causes or caused (as we have a work around?)
> vsnprintf is broken". The workaround avoids that, but it corrupts
> system error messages in non-C locales.
[snip]
> The bug in glibc h
Aaron Brooks brooks1.net> writes:
>
> Unlike other commands, git stash doesn't work outside of the worktree,
> even when --work-tree is specified:
>
> (...)
>
> It looks like the "require_work_tree" function should check the
> environment variables in addition to the status of the PWD (via
> g
Antoine Pelisse writes:
> On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
>> +static int verify_hdr(void *mmap, unsigned long size)
>> +{
>> + uint32_t *filecrc;
>> + unsigned int header_size;
>> + struct cache_header *hdr;
>> + struct cache_header_v5 *hdr_v5;
>>
Antoine Pelisse writes:
> On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
>> Make git read the index file version 5 without complaining.
>>
>> This version of the reader reads neither the cache-tree
>> nor the resolve undo data, however, it won't choke on an
>> index that includes such d
Antoine Pelisse writes:
> On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
>> @@ -447,6 +463,7 @@ int cmd_ls_files(int argc, const char **argv, const char
>> *cmd_prefix)
>> struct dir_struct dir;
>> struct exclude_list *el;
>> struct string_list exclude_list = ST
Unlike other commands, git stash doesn't work outside of the worktree,
even when --work-tree is specified:
abrooks@host:~/tmp$ mkdir test-repo
abrooks@host:~/tmp$ cd !$
cd test-repo
abrooks@host:~/tmp/test-repo$ git init
Initialized empty Git repository in /home/abrooks/tmp/test-repo/.git/
abrooks
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> @@ -447,6 +463,7 @@ int cmd_ls_files(int argc, const char **argv, const char
> *cmd_prefix)
> struct dir_struct dir;
> struct exclude_list *el;
> struct string_list exclude_list = STRING_LIST_INIT_NODUP;
> + s
Thomas Rast thomasrast.ch> writes:
> I wonder what we would lose by dropping the --symbolic in the line I
> quoted above (which is the second parsing pass), so that it resolves
> to a SHA1. We would gain some robustness, as I'm not sure "$REV:"
> works correctly in the face of weird revision exp
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> +static int verify_hdr(void *mmap, unsigned long size)
> +{
> + uint32_t *filecrc;
> + unsigned int header_size;
> + struct cache_header *hdr;
> + struct cache_header_v5 *hdr_v5;
> +
> + if (size < sizeof(struc
This parameter is not used yet, but it will be used to tell
sha1_object_info_extended() if it should perform object
replacement or not.
Signed-off-by: Christian Couder
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c| 2 +-
4 files chan
sha1_object_info_extended() should perform object replacement
if it is needed.
The simplest way to do that is to make it call
lookup_replace_object_extended().
And now its "unsigned flags" parameter is used as it is passed
to lookup_replace_object_extended().
Signed-off-by: Christian Couder
---
When --batch is passed to git cat-file, the sha1_object_info_extended()
function is used to get information about the objects passed to
git cat-file.
Unfortunately sha1_object_info_extended() doesn't take care of
object replacement properly, so it will often fail with a
message like this:
$ echo
Since ecef (inline lookup_replace_object() calls,
May 15 2011) the read_replace_refs global variable is
checked twice, once in lookup_replace_object() and
once again in do_lookup_replace_object().
As do_lookup_replace_object() is called only from
lookup_replace_object(), we can remove the chec
Here is a patch series to improve the way sha1_object_info_extended()
behaves when it is passed a replaced object.
This patch series was inspired by a sub thread in this discussion:
http://thread.gmane.org/gmane.comp.version-control.git/238118
Patches 1/5 and 2/5 are cleanups.
Patch 4/5 adds a t
Currently, there is only one caller to lookup_replace_object()
that can benefit from passing it some flags, but we expect
that there could be more.
Signed-off-by: Christian Couder
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cach
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> Make git read the index file version 5 without complaining.
>
> This version of the reader reads neither the cache-tree
> nor the resolve undo data, however, it won't choke on an
> index that includes such data.
>
> Helped-by: Junio C Haman
Bug 6530 [1] causes "git show v0.99.6~1" to fail with error "your
vsnprintf is broken". The workaround avoids that, but it corrupts
system error messages in non-C locales.
The bug has been fixed since 2.17. If git is built with glibc, it can
know running libc version with gnu_get_libc_version() an
Duy Nguyen writes:
> On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
>> This makes update-index use both partial reading and partial writing.
>> Partial reading is only used no option other than the paths is passed to
>> the command.
>>
>> This passes the test suite,
>
> Just checking, t
Duy Nguyen writes:
> On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -132,11 +141,17 @@ struct cache_entry {
>> char name[FLEX_ARRAY]; /* more */
>> };
>>
>> +#define CE_NAMEMASK (0x0fff)
>
> CE_NAMEMASK is redefined in read-cache-v2.c in
Duy Nguyen writes:
> On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
>> @@ -447,6 +463,7 @@ int cmd_ls_files(int argc, const char **argv, const char
>> *cmd_prefix)
>> struct dir_struct dir;
>> struct exclude_list *el;
>> struct string_list exclude_list = STRING_
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
> This makes update-index use both partial reading and partial writing.
> Partial reading is only used no option other than the paths is passed to
> the command.
>
> This passes the test suite,
Just checking, the test suite was run with TEST
Nguyễn Thái Ngọc Duy writes:
> diff --git a/gettext.c b/gettext.c
> index 71e9545..91e679d 100644
> --- a/gettext.c
> +++ b/gettext.c
> @@ -18,6 +18,13 @@
> #endif
> #endif
>
> +#ifdef USE_GLIBC
> +#ifndef _GNU_SOURCE
> +#define _GNU_SOURCE
> +#endif
Defining a feature test macro after a
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
> @@ -447,6 +463,7 @@ int cmd_ls_files(int argc, const char **argv, const char
> *cmd_prefix)
> struct dir_struct dir;
> struct exclude_list *el;
> struct string_list exclude_list = STRING_LIST_INIT_NODUP;
> + s
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer wrote:
> --- a/cache.h
> +++ b/cache.h
> @@ -132,11 +141,17 @@ struct cache_entry {
> char name[FLEX_ARRAY]; /* more */
> };
>
> +#define CE_NAMEMASK (0x0fff)
CE_NAMEMASK is redefined in read-cache-v2.c in "read-cache: move index
v2 speci
I have seen this behaviour, though never determined the root cause
.Probably the simplest thing you can do without access to the server
is to put your git svn fetch into a bash while loop, like so:
while ! git svn fetch; do :; done;
jon
On Sat, Nov 30, 2013 at 10:14 AM, Matěj Cepl wrote:
> Hi,
>From the perspective of topic there had been no change to the
definition of bar(), hence there was no change to contribute to the
eventual merge with master.
One way to avoid this kind of problem is to avoid making (or
cherry-picking) the same change on different branches, but instead use
a merge
36 matches
Mail list logo
