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
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
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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 =
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Nov 27, 2013 at 7:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
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() and
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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:
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
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
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 chrisc...@tuxfamily.org
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2
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
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 chrisc...@tuxfamily.org
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Thomas Rast tr at 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
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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 =
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/
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
+static int verify_hdr(void *mmap, unsigned long size)
+{
+ uint32_t *filecrc;
+ unsigned int header_size;
+ struct cache_header *hdr;
+ struct
Aaron Brooks aaron at 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
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 has been
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 Fri, Nov 29, 2013 at 2:22 PM, Øystein Walle oys...@gmail.com 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
On Sun, Dec 1, 2013 at 6:01 AM, Torsten Bögershausen tbo...@web.de 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
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 not a
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
Commit 8cc5b290 (git merge -Xoption, 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
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 functions.
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 chrisc...@tuxfamily.org
---
git-compat-util.h | 2 --
strbuf.c | 18 --
2 files changed, 20 deletions(-)
diff
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
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 chrisc...@tuxfamily.org
---
environment.c | 2 +-
1 file changed, 1 insertion(+),
36 matches
Mail list logo
