kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
John Keeping	3ac221a78e	git-remote-testpy: fix path hashing on Python 3 When this change was originally made (`0846b0c` - git-remote-testpy: hash bytes explicitly , I didn't realise that the "hex" encoding we chose is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code. It is not possible to provide a single code path that works on Python 2 and Python 3 since Python 2.x will attempt to decode the string before encoding it, which fails for strings that are not valid in the default encoding. Python 3.1 introduced the "surrogateescape" error handler which handles this correctly and permits a bytes -> unicode -> bytes round-trip to be lossless. As the original came from reading the filesystem path, we convert them back into the original bytes encoded in sys.getfilesystemencoding(). At this point Python 3.0 is unsupported so we don't go out of our way to try to support it. Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
John Keeping	f9640ac26c	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 <john@keeping.me.uk> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
John Keeping	d04c94a2ea	git-remote-testpy: don't do unbuffered text I/O Python 3 forbids unbuffered I/O in text mode. Change the reading of stdin in git-remote-testpy so that we read the lines as bytes and then decode them a line at a time. This allows us to keep the I/O unbuffered in order to avoid reintroducing the bug fixed by commit `7fb8e16` (git-remote-testgit: fix race when spawning fast-import). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
John Keeping	0846b0c905	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 to hex bytes so that we don't need to worry about failures to encode that might occur if we chose a textual encoding. This changes the directory used by git-remote-testpy for its git mirror of the remote repository, but this tool should not have any serious users as it is used primarily to test the Python remote helper framework. The use of encode() moves the required Python version forward to 2.0. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Felipe Contreras	d0ac3ffd9d	Rename git-remote-testgit to git-remote-testpy This script is not really exercising the remote-helper functionality, but more the python framework for remote helpers that live in git_remote_helpers. It's also not a good example of how to write remote-helpers, unless you are planning to use python, and even then you might not want to use this framework. So let's use a more appropriate name: git-remote-testpy. A patch that replaces git-remote-testgit with a simpler version is on the way. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Felipe Contreras	3b705268f5	remote-testgit: fix direction of marks Basically this is what we want: == pull == testgit transport-helper * export -> import # testgit.marks git.marks == push == testgit transport-helper * import <- export # testgit.marks git.marks Each side should be agnostic of the other side. Because testgit.marks (our helper marks) could be anything, not necessarily a format parsable by fast-export or fast-import. In this test they happen to be compatible, because we use those tools, but in the real world it would be something completely different. For example, they might be mapping marks to mercurial revisions (certainly not parsable by fast-import/export). This is what we have: == pull == testgit transport-helper * export -> import # testgit.marks git.marks == push == testgit transport-helper * import <- export # git.marks testgit.marks The only reason this is working is that git.marks and testgit.marks are roughly the same. This new behavior used to not be possible before due to a bug in fast-export, but with the bug fixed, it works fine. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Felipe Contreras	6c32332268	remote-testgit: properly check for errors 'feature done' was missing, which allowed fast-import exit properly, and transport-helper to continue checking for refs and what not when in fact the remote-helper died. Let's enable that, and make sure the error paths are triggered. Now transport-helper correctly detects the errors from fast-import, unfortunately, not from fast-export because it might finish before detecting a SIGPIPE. This means transport-helper will quit silently and the user will not see any errors, which is bad. Hopefully the helper will print the error before dying anyway, so not all is lost. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jeff King <peff@peff.net>	12 years ago
Pete Wyckoff	7fb8e163bd	git-remote-testgit: fix race when spawning fast-import Test "pushing to local repo" in t5800-remote-helpers can hang due to a race condition in git-remote-testgit. Fix it by setting stdin to unbuffered. On the writer side, "git push" invokes push_refs_with_export(), which sends to stdout the command "export\n" and immediately starts up "git fast-export". The latter writes its output stream to the same stdout. On the reader side, remote helper "git-remote-testgit" reads from stdin to get its next command. It uses getc() to read characters from libc up until \n. Libc has buffered a potentially much larger chunk of stdin. When it sees the "export\n" command, it forks "git fast-import" to read the stream. If fast-export finishes before git fast-import starts, the fast-export output can end up in libc's buffer in git-remote-testgit, rather than in git fast-import. The latter hangs indefinitely on a now-empty stdin. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Matthieu Moy	9609dc9ddc	(short) documentation for the testgit remote helper While it's not a command meant to be used by actual users (hence, not mentionned in git(1)), this command is a very precious help for remote-helpers authors. The best place for such technical doc is the source code, but users may not find it without a link in a manpage. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Sverre Rabbelier	a515ebe9f1	transport-helper: implement marks location as capability Now that the gitdir location is exported as an environment variable this can be implemented elegantly without requiring any explicit flushes nor an ad-hoc exchange of values. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Sverre Rabbelier	9504bc9d5a	transport-helper: change import semantics Currently the helper must somehow guess how many import statements to read before it starts outputting its fast-export stream. This is because the remote helper infrastructure runs fast-import only once, so the helper is forced to output one stream for all import commands it will receive. The only reason this worked in the past was because only one ref was imported at a time. Change the semantics of the import statement such that it matches that of the push statement. That is, the import statement is followed by a series of import statements that are terminated by a '\n'. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Sverre Rabbelier	6c8151a32e	transport-helper: update ref status after push with export Also add check_output from python 2.7. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Sverre Rabbelier	1f25c50419	transport-helper: use the new done feature where possible In other words, use fast-export --use-done-feature to add a 'done' command at the end of streams passed to remote helpers' "import" commands, and teach the remote helpers implementing "export" to use the 'done' command in turn when producing their streams. The trailing \n in the protocol signals the helper that the connection is about to close, allowing it to do whatever cleanup neccesary. Previously, the connection would already be closed by the time the trailing \n was to be written. Now that the remote-helper protocol uses the new done command in its fast-import streams, this is no longer the case and we can safely write the trailing \n. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Sverre Rabbelier	0fb56ce716	git-remote-testgit: only push for non-local repositories Trying to push for local repositories will fail since there is no local checkout in .git/info/... to push from as that is only used for non-local repositories (local repositories are pushed to directly). This went unnoticed because the transport helper infrastructure does not check the return value of the helper. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Dmitry Ivankov	e173587252	remote-helpers: export GIT_DIR variable to helpers The gitdir capability is recognized by git and can be used to tell the helper where the .git directory is. But it is not mentioned in the documentation and considered worse than if gitdir was passed via GIT_DIR environment variable. Remove support for the gitdir capability and export GIT_DIR instead. Teach testgit to use env instead of the now-removed gitdir command. [sr: fixed up documentation] Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jeff King	4e51ba238f	git-remote-testgit: import non-HEAD refs Upon receiving an "import" command, the testgit remote helper would ignore the ref asked for by git and generate a fast-export stream based on HEAD. Instead, we should actually give git the ref it asked for. This requires adding a new parameter to the export_repo method in the remote-helpers python library, which may be used by code outside of git.git. We use a default parameter so that callers without the new parameter will get the same behavior as before. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Brandon Casey	23b093ee08	Remove python 2.5'isms The following python 2.5 features were worked around: * the sha module is used as a fallback when the hashlib module is not available * the 'any' built-in method was replaced with a 'for' loop * a conditional expression was replaced with an 'if' statement * the subprocess.check_call method was replaced by a call to subprocess.Popen followed by a call to subprocess.wait with a check of its return status These changes allow the python infrastructure to be used with python 2.4 which is distributed with RedHat's RHEL 5, for example. t5800 was updated to check for python >= 2.4 to reflect these changes. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Brian Gernhardt	f733f6a0c6	Makefile: Simplify handling of python scripts The sed script intended to add a standard opening to python scripts was non-compatible and overly complex. Simplifying it down to a set of one-liners removes the compatibility issues of newlines. Moving the environment alterations from the Makefile to the python scripts makes also makes the scripts easier to run in-place. Specifically, the new sed script: - Alters the shebang line to use the configured Python. - Alters any os.getenv("GITPYTHONLIB") calls to use @@INSTLIBDIR@@ as the default. This will replace any existing default or add a default if none is provided. - Replaces the @@INSTLIBDIR@@ placeholder with the directory git installs its python libraries to. The last two steps could be combined into a single step, but is left separate in case someone has another need for @@INSTLIBDIR@@ in their script. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Sverre Rabbelier	7aeaa2fc0a	remote-helpers: add testgit helper Currently the remote helper infrastructure is only used by the curl helper, which does not give a good impression of how remote helpers can be used to interact with foreign repositories. Since implementing such a helper is non-trivial it would be good to have at least one easy-to-follow example demonstrating how to implement a helper that interacts with a foreign vcs using fast-import/fast-export. The testgit helper can be used to interact with remote git repositories by prefixing the url with "testgit::". Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago

7 Commits (abdea96efdade975246cce0674fa2cfb8a7cc148)