Re: [PATCH] fix some clang warnings
On Wed, Jan 16, 2013 at 07:01:37PM +, John Keeping wrote: On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote: On Wed, Jan 16, 2013 at 06:22:40PM +, John Keeping wrote: Thanks for checking. I'd rather squelch the warning completely (as in my re-post of Max's patch from a few minutes ago), and we can loosen it (possibly with a version check) later when a fix is widely disseminated. I checked again with a trunk build of clang and the warning's still there, so I've created a clang bug [1] to see if they will change the behaviour. [1] http://llvm.org/bugs/show_bug.cgi?id=14968 Well, that was quick! This warning is now gone when using a fresh trunk build of clang. From [2], it looks like this will become version 3.3 (in about 5 months). So should we change the condition to: #if defined(__GNUC__) (!defined(__clang__) || __clang_major__ 3 || \ (__clang__major == 3 __clang_minor__ = 3) [2] http://llvm.org/docs/HowToReleaseLLVM.html John -- 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
[PATCH] combine-diff: suppress a clang warning
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~^~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
[ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Thu, Jan 17, 2013 at 11:00:08AM +, John Keeping wrote:
On Thu, Jan 17, 2013 at 11:32:39AM +0100, Antoine Pelisse wrote:
There is one remaining warning on pu which hasn't been discussed in this
thread as far as I can see. I'll send a patch shortly.
... and here it is.
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = COLONS[offset];
/* Show the modes */
for (i = 0; i num_parent; i++) {
--
1.8.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
Re: GIT get corrupted on lustre
Hi! I still have the corruption problems We just compiled a git without threads to try... (by the way, --without-pthreads doesn't work, you have to do a --disable-pthreads instead). And to remove the warnings about threads at git gc execution, I did a: git config --local pack.threads 1 and cloned a repository and started to do: git gc once every hour. Then this night (at 05:35:02 exactly), the same error as usual occurred: error: index file .git/objects/pack/pack-bf0748cee64a1964be0a1061c82aca51c993b825.idx is too small error: refs/heads/master does not point to a valid object! So now I am convinced that it is not a thread problem I am kind of discouraged, we like to use git, but in this case we have this error which seems unsolvable! Anyone has a new idea? Thanks, Eric On 01/09/2013 04:20 PM, Eric Chamberland wrote: Hi Brian, On 01/08/2013 11:11 AM, Eric Chamberland wrote: On 12/24/2012 10:11 AM, Brian J. Murrell wrote: Have you tried adding a -q to the git command line to quiet down git's feedback messages? I moved to git 1.8.1 and added the -q to the command git gc but it occured to return an error, so the -q option is not avoiding the problem here... :-/ command in crontab: cd /rap/jsf-051-aa/ericc/tests_git_clones/GIREF for i in seq 10; do /software/apps/git/1.8.1/bin/git gc -q || true;done results: error: index file .git/objects/pack/pack-1f09879c88cd71a15dcc891713cf038d249830ad.idx is too small error: refs/remotes/origin/BIB_Branche_1_4_x does not point to a valid object! and this clone was a clean clone in which only git qc -q has been run on I still have a doubt on threads Eric -- 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 -- 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
Re: [PATCH v6 0/8] push: update remote tags only with force
On Thu, Jan 17, 2013 at 12:59 AM, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote: It is fine when pushing into refs/tags/ hierarchy. It is *NOT* OK if the type check does not satisfy this function. In that case, we do not actually see the existence of the destination as a problem, but it is reported as such. We are blocking because we do not like the type of the new object or the type of the old object. If the destination points at a commit, the push can succeed if the user changes what object to push, so saying you cannot push because the destination already exists is just wrong in such a case. So the solution is to revert back to recommending a merge? Of course not, because at that point you may not even have what you were attempting to overwrite. Nobody says it is even something you could merge. I was referring to your concern about rejecting based on type. A push causing a reference to move (for example) from a commit to a blob is rejected as already exists with this patch. You emphatically state this is not OK and your solution is to revert back to behavior that advises a merge. Clearly the bug regarding an 'old' unknown to the client should be fixed. This is a obvious test case I should have covered and it's unfortunate it made it into master. But I don't understand why is_forwardable() was misguided (maybe poorly named) nor why ref_newer() is a better place to solve the issues it was addressing. Chris -- 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
merge vs. rebase question
As a git noob I am having trouble understanding when to use which commands. I have a repository (bare) on my Linux server. I also created a build directory as a local repository. In my build script I do a 'git pull' to make sure the build directory is up to date. No changes are made to my source so this repository never does an 'add' or 'commit'. When I run my script with 'pull', the output indicates that changes were found and seems to have pulled them into the local directory. However, when I look at the resulting source, none of the expected changes show up. I then tried a 'fetch' and 'rebase'. That worked but I don't understand why. I thought 'pull' did a 'fetch' and a 'merge' so I don't understand why a 'fetch' and 'rebase' worked but 'fetch' and 'merge' did not. Unless my understanding of what 'pull' does is wrong. In my case, what should I be using in my script to assure that the build directory is current? Thanks. signature.asc Description: OpenPGP digital signature
Re: GIT get corrupted on lustre
On 01/17/2013 09:23 AM, Philippe Vaucher wrote: Anyone has a new idea? Did you try Jeff King's code to confirm his idea? Philippe Yes I did, but it was running without any problem I find that my test case is simple (fresh git clone then git gc in a crontab), I bet anyone who has access to a Lustre filesystem can reproduce the problem... The problem is to have such a filesystem to do the tests But I am available to do it... Thanks, Eric -- 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
RE: GIT get corrupted on lustre
-Original Message- From: Eric Chamberland Sent: Thursday, January 17, 2013 11:31 AM On 01/17/2013 09:23 AM, Philippe Vaucher wrote: Anyone has a new idea? Did you try Jeff King's code to confirm his idea? Philippe Yes I did, but it was running without any problem I find that my test case is simple (fresh git clone then git gc in a crontab), I bet anyone who has access to a Lustre filesystem can reproduce the problem... The problem is to have such a filesystem to do the tests Stabbing in the dark, but can you log the details with ProcessMon? http://technet.microsoft.com/en-us/sysinternals/bb896645 But I am available to do it... -Jason smime.p7s Description: S/MIME cryptographic signature
Re: GIT get corrupted on lustre
I don't know of any lustre filesystem that is used on Windows. Barely anybody uses Windows in the HPC industry. This is a Linux cluster. Maxime Boissonneault Le 2013-01-17 11:40, Pyeron, Jason J CTR (US) a écrit : -Original Message- From: Eric Chamberland Sent: Thursday, January 17, 2013 11:31 AM On 01/17/2013 09:23 AM, Philippe Vaucher wrote: Anyone has a new idea? Did you try Jeff King's code to confirm his idea? Philippe Yes I did, but it was running without any problem I find that my test case is simple (fresh git clone then git gc in a crontab), I bet anyone who has access to a Lustre filesystem can reproduce the problem... The problem is to have such a filesystem to do the tests Stabbing in the dark, but can you log the details with ProcessMon? http://technet.microsoft.com/en-us/sysinternals/bb896645 But I am available to do it... -Jason -- - Maxime Boissonneault Analyste de calcul - Calcul Québec, Université Laval Ph. D. en physique -- 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
Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote: There's also a warning that triggers with clang 3.2 but not clang trunk, which I think is a legitimate warning - perhaps someone who understands integer type promotion better than me can explain why the code is OK (patch-score is declared as 'int'): builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615 with expression of type 'int' is always false [-Wtautological-constant-out-of-range-compare] if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX) ^ ~ The warning seems to be very very wrong, and implies that clang has some nasty bug in it. Since patch-score is 'int', and UNLONG_MAX is 'unsigned long', the conversion rules for the comparison is that the int result from the assignment is cast to unsigned long. And if you cast (int)-1 to unsigned long, you *do* get ULONG_MAX. That's true regardless of whether long has the same number of bits as int or is bigger. The implicit cast will be done as a sign-extension (unsigned long is not signed, but the source type of 'int' *is* signed, and that is what determines the sign extension on casting). So the is always false is pure and utter crap. clang is wrong, and it is wrong in a way that implies that it actually generates incorrect code. It may well be worth making a clang bug report about this. That said, clang is certainly understandably confused. The code depends on subtle conversion rules and bit patterns, and is clearly very confusingly written. So it would probably be good to rewrite it as unsigned long val = strtoul(line, NULL, 10); if (val == ULONG_MAX) .. patch-score = val; instead. At which point you might as well make the comparison be = INT_MAX instead, since anything bigger than that is going to be bogus. So the git code is probably worth cleaning up, but for git it would be a cleanup. For clang, this implies a major bug and bad code generation. Linus Linus -- 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
Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
BTW, I think it has been addressed [1] by clang already and that would explain why you don't have the warning when using clang trunk version. [1]: http://llvm-reviews.chandlerc.com/D113 Antoine, On Thu, Jan 17, 2013 at 5:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote: There's also a warning that triggers with clang 3.2 but not clang trunk, which I think is a legitimate warning - perhaps someone who understands integer type promotion better than me can explain why the code is OK (patch-score is declared as 'int'): builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615 with expression of type 'int' is always false [-Wtautological-constant-out-of-range-compare] if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX) ^ ~ The warning seems to be very very wrong, and implies that clang has some nasty bug in it. Since patch-score is 'int', and UNLONG_MAX is 'unsigned long', the conversion rules for the comparison is that the int result from the assignment is cast to unsigned long. And if you cast (int)-1 to unsigned long, you *do* get ULONG_MAX. That's true regardless of whether long has the same number of bits as int or is bigger. The implicit cast will be done as a sign-extension (unsigned long is not signed, but the source type of 'int' *is* signed, and that is what determines the sign extension on casting). So the is always false is pure and utter crap. clang is wrong, and it is wrong in a way that implies that it actually generates incorrect code. It may well be worth making a clang bug report about this. That said, clang is certainly understandably confused. The code depends on subtle conversion rules and bit patterns, and is clearly very confusingly written. So it would probably be good to rewrite it as unsigned long val = strtoul(line, NULL, 10); if (val == ULONG_MAX) .. patch-score = val; instead. At which point you might as well make the comparison be = INT_MAX instead, since anything bigger than that is going to be bogus. So the git code is probably worth cleaning up, but for git it would be a cleanup. For clang, this implies a major bug and bad code generation. Linus Linus -- 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
Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
On Thu, Jan 17, 2013 at 08:44:20AM -0800, Linus Torvalds wrote: On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote: There's also a warning that triggers with clang 3.2 but not clang trunk, which I think is a legitimate warning - perhaps someone who understands integer type promotion better than me can explain why the code is OK (patch-score is declared as 'int'): builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615 with expression of type 'int' is always false [-Wtautological-constant-out-of-range-compare] if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX) ^ ~ The warning seems to be very very wrong, and implies that clang has some nasty bug in it. Since patch-score is 'int', and UNLONG_MAX is 'unsigned long', the conversion rules for the comparison is that the int result from the assignment is cast to unsigned long. And if you cast (int)-1 to unsigned long, you *do* get ULONG_MAX. That's true regardless of whether long has the same number of bits as int or is bigger. The implicit cast will be done as a sign-extension (unsigned long is not signed, but the source type of 'int' *is* signed, and that is what determines the sign extension on casting). So the is always false is pure and utter crap. clang is wrong, and it is wrong in a way that implies that it actually generates incorrect code. It may well be worth making a clang bug report about this. The warning doesn't occur with a build from their trunk so it looks like it's already fixed - it just won't make into into a release for about 5 months going by their timeline. Thanks for the clear explanation. -- 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
RE: GIT get corrupted on lustre
Sorry, I am in cygwin mode, and I had crossed wires in my head. s/ProcessMon/strace/ -Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Maxime Boissonneault Sent: Thursday, January 17, 2013 11:41 AM To: Pyeron, Jason J CTR (US) Cc: Eric Chamberland; Philippe Vaucher; git@vger.kernel.org; Sébastien Boisvert Subject: Re: GIT get corrupted on lustre I don't know of any lustre filesystem that is used on Windows. Barely anybody uses Windows in the HPC industry. This is a Linux cluster. Maxime Boissonneault Le 2013-01-17 11:40, Pyeron, Jason J CTR (US) a écrit : -Original Message- From: Eric Chamberland Sent: Thursday, January 17, 2013 11:31 AM On 01/17/2013 09:23 AM, Philippe Vaucher wrote: Anyone has a new idea? Did you try Jeff King's code to confirm his idea? Philippe Yes I did, but it was running without any problem I find that my test case is simple (fresh git clone then git gc in a crontab), I bet anyone who has access to a Lustre filesystem can reproduce the problem... The problem is to have such a filesystem to do the tests Stabbing in the dark, but can you log the details with ProcessMon? http://technet.microsoft.com/en-us/sysinternals/bb896645 But I am available to do it... -Jason -- - Maxime Boissonneault Analyste de calcul - Calcul Québec, Université Laval Ph. D. en physique -- 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 smime.p7s Description: S/MIME cryptographic signature
[PATCH v2 0/8] Initial Python 3 support
This series does enough so that everything except git-p4 runs under Python 3. As discussed with Pete, it may not make sense to change git-p4 to support Python 3 until Perforce's Python output mode is changed. So does it make sense to merge this now and say use Python 2 if you want git-p4? Changes since v1: * rebased on master after fc/remote-testgit-feature-done was merged, leading to an extra change in patch 8 (git-remote-testpy: call print as a function) * changed patch 2 (git_remote_helpers: fix input when running under Python 3) to treat ref names as byte strings John Keeping (8): git_remote_helpers: Allow building with Python 3 git_remote_helpers: fix input when running under Python 3 git_remote_helpers: Force rebuild if python version changes git_remote_helpers: Use 2to3 if building with Python 3 svn-fe: allow svnrdump_sim.py to run with Python 3 git-remote-testpy: hash bytes explicitly git-remote-testpy: don't do unbuffered text I/O git-remote-testpy: call print as a function contrib/svn-fe/svnrdump_sim.py | 4 ++-- git-remote-testpy.py | 42 +++--- git_remote_helpers/.gitignore | 1 + git_remote_helpers/Makefile| 10 +++-- git_remote_helpers/git/importer.py | 9 +--- git_remote_helpers/setup.py| 10 + 6 files changed, 48 insertions(+), 28 deletions(-) -- 1.8.1.1.260.g99b33f4.dirty -- 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
[PATCH v2 1/8] git_remote_helpers: allow building with Python 3
Change inline Python to call print as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
index 74b05dc..f65f064 100644
--- a/git_remote_helpers/Makefile
+++ b/git_remote_helpers/Makefile
@@ -23,7 +23,7 @@ endif
PYLIBDIR=$(shell $(PYTHON_PATH) -c \
import sys; \
-print 'lib/python%i.%i/site-packages' % sys.version_info[:2])
+print('lib/python%i.%i/site-packages' % sys.version_info[:2]))
all: $(pysetupfile)
$(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build
--
1.8.1.1.260.g99b33f4.dirty
--
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
[PATCH v2 3/8] git_remote_helpers: force rebuild if python version changes
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/git_remote_helpers/.gitignore b/git_remote_helpers/.gitignore
index 2247d5f..06c664f 100644
--- a/git_remote_helpers/.gitignore
+++ b/git_remote_helpers/.gitignore
@@ -1,2 +1,3 @@
+/GIT-PYTHON_VERSION
/build
/dist
diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
index f65f064..91f458f 100644
--- a/git_remote_helpers/Makefile
+++ b/git_remote_helpers/Makefile
@@ -25,8 +25,14 @@ PYLIBDIR=$(shell $(PYTHON_PATH) -c \
import sys; \
print('lib/python%i.%i/site-packages' % sys.version_info[:2]))
+py_version=$(shell $(PYTHON_PATH) -c \
+ 'import sys; print(%i.%i % sys.version_info[:2])')
+
all: $(pysetupfile)
- $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build
+ $(QUIET)test $$(cat GIT-PYTHON_VERSION 2/dev/null) = $(py_version)
|| \
+ flags=--force; \
+ $(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build $$flags
+ $(QUIET)echo $(py_version) GIT-PYTHON_VERSION
install: $(pysetupfile)
$(PYTHON_PATH) $(pysetupfile) install --prefix $(DESTDIR_SQ)$(prefix)
--
1.8.1.1.260.g99b33f4.dirty
--
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
[PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
Using the approach detailed on the Python wiki[1], run 2to3 on the code
as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://wiki.python.org/moin/PortingPythonToPy3k
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/setup.py | 10 ++
1 file changed, 10 insertions(+)
diff --git a/git_remote_helpers/setup.py b/git_remote_helpers/setup.py
index 4d434b6..6de41de 100644
--- a/git_remote_helpers/setup.py
+++ b/git_remote_helpers/setup.py
@@ -4,6 +4,15 @@
from distutils.core import setup
+# If building under Python3 we need to run 2to3 on the code, do this by
+# trying to import distutils' 2to3 builder, which is only available in
+# Python3.
+try:
+from distutils.command.build_py import build_py_2to3 as build_py
+except ImportError:
+# 2.x
+from distutils.command.build_py import build_py
+
setup(
name = 'git_remote_helpers',
version = '0.1.0',
@@ -14,4 +23,5 @@ setup(
url = 'http://www.git-scm.com/',
package_dir = {'git_remote_helpers': ''},
packages = ['git_remote_helpers', 'git_remote_helpers.git'],
+cmdclass = {'build_py': build_py},
)
--
1.8.1.1.260.g99b33f4.dirty
--
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
[PATCH v2 5/8] svn-fe: allow svnrdump_sim.py to run with Python 3
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 17cf6f9..4e78a1c 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -14,7 +14,7 @@ if sys.hexversion 0x0204:
def getrevlimit():
var = 'SVNRMAX'
-if os.environ.has_key(var):
+if var in os.environ:
return os.environ[var]
return None
@@ -44,7 +44,7 @@ def writedump(url, lower, upper):
if __name__ == __main__:
if not (len(sys.argv) in (3, 4, 5)):
-print usage: %s dump URL -rLOWER:UPPER
+print(usage: %s dump URL -rLOWER:UPPER)
sys.exit(1)
if not sys.argv[1] == 'dump': raise NotImplementedError('only dump
is suppported.')
url = sys.argv[2]
--
1.8.1.1.260.g99b33f4.dirty
--
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
[PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..f8dc196 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('utf-8'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
1.8.1.1.260.g99b33f4.dirty
--
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
[PATCH v2 8/8] git-remote-testpy: call print as a function
This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3. Since this is the only change
required to make this script just run under Python 3 without needing
2to3 it seems worthwhile.
The case of an empty print must be handled specially because in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-remote-testpy.py | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index bc5e3cf..ccdb2dc 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -87,9 +87,9 @@ def do_capabilities(repo, args):
Prints the supported capabilities.
-print import
-print export
-print refspec refs/heads/*:%s* % repo.prefix
+print(import)
+print(export)
+print(refspec refs/heads/*:%s* % repo.prefix)
dirname = repo.get_base_path(repo.gitdir)
@@ -98,11 +98,11 @@ def do_capabilities(repo, args):
path = os.path.join(dirname, 'git.marks')
-print *export-marks %s % path
+print(*export-marks %s % path)
if os.path.exists(path):
-print *import-marks %s % path
+print(*import-marks %s % path)
-print # end capabilities
+print('') # end capabilities
def do_list(repo, args):
@@ -115,16 +115,16 @@ def do_list(repo, args):
for ref in repo.revs:
debug(? refs/heads/%s, ref)
-print ? refs/heads/%s % ref
+print(? refs/heads/%s % ref)
if repo.head:
debug(@refs/heads/%s HEAD % repo.head)
-print @refs/heads/%s HEAD % repo.head
+print(@refs/heads/%s HEAD % repo.head)
else:
debug(@refs/heads/master HEAD)
-print @refs/heads/master HEAD
+print(@refs/heads/master HEAD)
-print # end list
+print('') # end list
def update_local_repo(repo):
@@ -164,7 +164,7 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
-print feature done
+print(feature done)
if os.environ.get(GIT_REMOTE_TESTGIT_FAILURE):
die('Told to fail')
@@ -172,7 +172,7 @@ def do_import(repo, args):
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
-print done
+print(done)
def do_export(repo, args):
@@ -192,8 +192,8 @@ def do_export(repo, args):
repo.non_local.push(repo.gitdir)
for ref in changed:
-print ok %s % ref
-print
+print(ok %s % ref)
+print('')
COMMANDS = {
--
1.8.1.1.260.g99b33f4.dirty
--
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
Re: [PATCH 2/3] Allow Git::get_tz_offset to properly handle DST boundary times
Ben Walton bdwal...@gmail.com writes:
The Git::get_tz_offset is meant to provide a workalike replacement for
the GNU strftime %z format specifier. The algorithm used failed to
properly handle DST boundary cases.
For example, the unix time 1162105199 in CST6CDT saw set_tz_offset
improperly return -0600 instead of -0500.
TZ=CST6CDT date -d @1162105199 +%c %z
Sun 29 Oct 2006 01:59:59 AM CDT -0500
$ zdump -v /usr/share/zoneinfo/CST6CDT | grep 2006
/usr/share/zoneinfo/CST6CDT Sun Apr 2 07:59:59 2006 UTC = Sun Apr 2
01:59:59 2006 CST isdst=0 gmtoff=-21600
/usr/share/zoneinfo/CST6CDT Sun Apr 2 08:00:00 2006 UTC = Sun Apr 2
03:00:00 2006 CDT isdst=1 gmtoff=-18000
/usr/share/zoneinfo/CST6CDT Sun Oct 29 06:59:59 2006 UTC = Sun Oct 29
01:59:59 2006 CDT isdst=1 gmtoff=-18000
/usr/share/zoneinfo/CST6CDT Sun Oct 29 07:00:00 2006 UTC = Sun Oct 29
01:00:00 2006 CST isdst=0 gmtoff=-21600
To determine how many hours/minutes away from GMT a particular time
was, we calculated the gmtime() of the requested time value and then
used Time::Local's timelocal() function to turn the GMT-based time
back into a scalar value representing seconds from the epoch. Because
GMT has no daylight savings time, timelocal() cannot handle the
ambiguous times that occur at DST boundaries since there are two
possible correct results.
To work around the ambiguity at these boundaries, we must take into
account the pre and post conversion values for is_dst as provided by
both the original time value and the value that has been run through
timelocal(). If the is_dst field of the two times disagree then we
must modify the value returned from timelocal() by an hour in the
correct direction.
It seems to me that it is a very roundabout way. It may be correct,
but it is unclear why the magic +/-3600 shift is the right solution
and I suspect even you wouldn't notice if I sent you back your patch
with a slight change to swap $gm += 3600 and $gm -= 3600 lines ;-).
For that timestamp in question, the human-readable representation of
gmtime($t) and localtime($t) look like these two strings:
my $t = 1162105199;
print gmtime($t), \n;# Sun Oct 29 06:59:59 2006
print localtime($t), \n; # Sun Oct 29 01:59:59 2006
As a human, you can easily see that these two stringified timestamps
look 5 hours apart. Think how you managed to do so.
If we convert these back to the seconds-since-epoch, as if these
broken-down times were both in a single timezone that does not have
any DST issues, you can get the offset (in seconds) by subtraction,
and that is essentially the same as the way in which your eyes saw
they are 5 hours apart, no? In other words, why do you need to run
timelocal() at all?
my $t = 1162105199;
my $lct = timegm(localtime($t));
# of course, timegm(gmtime($t)) == $t
my $minutes = int(($lct - $t)/60);
my $sign +;
if ($minutes 0) {
$sign = -;
$minutes = -$minutes;
}
my $hours = int($minutes/60);
$minutes -= $hours * 60;
sprintf(%s%02d%02d, $sign, $hours, $minutes);
Confused...
Signed-off-by: Ben Walton bdwal...@gmail.com
---
perl/Git.pm | 20
1 file changed, 20 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index 5649bcc..788b9b4 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -528,7 +528,27 @@ If TIME is not supplied, the current local time is used.
sub get_tz_offset {
# some systmes don't handle or mishandle %z, so be creative.
my $t = shift || time;
+ # timelocal() has a problem when it comes to DST ambiguity so
+ # times that are on a DST boundary cannot be properly converted
+ # using it. we will possibly adjust its result depending on whehter
+ # pre and post conversions agree on DST
my $gm = timelocal(gmtime($t));
+
+ # we need to know whether we were originally in DST or not
+ my $orig_dst = (localtime($t))[8];
+ # and also whether timelocal thinks we're in DST
+ my $conv_dst = (localtime($gm))[8];
+
+ # re-adjust $gm based on the DST value for the two times we're
+ # handling.
+ if ($orig_dst != $conv_dst) {
+ if ($orig_dst == 1) {
+ $gm -= 3600;
+ } else {
+ $gm += 3600;
+ }
+ }
+
my $sign = qw( + + - )[ $t = $gm ];
return sprintf(%s%02d%02d, $sign, (gmtime(abs($t - $gm)))[2,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
Changing Spell checker under GIT
As my organization has change from RedHat 5 to RedHat 6 Linux, it appears that RedHat is trying to replace (deprecate) ispell/aspell with a different tool (hunspell). It appears that GIT GUI current supports changing the dictionary used to support spell checks. Is there currently a way to change the spell check program to be used(can't find in documentation or version of code that I'm currently installing), or would someone consider this as a future program change? Thanks for your time. Mike Hall-- 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
git pull - reporting that I modified files, but I did not
When I do a git pull, I am getting a messages that changes to local files would be overwritten by a merge, but I have not changed these files locally at all, I have not opened them in my IDE. This happens every now and then. 1) Why does this happen? 2) How do I prevent this from happening in the future? 3) How do I get out of this state so that I can do a git pull and rebuild my code? --- In other instances, when I do a git pull (not getting the message above, I will see something like: M src/MyClass.java = a file that I did not touch or modify D src/AnotherClass.java = a file that I did not delete or touch M src/MyModifiedClass.java = a file that I indeed modified for which in the pull there are no merge conflicts. and the pull is successful, (then I want to push my changes), but I did not change either of the above two files If I see the above, am I OK to push? My thinking is that git thinks I changed 'src/MyClass.java' and if I do a diff there are differences, but I do not want to push because I NEVER TOUCHED THAT FILE IN ANY WAY. What is going on here? Maybe this is normal and I simply do not understand correctly. What is happening? I would expect to see only line items 'M' and 'D' for files that I personally have modified and deleted. If I push at this point, will I overwrite changes in the repo pushed by others and muck things up? thanks J.V. -- 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
Re: Changing Spell checker under GIT
Hi Mike, Mike Hall wrote: As my organization has change from RedHat 5 to RedHat 6 Linux, it appears that RedHat is trying to replace (deprecate) ispell/aspell with a different tool (hunspell). It appears that GIT GUI current supports changing the dictionary used to support spell checks. Is there currently a way to change the spell check program to be used(can't find in documentation or version of code that I'm currently installing), or would someone consider this as a future program change? git-gui uses the aspell command as a spellchecker. A patch to add hunspell support sounds like it would be a nice addition. If you'd like to work on it, then lib/spellcheck.tcl in git://repo.or.cz/git-gui might be a good place to start. Hope that helps, Jonathan -- 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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
John Keeping j...@keeping.me.uk writes:
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Hmph. So what happens when the path is _not_ encoded in UTF-8?
Is the repo.hash (and local.hash that gets a copy of it) something
that needs to stay the same across multiple invocations of this
remote helper, and between the currently shipped Git and the version
of Git after applying this patch? If that is not the case, and if
this is used only to get a randomly-looking 40-byte hexadecimal
string, then a lossy attempt to .encode('utf-8') and falling back to
replace or ignore bytes in the original that couldn't be interpreted
as part of a UTF-8 string would be OK, but doesn't .encode('utf-8')
throw an exception if not told to 'ignore' or something?
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..f8dc196 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('utf-8'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
Junio C Hamano gits...@pobox.com writes: John Keeping j...@keeping.me.uk writes: Under Python 3 'hasher.update(...)' must take a byte string and not a unicode string. Explicitly encode the argument to this method as UTF-8 so that this code works under Python 3. This moves the required Python version forward to 2.0. Signed-off-by: John Keeping j...@keeping.me.uk --- Hmph. So what happens when the path is _not_ encoded in UTF-8? Oh, my brain was not working. Forget this part, and sorry for the noise. We are not decoding a bytestring to an array of unicode characters, but going the other way around here. -- 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
Re: [PATCH] Add --unannotate option to git-subtree
On Mon, Dec 31, 2012 at 8:15 PM, gree...@obbligato.org wrote: James Nylen jny...@gmail.com writes: Rather than adding a marker to each commit when splitting out the commits back to the subproject, --unannotate removes the specified string (or bash glob pattern) from the beginning of the first line of the commit message. This enables the following workflow: I applied the patch to my working copy but it doesn't seem to do what I'd expect. The test script does something like this: - create project A - add file to project A with message subproj: add F1 - add file to project A with message subproj: add F2 - add project A as a subtree of project B under directory subdir - add a file to subdir with message subproj: add F3 - do a split --unannotate=subproj: I expected to see a log with no mention of subproj anywhere. Instead I get: add F3 subproj: add F2 subproj: add F1 Is this as you intend? Is --unannotate only supposed to strip the string for commits added when A was a subtree of B? I guess this behavior makes sense in that the user would want to see the same commits that existed before A became a subproject. -David Wow, I missed a bunch of emails on this. Thanks for applying and for writing tests! This is as intended. You wouldn't want subtree to modify commits that occurred in the full repository for project A. Furthermore, you wouldn't have a subproj: commit in project A's standalone repo since it wasn't a subproject at that time. The --annotate option confused me because it was the reverse of what I wanted. As in your example, a typical use would be 'add a file to subdir with message subproj: add F3 ' to make it clear that you were committing to the subproj part of a larger repository. Then, when splitting back out to subproj's main repository, you'd want to remove the prefix. -- 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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
On Thu, Jan 17, 2013 at 09:00:48PM +, John Keeping wrote: On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Under Python 3 'hasher.update(...)' must take a byte string and not a unicode string. Explicitly encode the argument to this method as UTF-8 so that this code works under Python 3. This moves the required Python version forward to 2.0. Signed-off-by: John Keeping j...@keeping.me.uk --- Hmph. So what happens when the path is _not_ encoded in UTF-8? Do you mean encodable? As you say below it will currently throw an exception. Now my brain's not working - we shouldn't get an error converting from a Unicode string to UTF-8, so I think this patch is OK as it is. Is the repo.hash (and local.hash that gets a copy of it) something that needs to stay the same across multiple invocations of this remote helper, and between the currently shipped Git and the version of Git after applying this patch? It's used to specify the path of the repository for importing or exporting, so it should stay consistent across invocations. However, this is only an example remote helper so I don't think we should worry if it changes from one Git release to the next. -- 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
Re: [PATCH 2/8] Add --unannotate
On Tue, Jan 1, 2013 at 5:31 PM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? That's not a bad idea. I'd have to think a bit about a sensible design. Do you have any ideas, James? I just now saw these emails. I'm having a hard time thinking of any good use case other than: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib's main repo, and remove the fancylib: prefix You could potentially have something like Don't crash as much (fancylib) but that's awkward. What might you want to do with a pattern-based rewrite that doesn't involve removing a prefix when splitting commits? In fact, I don't see the use of the original --annotate option at all, since it causes more detailed commit messages in the smaller of the two repositories. -- 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
[PATCH] git-svn: do not escape certain characters in paths
Subversion 1.7 and newer implement HTTPv2, an extension that should make HTTP
more efficient. Servers with support for this protocol will make the subversion
client library take an alternative code path that checks (with assertions)
whether the URL is canonical or not.
This patch fixes an issue I encountered while trying to `git svn dcommit` a
rename action for a file containing a single quote character (User's Manual
to UserMan.tex). It does not happen for older subversion 1.6 servers nor
non-HTTP(S) protocols such as the native svn protocol, only on an Apache server
shipping SVN 1.7. Trying to `git svn dcommit` under the aforementioned
conditions yields the following error which aborts the commit process:
Committing to http://example.com/svn ...
perl: subversion/libsvn_subr/dirent_uri.c:1520: uri_skip_ancestor:
Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
error: git-svn died of signal 6
An analysis of the subversion source for the cause:
- The assertion originates from uri_skip_ancestor which calls
svn_uri_is_canonical, which fails when the URL contains percent-encoded values
that do not necessarily have to be encoded (not canonical enough). This is
done by a table lookup in libsvn_subr/path.c. Putting some debugging prints
revealed that the character ' is indeed encoded to %27 which is not
considered canonical.
- url_skip_ancestor is called by svn_ra_neon__get_baseline_info with the root
repository URL and path as parameters;
- which is called by copy_resource (libsvn_ra_neon/commit.c) for a copy action
(or in my case, renaming which is actually copy + delete old);
- which is called by commit_add_dir;
- which is assigned as a structure method add_file in
svn_ra_neon__get_commit_editor.
In the whole path, the path argument is not modified.
Through some more uninteresting wrapper functions, the Perl bindings gives you
access to the add_file method which will pass the path argument without
modifications to svn.
git-svn calls the R(ename) subroutine in Git::SVN::Editor which contains:
326 my $fbat = $self-add_file($self-repo_path($m-{file_b}), $pbat,
327 $self-url_path($m-{file_a}), $self-{r});
repo_path basically returns the path as-is, unless the svn.pathnameencoding
configuration property is set. url_path tries to escape some special
characters, but does not take all special characters into account, thereby
causing the path to contain some escaped characters which do not have to be
escaped.
The list of characters not to be escaped are taken from the
subversion/libsvn_subr/path.c file to fully account for all characters. Tested
with a filename containing all characters in the range 0x20 to 0x78 (inclusive).
Signed-off-by: Peter Wu lekenst...@gmail.com
---
perl/Git/SVN/Editor.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 3bbc20a..30f92cb 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -145,7 +145,8 @@ sub repo_path {
sub url_path {
my ($self, $path) = @_;
if ($self-{url} =~ m#^https?://#) {
- $path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf(%%%02x,ord($1))!eg;
+ # characters are taken from subversion/libsvn_subr/path.c
+ $path =~ s#([^~a-zA-Z0-9_./!$'()*+,-])#uc
sprintf(%%%02x,ord($1))#eg;
}
$self-{url} . '/' . $self-repo_path($path);
}
--
1.8.1.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
RE: Question re. git remote repository
Hi David, Ok, now I'm really lost! This is definitely due to my newbie git status but I'll ask anyway. I'm confused by your statement ... if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems. Isn't that the whole point of git, or any versioning system? I thought the idea was that each developer installed git locally on their machines and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network server (and which I'm assuming has git installed locally as well). What am I missing? The 'other' David Lang ;-) -Original Message- From: David Lang [mailto:da...@lang.hm] Sent: Wednesday, January 16, 2013 6:01 PM To: Stephen Smith Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David Subject: Re: Question re. git remote repository On Wed, 16 Jan 2013, Stephen Smith wrote: Ideally we'd prefer to simply create our remote repository on a drive of one of our local network servers. Is this possible? Yes, this is possible, but it's not advised to keep such a reference repository on an exported networked drive for a number of reasons (both performance and bug-free operation). I agree that performance is not ideal (although if you are on a fast LAN, it probably would not matter much), but I do not recall any specific bugs in that area. Can you elaborate? This one [1] for instance. I also recall seing people having other mystical problems with setups like this so I somehow developed an idea than having a repository on a networked drive is asking for troubles. Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. 1. http://code.google.com/p/msysgit/issues/detail?id=130 A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem. But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems. David Lang This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. -- 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
[PATCH] simplify-merges: drop merge from irrelevant side branch
The merge simplification rule stated in 6546b59 (revision traversal:
show full history with merge simplification, 2008-07-31) still
treated merge commits too specially. Namely, in a history with this
shape:
---o---o---M
/
x---x---x
where three 'x' were on a history completely unrelated to the main
history 'o' and do not touch any of the paths we are following, we
still said that after simplifying all of the parents of M, 'x'
(which is the leftmost 'x' that rightmost 'x simplifies down to) and
'o' (which would be the last commit on the main history that touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the paths.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The old test vector had a history ending at I; the updates to it
adds an unrelated side branch rooted at J, merge of I and J which
is K, and then an extra commit L on top.
A---(some merge mess)---I---K---L
/
J
revision.c | 19 +++
t/t6012-rev-list-simplify.sh | 26 +-
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/revision.c b/revision.c
index 33cb207..532611b 100644
--- a/revision.c
+++ b/revision.c
@@ -1424,6 +1424,22 @@ static struct merge_simplify_state
*locate_simplify_state(struct rev_info *revs,
return st;
}
+static void remove_treesame_parents(struct commit *commit)
+{
+ struct commit_list **pp, *p;
+
+ pp = commit-parents;
+ while ((p = *pp) != NULL) {
+ struct commit *parent = p-item;
+ if (parent-object.flags TREESAME) {
+ *pp = p-next;
+ free(p);
+ continue;
+ }
+ pp = p-next;
+ }
+}
+
static struct commit_list **simplify_one(struct rev_info *revs, struct commit
*commit, struct commit_list **tail)
{
struct commit_list *p;
@@ -1469,6 +1485,9 @@ static struct commit_list **simplify_one(struct rev_info
*revs, struct commit *c
pst = locate_simplify_state(revs, p-item);
p-item = pst-simplified;
}
+
+ remove_treesame_parents(commit);
+
cnt = remove_duplicate_parents(commit);
/*
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index 510bb96..d6d79c4 100755
--- a/t/t6012-rev-list-simplify.sh
+++ b/t/t6012-rev-list-simplify.sh
@@ -59,7 +59,23 @@ test_expect_success setup '
echo Final change file
test_tick git commit -a -m Final change
- note I
+ note I
+
+ git symbolic-ref HEAD refs/heads/unrelated
+ git rm -f *
+ echo Unrelated branch side
+ git add side
+ test_tick git commit -m Side root
+ note J
+
+ git checkout master
+ test_tick git merge -m Coolest unrelated
+ note K
+
+ echo Immaterial elif
+ git add elif
+ test_tick git commit -m Last
+ note L
'
FMT='tformat:%P%H | %s'
@@ -82,10 +98,10 @@ check_result () {
'
}
-check_result 'I H G F E D C B A' --full-history
-check_result 'I H E C B A' --full-history -- file
-check_result 'I H E C B A' --full-history --topo-order -- file
-check_result 'I H E C B A' --full-history --date-order -- file
+check_result 'L K J I H G F E D C B A' --full-history
+check_result 'K I H E C B A' --full-history -- file
+check_result 'K I H E C B A' --full-history --topo-order -- file
+check_result 'K I H E C B A' --full-history --date-order -- file
check_result 'I E C B A' --simplify-merges -- file
check_result 'I B A' -- file
check_result 'I B A' --topo-order -- file
--
1.8.1.1.431.g469ab37
--
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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue, no?
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..f8dc196 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or
later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or
later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('utf-8'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue, no?
Even better. Are you happy to squash that in (assuming nothing else
comes up) or shall I resend?
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..f8dc196 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or
later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or
later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('utf-8'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
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
Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
John Keeping j...@keeping.me.uk writes:
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue, no?
Even better. Are you happy to squash that in (assuming nothing else
comes up) or shall I resend?
If you go the .encode('hex') route, the log message needs to explain
why the hashed values are now different from the old implementation
and justify why it is safe to do so. I do not think I want to do
that myself ;-).
Thanks.
git-remote-testpy.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index d94a66a..f8dc196 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
-if sys.hexversion 0x01050200:
-# os.makedirs() is the limiter
-sys.stderr.write(git-remote-testgit: requires Python 1.5.2 or
later.\n)
+if sys.hexversion 0x0200:
+# string.encode() is the limiter
+sys.stderr.write(git-remote-testgit: requires Python 2.0 or
later.\n)
sys.exit(1)
def get_repo(alias, url):
@@ -45,7 +45,7 @@ def get_repo(alias, url):
repo.get_head()
hasher = _digest()
-hasher.update(repo.path)
+hasher.update(repo.path.encode('utf-8'))
repo.hash = hasher.hexdigest()
repo.get_base_path = lambda base: os.path.join(
--
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
Re: git pull - reporting that I modified files, but I did not
On 17.01.2013, at 20:29, Jay Vee wrote: When I do a git pull, I am getting a messages that changes to local files would be overwritten by a merge, but I have not changed these files locally at all, I have not opened them in my IDE. This happens every now and then. 1) Why does this happen? This is hard to tell given the little information you provide. But clearly *something* modified those files, whether consciously triggered by you or not. But files don't magically change themselves :-). I recommend that you run git diff on those files to figure out in what way they changed -- this will likely provide a clue to the cause for this. All I can say is that it is extremely unlikely that git did this, unless it happens to be something you (or somebody who has access to your git config resp. the repository config) explicitly activated and thus requested from git (e.g. via clean or smudge filters in gitattributes). 2) How do I prevent this from happening in the future? As this largely depends on the cause, it can't be answered before 1) is answered... 3) How do I get out of this state so that I can do a git pull and rebuild my code? At least over here, when I do a git status, it actually prints a nice message that explains how to do this. For example, I see something like this: # On branch next # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: src/MyClass.java # deleted:src/AnotherClass.java # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/MyModifiedClass.java # deleted:src/YetAnotherClass.java ... But I would strongly urge you to first review those changes, to make sure that they are really OK to discard. For example, you wouldn't want to throw away a change you did make on purpose but forgot to commit. --- In other instances, when I do a git pull (not getting the message above, I will see something like: M src/MyClass.java = a file that I did not touch or modify D src/AnotherClass.java = a file that I did not delete or touch M src/MyModifiedClass.java = a file that I indeed modified for which in the pull there are no merge conflicts. Hmm, where is this output from? and the pull is successful, (then I want to push my changes), but I did not change either of the above two files Did you try to find out what the change in them is? E.g. using git diff ? My guess would be that the nature of the changes would give a big clue as to their cause. E.g. did indention change? Line breaks? Where RCS keywords expanded / contracted? Was a random piece of code inserted somewhere? If I see the above, am I OK to push? My thinking is that git thinks I changed 'src/MyClass.java' and if I do a diff there are differences, but I do not want to push because I NEVER TOUCHED THAT FILE IN ANY WAY. Shouting doesn't help :-). Something on your computer *did* touch the file. Git does not magically change your stuff -- unless in very special cases, but then only when *explicitly* configured to do so by somebody. What is going on here? Maybe this is normal and I simply do not understand correctly. It doesn't sound normal, but it doesn't sound like an issue with git either, more like one with your particular setup. It is hard to say more since you give us very little concrete information. E.g. what kind of changes are in those files? Which git version, and what OS are you on? Do you use git via the command line exclusively, or do you use a frontend(s) for it? etc. What is happening? I would expect to see only line items 'M' and 'D' for files that I personally have modified and deleted. What do you mean by personally? Is a cron job you setup and forgot counting towards this, too? What about automatic changes caused by an IDE or a Git frontend? What about automatic changes caused by a git config setting you or a friendly co-worker setup in your gitconfig but you forgot about? If I push at this point, will I overwrite changes in the repo pushed by others and muck things up? A push will only push any commits you made. And a commit will only include changes you explicitly staged via git add, or told git commit to include by listing files when doing the commit... So if you worry that what you are about to push is broken, I'd recommend to a) review all local commits and their contents before pushing them, and b) testing your work before pushing it. Cheers, Max-- 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
RE: Question re. git remote repository
distributed version control systems let each developer have a full repository locally on their machine, they then can send updates to other people who have a repository (or a pull request which asks the other person to pull from the developers repository to the other persons repository) Most projects have one repository that they designate as being the 'main' repository for the project, and developers push updates to it (or send pull requests to the people who own that repository) The communication between developers is typically via e-mail and the repository updates are sent via the git-daemon and the git network protocol. This sort of thing is very different from the model where there is one repository on a shared disk somewhere and everyone accesses that shared disk to do their work or apply updates via NFS/CIFS protocols. Does this clarify the difference? David Lang On Thu, 17 Jan 2013, Lang, David wrote: Hi David, Ok, now I'm really lost! This is definitely due to my newbie git status but I'll ask anyway. I'm confused by your statement ... if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems. Isn't that the whole point of git, or any versioning system? I thought the idea was that each developer installed git locally on their machines and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network server (and which I'm assuming has git installed locally as well). What am I missing? The 'other' David Lang ;-) -Original Message- From: David Lang [mailto:da...@lang.hm] Sent: Wednesday, January 16, 2013 6:01 PM To: Stephen Smith Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David Subject: Re: Question re. git remote repository On Wed, 16 Jan 2013, Stephen Smith wrote: Ideally we'd prefer to simply create our remote repository on a drive of one of our local network servers. Is this possible? Yes, this is possible, but it's not advised to keep such a reference repository on an exported networked drive for a number of reasons (both performance and bug-free operation). I agree that performance is not ideal (although if you are on a fast LAN, it probably would not matter much), but I do not recall any specific bugs in that area. Can you elaborate? This one [1] for instance. I also recall seing people having other mystical problems with setups like this so I somehow developed an idea than having a repository on a networked drive is asking for troubles. Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. 1. http://code.google.com/p/msysgit/issues/detail?id=130 A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem. But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems. David Lang This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. -- 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
Re: Question re. git remote repository
On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote: This one [1] for instance. I also recall seing people having other mystical problems with setups like this so I somehow developed an idea than having a repository on a networked drive is asking for troubles. Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. 1. http://code.google.com/p/msysgit/issues/detail?id=130 A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem. That should not be an issue. Git on a server has to deal with multiple independent receive-pack's running to accept several simultaneous pushes. They coordinate through the use of file locks. Having multiple machines pushing over a shared filesystem should work the same, as long as the filesystem support atomic creation of files with O_EXCL. There may be other subtle issues lurking (e.g., the Windows issue that Konstantin mentioned), but as far as I know, it _should_ work in general. -Peff -- 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
Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
Jean-Noël AVILA wrote: OK. I have installed practically everything related to git from the package manager and there is a git-checkout-branches utility available. That result defeats the purpose of the test. This needs a tighter environment to work whatever the configuration of the user may be. Presumably 'git checkout-branches' is from git-stuff. Here's a patch to make the tested command a little less likely to conflict with commands from the user's $PATH. I'm not thrilled with it because the contents of $PATH are still not tightly controlled, and this does nothing to avoid problems due to existence of, for example, a git cherry-pick-branches command. Thoughts? Maybe it would be enough to check that the intended get commands are present in the completion list and other git commands are not, ignoring binaries that might live elsewhere on the $PATH? Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- t/t9902-completion.sh | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh index 3cd53f8..06dcfb2 100755 --- a/t/t9902-completion.sh +++ b/t/t9902-completion.sh @@ -192,19 +192,19 @@ test_expect_success 'general options' ' ' test_expect_success 'general options plus command' ' - test_completion git --version check checkout - test_completion git --paginate check checkout - test_completion git --git-dir=foo check checkout - test_completion git --bare check checkout - test_completion git --help des describe - test_completion git --exec-path=foo check checkout - test_completion git --html-path check checkout - test_completion git --no-pager check checkout - test_completion git --work-tree=foo check checkout - test_completion git --namespace=foo check checkout - test_completion git --paginate check checkout - test_completion git --info-path check checkout - test_completion git --no-replace-objects check checkout + test_completion git --version cherry-p cherry-pick + test_completion git --paginate cherry-p cherry-pick + test_completion git --git-dir=foo cherry-p cherry-pick + test_completion git --bare cherry-p cherry-pick + test_completion git --help cherry-p cherry-pick + test_completion git --exec-path=foo cherry-p cherry-pick + test_completion git --html-path cherry-p cherry-pick + test_completion git --no-pager cherry-p cherry-pick + test_completion git --work-tree=foo cherry-p cherry-pick + test_completion git --namespace=foo cherry-p cherry-pick + test_completion git --paginate cherry-p cherry-pick + test_completion git --info-path cherry-p cherry-pick + test_completion git --no-replace-objects cherry-p cherry-pick ' test_expect_success 'setup for ref completion' ' -- 1.8.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
Re: t9902 fails
Jonathan Nieder jrnie...@gmail.com writes: Thoughts? Maybe it would be enough to check that the intended get commands are present in the completion list and other git commands are not, ignoring binaries that might live elsewhere on the $PATH? Yeah, it would be a robust alternative approach to verify that (1) output is a superset of what we expect, and (2) they all share the string we fed to the machinery as the common prefix, I would think. -- 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
What's cooking in git.git (Jan 2013, #07; Thu, 17)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. As usual, this cycle is expected to last for 8 to 10 weeks, with a preview -rc0 sometime in the middle of next month. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * fc/remote-hg-fixup-url (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at d2acb2d) + remote-hg: store converted URL Update to the Hg remote helper (in contrib/). Will merge to 'master'. * mh/remote-hg-mode-bits-fix (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at ad57d9f) + remote-hg: fix handling of file perms when pushing Update to the Hg remote helper (in contrib/). Will merge to 'master'. * jc/valgrind-memcmp-bsearch (2013-01-14) 1 commit - ignore memcmp() overreading in bsearch() callback Squelch false positive in valgrind tests Will discard. * mh/imap-send-shrinkage (2013-01-15) 14 commits - imap-send.c: simplify logic in lf_to_crlf() - imap-send.c: fold struct store into struct imap_store - imap-send.c: remove unused field imap_store::uidvalidity - imap-send.c: use struct imap_store instead of struct store - imap-send.c: remove unused field imap_store::trashnc - imap-send.c: remove namespace fields from struct imap - imap-send.c: remove struct imap argument to parse_imap_list_l() - imap-send.c: inline parse_imap_list() in parse_list() - imap-send.c: remove some unused fields from struct store - imap-send.c: remove struct message - imap-send.c: remove struct store_conf - iamp-send.c: remove unused struct imap_store_conf - imap-send.c: remove struct msg_data - imap-send.c: remove msg_data::flags, which was always zero Remove a lot of unused code from git imap-send. With a further comment fixup in patch #6, this seems ready for 'next'. Expecting a reroll. * nd/attr-debug-fix (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at 8460acf) + attr: make it build with DEBUG_ATTR again Fix debugging support that was broken in earlier change. Will merge to 'master'. * nd/fix-directory-attrs-off-by-one (2013-01-16) 2 commits (merged to 'next' on 2013-01-16 at bd63e61) + attr: avoid calling find_basename() twice per path (merged to 'next' on 2013-01-15 at e0a0129) + attr: fix off-by-one directory component length calculation Fix performance regression introduced by an earlier change to let attributes apply to directories. Will merge to 'master'. * nd/fix-perf-parameters-in-tests (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at fedbdb9) + test-lib.sh: unfilter GIT_PERF_* Allow GIT_PERF_* environment variables to be passed through the test framework. Will merge to 'master'. * pw/p4-branch-fixes (2013-01-15) 14 commits (merged to 'next' on 2013-01-15 at 1ee379e) + git p4: fix submit when no master branch + git p4 test: keep P4CLIENT changes inside subshells + git p4: fix sync --branch when no master branch + git p4: fail gracefully on sync with no master branch + git p4: rearrange self.initialParent use + git p4: allow short ref names to --branch + git p4 doc: fix branch detection example + git p4: clone --branch should checkout master + git p4: verify expected refs in clone --bare test + git p4: create p4/HEAD on initial clone + git p4: inline listExistingP4GitBranches + git p4: add comments to p4BranchesInGit + git p4: rearrange and simplify hasOrigin handling + git p4: test sync/clone --branch behavior Fix git p4 around branch handling. Will merge to 'master'. * ss/help-htmlpath-config-doc (2013-01-15) 1 commit (merged to 'next' on 2013-01-17 at 99bfae2) + config.txt: Document help.htmlpath config parameter Add missing doc. Will merge to 'master'. * cr/push-force-tag-update (2013-01-16) 1 commit - push: fix refs/tags/ hierarchy cannot be updated without --force Regression fix. Will merge to 'next' and then to 'master' soonish. * jk/suppress-clang-warning (2013-01-16) 1 commit - fix clang -Wunused-value warnings for error functions Will merge to 'next'. * rs/clarify-entry-cmp-sslice (2013-01-16) 1 commit - refs: use strncmp() instead of strlen() and memcmp() Will merge to 'next'. * ch/add-auto-submitted-in-sample-post-receive-email (2013-01-17) 1 commit - Add Auto-Submitted header to post-receive-email Will merge to 'next'. * jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit - simplify-merges: drop merge from irrelevant side branch The --simplify-merges logic did not cull irrelevant parents from a merge that is otherwise not interesting with respect to the paths we are following. As this touches a fairly core part of the revision traversal infrastructure, it is appreciated to have an extra set of eyes for sanity check. Waiting for
Re: [PATCH] git-svn: teach find-rev to find near matches
John Keeping j...@keeping.me.uk wrote: When a single SVN repository is split into multiple Git repositories many SVN revisions will exist in only one of the Git repositories created. For some projects the only way to build a working artifact is to check out corresponding versions of various repositories, with no indication of what those are in the Git world - in the SVN world the revision numbers are sufficient. By adding --before to git-svn find-rev we can say tell me what this repository looked like when that other repository looked like this: git svn find-rev --before \ r$(git --git-dir=/over/there.git svn find-rev HEAD) Signed-off-by: John Keeping j...@keeping.me.uk Thanks. Signed-off-by: Eric Wong normalper...@yhbt.net I've pushed this out to git://bogomips.org/git-svn along with a few other things I seem to have forgotten about :x John Keeping (1): git-svn: teach find-rev to find near matches Jonathan Nieder (2): Git::SVN::Editor::T: pass $deletions to -A and -D git svn: do not overescape URLs (fallback case) -- 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
Re: [PATCH v6 0/8] push: update remote tags only with force
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote: I was referring to your concern about rejecting based on type. A push causing a reference to move (for example) from a commit to a blob is rejected as already exists with this patch. You emphatically state this is not OK and your solution is to revert back to behavior that advises a merge. Clearly the bug regarding an 'old' unknown to the client should be fixed. This is a obvious test case I should have covered and it's unfortunate it made it into master. But I don't understand why is_forwardable() was misguided (maybe poorly named) nor why ref_newer() is a better place to solve the issues it was addressing. I think that a type-based rule that relies on knowing the type of the other side will always have to guess in some cases, because we do not necessarily have that information. However, if instead of the rule being blobs on the remote side cannot be replaced, if it becomes the old value on the remote side must be referenced by what we replace it with, that _is_ something we can calculate reliably on the sending side. And that is logically an extension of the fast-forward rule, which is why I suggested placing it with ref_newer (but the latter should probably be extended to not suggest merging if we _know_ it is a non-commit object). -Peff -- 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
Re: [PATCH v6 0/8] push: update remote tags only with force
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote: However, if instead of the rule being blobs on the remote side cannot be replaced, if it becomes the old value on the remote side must be referenced by what we replace it with, that _is_ something we can calculate reliably on the sending side. Interesting. I would have thought knowing reachability implied having the old object in the sending repository. And that is logically an extension of the fast-forward rule, which is why I suggested placing it with ref_newer (but the latter should probably be extended to not suggest merging if we _know_ it is a non-commit object). Sounds great, especially if it is not dependent on the sender actually having the old object. Until this is implemented, though, I don't understand what was wrong with doing the checks in the is_forwardable() helper function (of course after fixing the regression/bug.) Chris -- 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
Re: [PATCH v2 8/8] git-remote-testpy: call print as a function
Looks harmless enough.
Acked-by: Sverre Rabbelier srabbel...@gmail.com
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping j...@keeping.me.uk wrote:
This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3. Since this is the only change
required to make this script just run under Python 3 without needing
2to3 it seems worthwhile.
The case of an empty print must be handled specially because in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-remote-testpy.py | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index bc5e3cf..ccdb2dc 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -87,9 +87,9 @@ def do_capabilities(repo, args):
Prints the supported capabilities.
-print import
-print export
-print refspec refs/heads/*:%s* % repo.prefix
+print(import)
+print(export)
+print(refspec refs/heads/*:%s* % repo.prefix)
dirname = repo.get_base_path(repo.gitdir)
@@ -98,11 +98,11 @@ def do_capabilities(repo, args):
path = os.path.join(dirname, 'git.marks')
-print *export-marks %s % path
+print(*export-marks %s % path)
if os.path.exists(path):
-print *import-marks %s % path
+print(*import-marks %s % path)
-print # end capabilities
+print('') # end capabilities
def do_list(repo, args):
@@ -115,16 +115,16 @@ def do_list(repo, args):
for ref in repo.revs:
debug(? refs/heads/%s, ref)
-print ? refs/heads/%s % ref
+print(? refs/heads/%s % ref)
if repo.head:
debug(@refs/heads/%s HEAD % repo.head)
-print @refs/heads/%s HEAD % repo.head
+print(@refs/heads/%s HEAD % repo.head)
else:
debug(@refs/heads/master HEAD)
-print @refs/heads/master HEAD
+print(@refs/heads/master HEAD)
-print # end list
+print('') # end list
def update_local_repo(repo):
@@ -164,7 +164,7 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
-print feature done
+print(feature done)
if os.environ.get(GIT_REMOTE_TESTGIT_FAILURE):
die('Told to fail')
@@ -172,7 +172,7 @@ def do_import(repo, args):
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
-print done
+print(done)
def do_export(repo, args):
@@ -192,8 +192,8 @@ def do_export(repo, args):
repo.non_local.push(repo.gitdir)
for ref in changed:
-print ok %s % ref
-print
+print(ok %s % ref)
+print('')
COMMANDS = {
--
1.8.1.1.260.g99b33f4.dirty
--
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
--
Cheers,
Sverre Rabbelier
--
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
Re: [PATCH v2 7/8] git-remote-testpy: don't do unbuffered text I/O
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping j...@keeping.me.uk wrote: -sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0) +sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0) It is not immediately obvious why you would open stdin in rb mode, please add a comment. -- Cheers, Sverre Rabbelier -- 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
bug: git-svn seg fault during 'git svn fetch' due to perl 5.10
In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a seg fault. It's caused by git-svn trying to parse a large yaml file (introduced in https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540 ) which encounters a perl regex stack overflow bug that was present in perl 5.10 (https://bugzilla.redhat.com/show_bug.cgi?id=192400). We'll find a work around, but it'd be nice if there was a config setting to let us choose not to use the yaml format. Let me know if there's a better place to report this. -Durham -- 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
Re: [PATCH v6 0/8] push: update remote tags only with force
Jeff King p...@peff.net writes: However, if instead of the rule being blobs on the remote side cannot be replaced, if it becomes the old value on the remote side must be referenced by what we replace it with, that _is_ something we can calculate reliably on the sending side. And that is logically an extension of the fast-forward rule,... It may be an extension of the fast-forward, but only in the graph reachability sense. I can buy that it is mathmatically consistent with the mode that has proven to be useful for commits at the branch tips, which we know why fast-forward rule is an appropriate default for. You haven't shown if that mathmatical consistency is useful for non-commit case. The primary reason fast-forward is a good default for branches is not that we do not want to lose objects to gc (you have reflog for that). The reason is non fast-forward is a sign of unintended rewind, and later will cause duplicated history with merge conflicts. That comes from the way objects pointed by refs/heads aka branches are used. It is not just commit (as object type), but how these objects are used. Think why we decided it was a good idea to do one thing in the topic that introduced the regression under discussion: Even if the new commit is a descendant of the old commit, we do not want to fast-forward a ref if it is under refs/tags/. Type of object may be one factor, but how it is used is more important factor in deciding what kind of policy is appropriate. If users have workflows that want to have a ref hierarchy that point at a blob, there will not be any update to such a ref that will satisfy your definition of extended fast-forward requirement, and that requirement came solely from mathematical purity (i.e. graph reachability), not from any workflow consideration. That is very disturbing to me. A workflow that employes such a blob at a ref may perfectly be happy with replacing the blob as last-one-wins basis. I do not think the client side should enforce a policy to forbid such a push. I personally think the current client side that insists that updates to any ref has to have the current object and must fast-forward and requires --force otherwise was a mistake (this predates the change by Chris). The receiving end does not implement such an arbitrary restriction outside refs/heads/, and does so only for refs/heads/ only when deny-non-fast-forwards is set. -- 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
Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
On Thu, Jan 17, 2013 at 10:53 AM, John Keeping j...@keeping.me.uk wrote: [1] http://wiki.python.org/moin/PortingPythonToPy3k This link seems dead. -- Cheers, Sverre Rabbelier -- 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
Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
On 18.01.13 01:04, Jonathan Nieder wrote: Jean-Noël AVILA wrote: OK. I have installed practically everything related to git from the package manager and there is a git-checkout-branches utility available. That result defeats the purpose of the test. This needs a tighter environment to work whatever the configuration of the user may be. Presumably 'git checkout-branches' is from git-stuff. Here's a patch to make the tested command a little less likely to conflict with commands from the user's $PATH. I'm not thrilled with it because the contents of $PATH are still not tightly controlled, and this does nothing to avoid problems due to existence of, for example, a git cherry-pick-branches command. Thoughts? Maybe it would be enough to check that the intended get commands are present in the completion list and other git commands are not, ignoring binaries that might live elsewhere on the $PATH? Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- t/t9902-completion.sh | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh index 3cd53f8..06dcfb2 100755 --- a/t/t9902-completion.sh +++ b/t/t9902-completion.sh @@ -192,19 +192,19 @@ test_expect_success 'general options' ' ' test_expect_success 'general options plus command' ' - test_completion git --version check checkout - test_completion git --paginate check checkout - test_completion git --git-dir=foo check checkout - test_completion git --bare check checkout - test_completion git --help des describe - test_completion git --exec-path=foo check checkout - test_completion git --html-path check checkout - test_completion git --no-pager check checkout - test_completion git --work-tree=foo check checkout - test_completion git --namespace=foo check checkout - test_completion git --paginate check checkout - test_completion git --info-path check checkout - test_completion git --no-replace-objects check checkout + test_completion git --version cherry-p cherry-pick + test_completion git --paginate cherry-p cherry-pick + test_completion git --git-dir=foo cherry-p cherry-pick + test_completion git --bare cherry-p cherry-pick + test_completion git --help cherry-p cherry-pick + test_completion git --exec-path=foo cherry-p cherry-pick + test_completion git --html-path cherry-p cherry-pick + test_completion git --no-pager cherry-p cherry-pick + test_completion git --work-tree=foo cherry-p cherry-pick + test_completion git --namespace=foo cherry-p cherry-pick + test_completion git --paginate cherry-p cherry-pick + test_completion git --info-path cherry-p cherry-pick + test_completion git --no-replace-objects cherry-p cherry-pick ' test_expect_success 'setup for ref completion' ' That looks good to me, 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 http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@uhn.ca] I thought the idea was that each developer installed git locally on their machines Yes. and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network server Yes, but committing their changes to the master repository is a two step process: 1. Each developer first commits their changes to their personal repository using the git commit command. 2. Each developer pushes their changes from their personal repository to the master repository with the git push command (and which I'm assuming has git installed locally as well). Maybe. If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol. If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the file protocol. The other David Lang (da...@lang.hm) believes that using git push using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using git push over NFS or CIFS/SMB is safe and reliable: http://permalink.gmane.org/gmane.comp.version-control.git/122670 The GitFaq wiki also says that using git push over NFS or CIFS/SMB is safe and reliable: https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F -- 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
RE: Question re. git remote repository
On Fri, 18 Jan 2013, Matt Seitz wrote: From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@uhn.ca] The other David Lang (da...@lang.hm) believes that using git push using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using git push over NFS or CIFS/SMB is safe and reliable: http://permalink.gmane.org/gmane.comp.version-control.git/122670 The GitFaq wiki also says that using git push over NFS or CIFS/SMB is safe and reliable: https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F I'm glad to learn that git is more robust than I feared. David Lang -- 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
