* Re: missing objects -- prevention
From: Jeff King @ 2013-01-12 13:13 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_jN7=Antz-5D7yf0KV8m-YEy93tZP_zziTXPDzbdyjUrw@mail.gmail.com>
On Sat, Jan 12, 2013 at 06:39:52AM +0530, Sitaram Chamarty wrote:
> > 1. The repo has a ref R pointing at commit X.
> >
> > 2. A user starts a push to another ref, Q, of commit Y that builds on
> > X. Git advertises ref R, so the sender knows they do not need to
> > send X, but only Y. The user then proceeds to send the packfile
> > (which might take a very long time).
> >
> > 3. Meanwhile, another user deletes ref R. X becomes unreferenced.
>
> The gitolite logs show that no deletion of refs has happened.
To be pedantic, step 3 could also be rewinding R to a commit before X.
Anything that causes X to become unreferenced.
> > There is a race with simultaneously deleting and packing refs. It
> > doesn't cause object db corruption, but it will cause refs to "rewind"
> > back to their packed versions. I have seen that one in practice (though
> > relatively rare). I fixed it in b3f1280, which is not yet in any
> > released version.
>
> This is for the packed-refs file right? And it could result in a ref
> getting deleted right?
Yes, if the ref was not previously packed, it could result in the ref
being deleted entirely.
> I said above that the gitolite logs say no ref was deleted. What if
> the ref "deletion" happened because of this race, making the rest of
> your 4-step scenario above possible?
It's possible. I do want to highlight how unlikely it is, though.
> > up in the middle, or fsck rejects the pack). We have historically left
>
> fsck... you mean if I had 'receive.fsckObjects' true, right? I don't.
> Should I? Would it help this overall situation? As I understand it,
> thats only about the internals of each object to check corruption, and
> cannot detect a *missing* object on the local object store.
Right, I meant if you have receive.fsckObjects on. It won't help this
situation at all, as we already do a connectivity check separate from
the fsck. But I do recommend it in general, just because it helps catch
bad objects before they gets disseminated to a wider audience (at which
point it is often infeasible to rewind history). And it has found git
bugs (e.g., null sha1s in tree entries).
> > At GitHub, we've taken to just cleaning them up aggressively (I think
> > after an hour), though I am tempted to put in an optional signal/atexit
>
> OK; I'll do the same then. I suppose a cron job is the best way; I
> didn't find any config for expiring these files.
If you run "git prune --expire=1.hour.ago", it should prune stale
tmp_pack_* files more than an hour old. But you may not be comfortable
with such a short expiration for the objects themselves. :)
> Thanks again for your help. I'm going to treat it (for now) as a
> disk/fs error after hearing from you about the other possibility I
> mentioned above, although I find it hard to believe one repo can be
> hit buy *two* races occurring together!
Yeah, the race seems pretty unlikely (though it could be just the one
race with a rewind). As I said, I haven't actually ever seen it in
practice. In my experience, though, disk/fs issues do not manifest as
just missing objects, but as corrupted packfiles (e.g., the packfile
directory entry ends up pointing to the wrong inode, which is easy to
see because the inode's content is actually a reflog). And then of
course with the packfile unreadable, you have missing objects. But YMMV,
depending on the fs and what's happened to the machine to cause the fs
problem.
-Peff
^ permalink raw reply
* [PATCH] Support FTP-over-SSL/TLS for regular FTP
From: Modestas Vainius @ 2013-01-12 13:59 UTC (permalink / raw)
To: git; +Cc: Modestas Vainius
Add a boolean http.sslTry option which allows to enable AUTH SSL/TLS and
encrypted data transfers when connecting via regular FTP protocol.
Default is false since it might trigger certificate verification errors on
misconfigured servers.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
---
Documentation/config.txt | 8 ++++++++
http.c | 10 ++++++++++
http.h | 9 +++++++++
3 files changed, 27 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d5809e0..1abd161 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1406,6 +1406,14 @@ http.sslCAPath::
with when fetching or pushing over HTTPS. Can be overridden
by the 'GIT_SSL_CAPATH' environment variable.
+http.sslTry::
+ Attempt to use AUTH SSL/TLS and encrypted data transfers
+ when connecting via regular FTP protocol. This might be needed
+ if the FTP server requires it for security reasons or you wish
+ to connect securely whenever remote FTP server supports it.
+ Default is false since it might trigger certificate verification
+ errors on misconfigured servers.
+
http.maxRequests::
How many HTTP requests to launch in parallel. Can be overridden
by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
diff --git a/http.c b/http.c
index 44f3525..d49a3d4 100644
--- a/http.c
+++ b/http.c
@@ -30,6 +30,7 @@ static CURL *curl_default;
char curl_errorstr[CURL_ERROR_SIZE];
static int curl_ssl_verify = -1;
+static int curl_ssl_try;
static const char *ssl_cert;
#if LIBCURL_VERSION_NUM >= 0x070903
static const char *ssl_key;
@@ -162,6 +163,10 @@ static int http_options(const char *var, const char *value, void *cb)
ssl_cert_password_required = 1;
return 0;
}
+ if (!strcmp("http.ssltry", var)) {
+ curl_ssl_try = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp("http.minsessions", var)) {
min_curl_sessions = git_config_int(var, value);
#ifndef USE_CURL_MULTI
@@ -306,6 +311,11 @@ static CURL *get_curl_handle(void)
if (curl_ftp_no_epsv)
curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
+#ifdef CURLOPT_USE_SSL
+ if (curl_ssl_try)
+ curl_easy_setopt(result, CURLOPT_USE_SSL, CURLUSESSL_TRY);
+#endif
+
if (curl_http_proxy) {
curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
diff --git a/http.h b/http.h
index 0a80d30..f861662 100644
--- a/http.h
+++ b/http.h
@@ -42,6 +42,15 @@
#define NO_CURL_IOCTL
#endif
+/*
+ * CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4,
+ * and the constants were known as CURLFTPSSL_*
+*/
+#if !defined(CURLOPT_USE_SSL) && defined(CURLOPT_FTP_SSL)
+#define CURLOPT_USE_SSL CURLOPT_FTP_SSL
+#define CURLUSESSL_TRY CURLFTPSSL_TRY
+#endif
+
struct slot_results {
CURLcode curl_result;
long http_code;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] Support FTP-over-SSL/TLS for regular FTP
From: Matt Kraai @ 2013-01-12 14:25 UTC (permalink / raw)
To: Modestas Vainius; +Cc: git
In-Reply-To: <1357999192-877-1-git-send-email-modestas@vainius.eu>
On Sat, Jan 12, 2013 at 03:59:52PM +0200, Modestas Vainius wrote:
> @@ -306,6 +311,11 @@ static CURL *get_curl_handle(void)
> if (curl_ftp_no_epsv)
> curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
>
> +#ifdef CURLOPT_USE_SSL
> + if (curl_ssl_try)
> + curl_easy_setopt(result, CURLOPT_USE_SSL, CURLUSESSL_TRY);
> +#endif
> +
> if (curl_http_proxy) {
> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
It looks like the indentation of the "if" line you added is messed up.
^ permalink raw reply
* How to setup bash completion for alias of git command
From: Ping Yin @ 2013-01-12 14:30 UTC (permalink / raw)
To: git mailing list
Following setup works for me in ubuntu (10.04,11.04) for a long time
alias gtlg='git log'
complete -o default -o nospace -F _git_log gtlg
However, in debian (testing, wheezy), it doesn't work
$ gtlg or<TAB>
gtlg or-bash: [: 1: unary operator expected
-bash: [: 1: unary operator expected
$ git --version
git version 1.7.10
Can anybody help?
^ permalink raw reply
* Re: [PATCH] Support FTP-over-SSL/TLS for regular FTP
From: Modestas Vainius @ 2013-01-12 14:51 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20130112142521.GA21639@ftbfs.org>
Hello,
Saturday 12 January 2013 06:25:21 rašė:
> On Sat, Jan 12, 2013 at 03:59:52PM +0200, Modestas Vainius wrote:
> > @@ -306,6 +311,11 @@ static CURL *get_curl_handle(void)
> >
> > if (curl_ftp_no_epsv)
> >
> > curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
> >
> > +#ifdef CURLOPT_USE_SSL
> > + if (curl_ssl_try)
> > + curl_easy_setopt(result, CURLOPT_USE_SSL, CURLUSESSL_TRY);
> > +#endif
> > +
> >
> > if (curl_http_proxy) {
> >
> > curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
> > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>
> It looks like the indentation of the "if" line you added is messed up.
Yeah, sorry about that. I will fix it.
--
Modestas Vainius <modestas@vainius.eu>
^ permalink raw reply
* Re: [PATCH v5] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-12 14:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, szeder, felipe.contreras, peff
In-Reply-To: <7v8v7zbcoi.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 11/01/2013 23:02, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> +# Process path list returned by "ls-files" and "diff-index --name-only"
>> +# commands, in order to list only file names relative to a specified
>> +# directory, and append a slash to directory names.
>> +__git_index_file_list_filter ()
>> +{
>> + # Default to Bash >= 4.x
>> + __git_index_file_list_filter_bash
>> +}
>> +
>> +# Execute git ls-files, returning paths relative to the directory
>> +# specified in the first argument, and using the options specified in
>> +# the second argument.
>> +__git_ls_files_helper ()
>> +{
>> + # NOTE: $2 is not quoted in order to support multiple options
>> + cd "$1" && git ls-files --exclude-standard $2
>> +} 2>/dev/null
>
> I think this redirection is correct but a bit tricky;
It's not tricky: it is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10
> it is in
> effect during the execution of the { block } (in other words, it is
> not about squelching errors during the function definition).
>
What do you mean by "squelching"?
Note that I originally wrote the code as
__git_ls_files_helper ()
{
# NOTE: $2 is not quoted in order to support multiple options
{ cd "$1" && git ls-files --exclude-standard $2 } 2>/dev/null
}
but then I checked the POSIX standard, noting that it is redundant.
> -- >8 --
> #!/bin/sh
> cat >t.sh <<\EOF &&
> echo I am "$1"
> t () { echo "Goes to stdout"; echo >&2 "Goes to stderr"; } 2>/dev/null
> t
> for sh in bash dash ksh zsh
> do
> $sh t.sh $sh
> done
> -- 8< --
>
There is a missing EOF delimiter.
And I'm not sure to understand the meaning of && after EOF.
> Bash does (so do dash and real AT&T ksh) grok this correctly, but
> zsh does not seem to (I tried zsh 4.3.10 and 4.3.17; also zsh
> pretending to be ksh gets this wrong as well). Not that what ksh
> does matters, as it won't be dot-sourcing bash completion script.
>
I have added tcsh to the sh list, but it fails with:
Badly placed ()'s.
> It however may affect zsh, which does seem to dot-source this file.
> Perhaps zsh completion may have to be rewritten in a similar way as
> tcsh completion is done (i.e. does not dot-source this file but ask
> bash to do the heavy-lifting).
>
Ok, I was wrong on assuming all modern shells were POSIX compliant.
I will change the code to use a nested {} group.
> This function seems to be always called in an subshell (e.g. as an
> upstream of a pipeline), so the "cd" may be harmless, but don't you
> need to disable CDPATH while doing this?
>
I don't know.
> [..]
>> +# Try to count non option arguments passed on the command line for the
>> +# specified git command.
>> +# When options are used, it is necessary to use the special -- option to
>> +# tell the implementation were non option arguments begin.
>> +# XXX this can not be improved, since options can appear everywhere, as
>> +# an example:
>> +# git mv x -n y
>
> If that is the case, it is a bug in the command line parser, I
> think. We should reject it, and the command line completer
> certainly should not encourage it.
>
$ mkdir y
$ git mv x -n y
Checking rename of 'x' to 'y/x'
Renaming x to y/x
$ git status
# On branch master
nothing to commit, working directory clean
I was assuming it to be "normal", given how complex Git command line
parsing is (IMHO).
Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDxeMgACgkQscQJ24LbaUTmaQCeMbZ0lRJxZIx3U31gMPmcqTLp
54sAmwYrjJVuvRYcsbGaMa3rb9/EKrBU
=ky30
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Michael Haggerty @ 2013-01-12 15:13 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Junio C Hamano, git, Chris Rorvick
In-Reply-To: <1357875152-19899-1-git-send-email-gitster@pobox.com>
On 01/11/2013 04:32 AM, Junio C Hamano wrote:
> From: "Eric S. Raymond" <esr@thyrsus.com>
>
> The combination of git-cvsimport and cvsps had serious problems.
Agreed.
> [...]
> This patch also removes Michael Haggerty's git-cvsimport tests
> (t960[123]) from the git tree. These are actually conversion-engine
> tests and have been merged into a larger cvsps test suite, which I
> intend to spin out into a general CVS-lifting test that can also be
> applied to utilities such as cvs2git and parsecvs. The t9604 test
> will move in a future patch, when I likewise have it integrated
> into the general test suite.
>
> The following known bug has not been fixed: "If any files were ever
> "cvs import"ed more than once (e.g., import of more than one vendor
> release) the HEAD contains the wrong content." However, cvsps now
> emits a warning in this case. There is also one pathological tagging
> case that was successful in the former t9602 test that now fails
> (with a warning).
>
> I plan to address these problems. This patch at least gets the
> cvsps-3.x/git-cvsimport combination to a state that is not too
> broken to ship - that is, in all failure cases known to me it
> now emits useful warnings rather than silently botching the
> import.
I don't understand the logic of removing the cvsimport tests, at least
not at this time. It is true that the tests mostly ensure that the
conversion engine is working correctly, especially with your new version
of cvsps. But I think the git project, by implicitly endorsing the use
of cvsps, has some responsibility to verify that the combination cvsps +
git-cvsimport continues to work and to document any known breakages via
its test suite.
Otherwise, how do we know that cvsps currently works with git-cvsimport?
(OK, you claim that it does, but in the next breath you admit that
there is a new failure in "one pathological tagging case".) How can we
understand its strengths/weaknesses? How can we gain confidence that it
works on different platforms? How will we find out if a future versions
of cvsps stops working (e.g., because of a breakage or a
non-backwards-compatible change)?
Normally one would expect an improvement like this to be combined with
patches that turn test expected failures into expected successes, not to
rip out the very tests that establish the correctness of the change that
is being proposed!
Let me describe what I would consider to be the optimum state of the
test suite. Maybe your idea of "optimum" differs from mine, or maybe
the optimum is unrealistic due to lack of resources or for some other
reason. But if so, let's explicitly spell out why we are deviating from
whatever optimum we define.
* The old tests should be retained (and possibly new tests added to show
off your improvements).
* There should be a way for users to choose which cvsps executable to
use when running test suite. (In the future, the selection might be
expanded to cover altogether different conversion engines.)
* The tests should determine which version of cvsps has been selected
(e.g., by running "cvsps --version").
* The individual tests should be marked expected success/expected
failure based on the selected version of cvsps; in other words, some
tests might be marked "expected failure" if cvsps 2.x is being used but
"expected success" if cvsps 3.x is being used.
Regarding your claim that "within a few months the Perl git-cvsimport is
going to cease even pretending to work": It might be that the old
git-cvsimport will stop working *for people who upgrade to cvsps 3.x*.
But it is not realistic to expect people to synchronize their git and
cvsps version upgrades. It is even quite possible that this or that
Linux distribution will package incompatible versions of the two packages.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] t/lib-cvs: cvsimport no longer works without Python >= 2.7
From: Michael Haggerty @ 2013-01-12 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric S. Raymond, git
In-Reply-To: <7vip72iykx.fsf_-_@alter.siamese.dyndns.org>
I have the feeling I'm only seeing one side of this conversation...
On 01/12/2013 09:40 AM, Junio C Hamano wrote:
> The new cvsimport requires at least Python 2.7 to work; do not fail
> the cvsimport tests on platforms without one.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > http://docs.python.org/2/library/subprocess.html tells me that
> > check_output has first become available in 2.7.
> >
> > So... does this mean that we now set the minimum required version of
> > Python to 2.7? I dunno.
It would be unfortunate to set the minimum Python version to 2.7 if "git
cvsimport" is considered an integral part of git.
> Even if we were to rip out the fallback code that uses the 2.7-only
> subprocess.check_output() on "cvsps -V", the function is also used
> for doing the real work interacting with cvsps-3.x, so I think this
> patch will be necessary. Unless new cvsimport is tweaked not to
> use the method, that is.
>
> A suggestion for a better alternative is of course very much
> appreciated.
If the only reason to require Python 2.7 is subprocess.check_output(),
it would be easy to reimplement it (it is only 12 lines of
straightforward code, plus a few lines to define the exception type
CalledProcessError). According to [1], the Python license is
GPL-compatible; therefore these lines could even be copied into
git-cvsimport.
Michael
[1] http://www.gnu.org/licenses/license-list.html#Python
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Eric S. Raymond @ 2013-01-12 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62339du4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> And here is what I got:
Hm. In my version of these tests, I only have one regression from the
old combo (in the pathological tags test, t9602). You're seeing more
breakage than that, obviously.
> A funny thing was that without cvsps-3.7 on $PATH (which means I am
> getting distro packaged cvsps 2.1), I got identical errors.
That suggests that something in your test setup has gone bad and is
introducing spurious errors. Which would be consistent with the above.
> Looking
> at the log message, it seems that you meant to remove t960[123], so
> perhaps the patch simply forgot to remove 9601 and 9602?
Yes.
> As neither test runs "git cvsimport" with -o/-m/-M options, ideally
> we should be able to pass them with and without having cvsps-3.x.
> Not passing them without cvsps-3.x would mean that the fallback mode
> of rewritten cvsimport is not working as expected. Not passing them
> with cvsps-3.x may mean the tests were expecting a wrong conversion
> result, or they uncover bugs in the replacement cvsimport.
That's possible, but seems unlikely. Because the new cvsimport is
such a thin wrapper around the conversion engine, bugs in it should
lead to obvious crashes or failure to run the engine rather than the
sort of conversion error the t960* tests are designed to check. Really
all it does is assemble options to pass to the conversion engines.
My test strategy is aimed at the engine, not the wrapper. I took the
repos from t960* and wrote a small Python framework to check the same
assertions as the git-tree tests do, but using the engine. For example,
here's how my t9602 looks:
import os, cvspstest
cc = cvspstest.ConvertComparison("t9602", "module")
cc.cmp_branch_tree("test of branch", "master", True)
cc.cmp_branch_tree("test of branch", "vendorbranch", True)
cc.cmp_branch_tree("test of branch", "B_FROM_INITIALS", False)
cc.cmp_branch_tree("test of branch", "B_FROM_INITIALS_BUT_ONE", False)
cc.cmp_branch_tree("test of branch", "B_MIXED", False)
cc.cmp_branch_tree("test of branch", "B_SPLIT", True)
cc.cmp_branch_tree("test of tag", "vendortag", False)
# This is the only test new cvsps fails that old git-cvsimport passed.
cc.cmp_branch_tree("test of tag", "T_ALL_INITIAL_FILES", True)
cc.cmp_branch_tree("test of tag", "T_ALL_INITIAL_FILES_BUT_ONE", False)
cc.cmp_branch_tree("test of tag", "T_MIXED", False)
cc.cleanup()
> t9600 fails with "-a is no longer supported", even without having
> cvsps-3.x on the $PATH (i.e. attempting to use the fallback). I
> wonder if this is an option the updated cvsimport would want to
> simply ignore?
Probably. But I don't think you should keep these tests in the git tree.
That wasn't a great idea even when you were supporting just one engine;
with two (and soon three) it's going to be just silly. Let sanity-checking
the engines be *my* problem, since I have to do it anyway.
(I'm working towards the generalized test suite as fast as I can. First
results probably in four days or so.)
> It is a way to tell the old cvsps/cvsimport to disable its
> heuristics to ignore commits made within the last 10 minutes (this
> is done in the hope of waiting for the per-file nature of CVS
> commits to stabilize, IIUC); the user tells the command that he
> knows that the CVS repository is now quiescent and it is safe to
> import the whole thing.
Yes, that's just what -a is supposed to do. But is should be
irrelevant for testing - in the test framework CVS is running locally,
so there's no network lag.
> So... does this mean that we now set the minimum required version of
> Python to 2.7? I dunno.
That would be bad, IMO. I'll put backporting to 2.6 high on my to-do list.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH 2/3] config: Introduce diff.algorithm variable
From: Michal Privoznik @ 2013-01-12 16:02 UTC (permalink / raw)
To: git; +Cc: peff, trast
In-Reply-To: <cover.1358006339.git.mprivozn@redhat.com>
Some users or projects prefer different algorithms over others, e.g.
patience over myers or similar. However, specifying appropriate
argument every time diff is to be used is impractical. Moreover,
creating an alias doesn't play nicely with other tools based on diff
(git-show for instance). Hence, a configuration variable which is able
to set specific algorithm is needed. For now, these four values are
accepted: 'myers' (which has the same effect as not setting the config
variable at all), 'minimal', 'patience' and 'histogram'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
Documentation/diff-config.txt | 17 +++++++++++++++++
contrib/completion/git-completion.bash | 1 +
diff.c | 23 +++++++++++++++++++++++
3 files changed, 41 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..be31276 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -155,3 +155,20 @@ diff.tool::
"kompare". Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.<tool>.cmd`
option.
+
+diff.algorithm::
+ Choose a diff algorithm. The variants are as follows:
++
+--
+`myers`;;
+ The basic greedy diff algorithm.
+`minimal`;;
+ Spend extra time to make sure the smallest possible diff is
+ produced.
+`patience`;;
+ Use "patience diff" algorithm when generating patches.
+`histogram`;;
+ This algorithm extends the patience algorithm to "support
+ low-occurrence common elements".
+--
++
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 383518c..33e25dc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1839,6 +1839,7 @@ _git_config ()
diff.suppressBlankEmpty
diff.tool
diff.wordRegex
+ diff.algorithm
difftool.
difftool.prompt
fetch.recurseSubmodules
diff --git a/diff.c b/diff.c
index 732d4c2..ddae5c4 100644
--- a/diff.c
+++ b/diff.c
@@ -36,6 +36,7 @@ static int diff_no_prefix;
static int diff_stat_graph_width;
static int diff_dirstat_permille_default = 30;
static struct diff_options default_diff_options;
+static long diff_algorithm = 0;
static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -143,6 +144,20 @@ static int git_config_rename(const char *var, const char *value)
return git_config_bool(var,value) ? DIFF_DETECT_RENAME : 0;
}
+static long parse_algorithm_value(const char *value)
+{
+ if (!value || !strcasecmp(value, "myers"))
+ return 0;
+ else if (!strcasecmp(value, "minimal"))
+ return XDF_NEED_MINIMAL;
+ else if (!strcasecmp(value, "patience"))
+ return XDF_PATIENCE_DIFF;
+ else if (!strcasecmp(value, "histogram"))
+ return XDF_HISTOGRAM_DIFF;
+ else
+ return -1;
+}
+
/*
* These are to give UI layer defaults.
* The core-level commands such as git-diff-files should
@@ -196,6 +211,13 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "diff.algorithm")) {
+ diff_algorithm = parse_algorithm_value(value);
+ if (diff_algorithm < 0)
+ return -1;
+ return 0;
+ }
+
if (git_color_config(var, value, cb) < 0)
return -1;
@@ -3213,6 +3235,7 @@ void diff_setup(struct diff_options *options)
options->add_remove = diff_addremove;
options->use_color = diff_use_color_default;
options->detect_rename = diff_detect_rename_default;
+ options->xdl_opts |= diff_algorithm;
if (diff_no_prefix) {
options->a_prefix = options->b_prefix = "";
--
1.8.0.2
^ permalink raw reply related
* [PATCH 3/3] diff: Introduce --diff-algorithm command line option
From: Michal Privoznik @ 2013-01-12 16:02 UTC (permalink / raw)
To: git; +Cc: peff, trast
In-Reply-To: <cover.1358006339.git.mprivozn@redhat.com>
Since command line options have higher priority than config file
variables and taking previous commit into account, we need a way
how to specify myers algorithm on command line. However,
inventing `--myers` is not the right answer. We need far more
general option, and that is `--diff-algorithm`. The older options
(`--minimal`, `--patience` and `--histogram`) are kept for
backward compatibility.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
Documentation/diff-options.txt | 22 ++++++++++++++++++++++
contrib/completion/git-completion.bash | 11 +++++++++++
diff.c | 12 +++++++++++-
diff.h | 2 ++
merge-recursive.c | 6 ++++++
5 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 39f2c50..4091f52 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -45,6 +45,9 @@ ifndef::git-format-patch[]
Synonym for `-p --raw`.
endif::git-format-patch[]
+The next three options are kept for compatibility reason. You should use the
+`--diff-algorithm` option instead.
+
--minimal::
Spend extra time to make sure the smallest possible
diff is produced.
@@ -55,6 +58,25 @@ endif::git-format-patch[]
--histogram::
Generate a diff using the "histogram diff" algorithm.
+--diff-algorithm={patience|minimal|histogram|myers}::
+ Choose a diff algorithm. The variants are as follows:
++
+--
+`myers`;;
+ The basic greedy diff algorithm.
+`minimal`;;
+ Spend extra time to make sure the smallest possible diff is
+ produced.
+`patience`;;
+ Use "patience diff" algorithm when generating patches.
+`histogram`;;
+ This algorithm extends the patience algorithm to "support
+ low-occurrence common elements".
+--
++
+You should prefer this option over the `--minimal`, `--patience` and
+`--histogram` which are kept just for backwards compatibility.
+
--stat[=<width>[,<name-width>[,<count>]]]::
Generate a diffstat. By default, as much space as necessary
will be used for the filename part, and the rest for the graph
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 33e25dc..d592cf9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1021,6 +1021,8 @@ _git_describe ()
__gitcomp_nl "$(__git_refs)"
}
+__git_diff_algorithms="myers minimal patience histogram"
+
__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
@@ -1035,6 +1037,7 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--raw
--dirstat --dirstat= --dirstat-by-file
--dirstat-by-file= --cumulative
+ --diff-algorithm=
"
_git_diff ()
@@ -1042,6 +1045,10 @@ _git_diff ()
__git_has_doubledash && return
case "$cur" in
+ --diff-algorithm=*)
+ __gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
+ return
+ ;;
--*)
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
--base --ours --theirs --no-index
@@ -2114,6 +2121,10 @@ _git_show ()
" "" "${cur#*=}"
return
;;
+ --diff-algorithm=*)
+ __gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
+ return
+ ;;
--*)
__gitcomp "--pretty= --format= --abbrev-commit --oneline
$__git_diff_common_options
diff --git a/diff.c b/diff.c
index ddae5c4..6418076 100644
--- a/diff.c
+++ b/diff.c
@@ -144,7 +144,7 @@ static int git_config_rename(const char *var, const char *value)
return git_config_bool(var,value) ? DIFF_DETECT_RENAME : 0;
}
-static long parse_algorithm_value(const char *value)
+long parse_algorithm_value(const char *value)
{
if (!value || !strcasecmp(value, "myers"))
return 0;
@@ -3633,6 +3633,16 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
else if (!strcmp(arg, "--histogram"))
options->xdl_opts = DIFF_WITH_ALG(options, HISTOGRAM_DIFF);
+ else if (!prefixcmp(arg, "--diff-algorithm=")) {
+ long value = parse_algorithm_value(arg+17);
+ if (value < 0)
+ return error("option diff-algorithm accepts \"myers\", "
+ "\"minimal\", \"patience\" and \"histogram\"");
+ /* clear out previous settings */
+ DIFF_XDL_CLR(options, NEED_MINIMAL);
+ options->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK;
+ options->xdl_opts |= value;
+ }
/* flags options */
else if (!strcmp(arg, "--binary")) {
diff --git a/diff.h b/diff.h
index a47bae4..54c2590 100644
--- a/diff.h
+++ b/diff.h
@@ -333,6 +333,8 @@ extern struct userdiff_driver *get_textconv(struct diff_filespec *one);
extern int parse_rename_score(const char **cp_p);
+extern long parse_algorithm_value(const char *value);
+
extern int print_stat_summary(FILE *fp, int files,
int insertions, int deletions);
extern void setup_diff_pager(struct diff_options *);
diff --git a/merge-recursive.c b/merge-recursive.c
index d882060..53d8feb 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2068,6 +2068,12 @@ int parse_merge_opt(struct merge_options *o, const char *s)
o->xdl_opts = DIFF_WITH_ALG(o, PATIENCE_DIFF);
else if (!strcmp(s, "histogram"))
o->xdl_opts = DIFF_WITH_ALG(o, HISTOGRAM_DIFF);
+ else if (!strcmp(s, "diff-algorithm=")) {
+ long value = parse_algorithm_value(s+15);
+ if (value < 0)
+ return -1;
+ o->xdl_opts |= value;
+ }
else if (!strcmp(s, "ignore-space-change"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
else if (!strcmp(s, "ignore-all-space"))
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Eric S. Raymond @ 2013-01-12 16:11 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Chris Rorvick
In-Reply-To: <50F17DB0.2050802@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> Otherwise, how do we know that cvsps currently works with git-cvsimport?
> (OK, you claim that it does, but in the next breath you admit that
> there is a new failure in "one pathological tagging case".) How can we
> understand its strengths/weaknesses? How can we gain confidence that it
> works on different platforms? How will we find out if a future versions
> of cvsps stops working (e.g., because of a breakage or a
> non-backwards-compatible change)?
You can't. But in practice the git crew was going to lose that
capability anyway simply because the new wrapper will support three
engines rather than just one. It's not practical for the git tests to
handle that many variant external dependencies.
However, there is a solution.
The solution is for git to test that the wrapper is *generating the
expected commands*. So what the git tree ends up with is conditional
assurance; the wrapper will do the right thing if the engine it calls
is working correctly. I think that's really all the git-tree tests
can hope for.
Michael, the engines are my problem and yours - it's *our*
responsibility to develop a (hopefully shared) test suite to verify
that they convert repos correctly. I'm working my end as fast as I can;
I hope to have the test suite factored out of cvsps and ready to check
multiple engines by around Wednesday. I still need to convert t9604,
too.
I have parsecvs working since yesterday, so we really are up to three
engines.
I have two minor features I need to merge into parsecvs before
I can start on splitting out the test suite.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH 1/3] git-completion.bash: Autocomplete --minimal and --histogram for git-diff
From: Michal Privoznik @ 2013-01-12 16:02 UTC (permalink / raw)
To: git; +Cc: peff, trast
In-Reply-To: <cover.1358006339.git.mprivozn@redhat.com>
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..383518c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1031,7 +1031,7 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
--inter-hunk-context=
- --patience
+ --patience --histogram --minimal
--raw
--dirstat --dirstat= --dirstat-by-file
--dirstat-by-file= --cumulative
--
1.8.0.2
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2013, #05; Fri, 11)
From: Duy Nguyen @ 2013-01-12 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vip739su3.fsf@alter.siamese.dyndns.org>
On Sat, Jan 12, 2013 at 6:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/parse-pathspec (2013-01-11) 20 commits
>
> Uses the parsed pathspec structure in more places where we used to
> use the raw "array of strings" pathspec.
>
> Unfortunately, this conflicts a couple of topics in flight. I tried
> to be careful while resolving conflicts, though.
parse_pathspec has not picked up init_pathspec changes from
jk/pathspec-literal and nd/pathspec-wildcard (already in master) so
--literal-pathspecs is probably broken in 'pu' after a lot of
init_pathspec -> parse_pathspec conversion.
--
Duy
^ permalink raw reply
* [PATCH 0/3] Rework git-diff algorithm selection
From: Michal Privoznik @ 2013-01-12 16:02 UTC (permalink / raw)
To: git; +Cc: peff, trast
It's been a while I was trying to get this in. Recently, I realized how
important this is.
Please keep me CC'ed as I am not subscribed to the list.
Michal Privoznik (3):
git-completion.bash: Autocomplete --minimal and --histogram for
git-diff
config: Introduce diff.algorithm variable
diff: Introduce --diff-algorithm command line option
Documentation/diff-config.txt | 17 +++++++++++++++++
Documentation/diff-options.txt | 22 ++++++++++++++++++++++
contrib/completion/git-completion.bash | 14 +++++++++++++-
diff.c | 33 +++++++++++++++++++++++++++++++++
diff.h | 2 ++
merge-recursive.c | 6 ++++++
6 files changed, 93 insertions(+), 1 deletion(-)
--
1.8.0.2
^ permalink raw reply
* Re: Suggestion: add option in git-p4 to preserve user in Git repository
From: Pete Wyckoff @ 2013-01-12 16:38 UTC (permalink / raw)
To: Olivier Delalleau; +Cc: git, Luke Diamand
In-Reply-To: <CAFXk4bpQo26sAfHkE5_VLi_UkZcgsYvwYNH8byZjuXs=EAhu+A@mail.gmail.com>
shish@keba.be wrote on Thu, 10 Jan 2013 22:38 -0500:
> I'm in a situation where I don't have P4 admin rights to use the
> --preserve-user option of git-p4. However, I would like to keep user
> information in the associated Git branch.
>
> Would it be possible to add an option for this?
The --preserve-user option is used to submit somebody else's work
from git to p4. It does "p4 change -f" to edit the author of the
change after it has been submitted to p4. P4 requires admin
privileges to do that.
Changes that are imported _from_ p4 to git do have the correct
author information.
Can you explain a bit more what you're looking for?
-- Pete
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Jonathan Nieder @ 2013-01-12 18:16 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Michael Haggerty, Junio C Hamano, git, Chris Rorvick
In-Reply-To: <20130112161105.GB3270@thyrsus.com>
Hi Eric,
Eric S. Raymond wrote:
> But in practice the git crew was going to lose that
> capability anyway simply because the new wrapper will support three
> engines rather than just one. It's not practical for the git tests to
> handle that many variant external dependencies.
See the git-blame/git-annotate tests for an example of how the
testsuite handles "variations on a theme".
It works fine.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Jonathan Nieder @ 2013-01-12 18:26 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Eric S. Raymond, Junio C Hamano, git, Chris Rorvick
In-Reply-To: <50F17DB0.2050802@alum.mit.edu>
Michael Haggerty wrote:
> Regarding your claim that "within a few months the Perl git-cvsimport is
> going to cease even pretending to work": It might be that the old
> git-cvsimport will stop working *for people who upgrade to cvsps 3.x*.
> But it is not realistic to expect people to synchronize their git and
> cvsps version upgrades. It is even quite possible that this or that
> Linux distribution will package incompatible versions of the two packages.
Moreover, I feel an obligation to point the following out:
In a hypothetical world where cvsps 3.x simply breaks "git cvsimport"
it is likely that some distributions would just stick to the existing
cvsps and not upgrade to 3.x. Maybe that's a wrong choice, but that's
a choice some would make. An even more likely outcome in that
hypothetical world is that they would ship it renamed to something
like "cvsps3" alongside the existing cvsps. Or they could rename the
old version to "cvsps2". If we were the last holdout, we could even
bundle it as compat/cvsps.
So please do not act as though the cvsps upgrade is a crisis that we
need to break ourselves for at threat of no longer working at all.
The threat doesn't hold water.
Luckily you have already written patches to make "git cvsimport" work
with cvsps 3.x, and through your work you are making a better
argument: "The new cvsimport + cvsps will work better, at least for
some users, than the old tool."
Just don't pretend you have the power to force a change for a less
sensible reason than that!
Hope that helps,
Jonathan
^ permalink raw reply
* Re: erratic behavior commit --allow-empty
From: Jan Engelhardt @ 2013-01-12 18:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Angelo Borsotti, git
In-Reply-To: <506AA51E.9010209@viscovery.net>
On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
>
>Note that git commit -m A --allow-empty *DID* create a commit. Only, that
>it received the same name (SHA1) as the commit you created before it
>because it had the exact same contents (files, parents, author, committer,
>and timestamps). Obviously, your script was executed sufficiently fast
>that the two commits happend in the same second.
What about introducing nanosecond-granular timestamps into Git?
^ permalink raw reply
* git-completion.bash should not add a space after a ref
From: Manlio Perillo @ 2013-01-12 18:35 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: SZEDER Gábor, Felipe Contreras
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
This is not really a bug, but a small usability problem.
When completing a reference, Bash will add a space after the reference name.
As an example in:
$git show master<TAB>
The problem is that an user may want to show a tree or blog object from
master:
$git show master:git.c
A possible solution is to define a new __gitcomp_nospace function and
use it where appropriate.
Probably the __gitcomp_nospace should be used when git_complete_file is
called, and __gitcomp_nl should be used when __git_complete_revlist is
called, but I'm not sure.
P.S.:
it seems that __gitcomp_nl is **never** called with 4 arguments.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDxrQ8ACgkQscQJ24LbaURHmACfRXoM+uEVDgFUtZFzUcPC5oSZ
FGsAnAxQf+SN7GrNljxU1io4IuayHmed
=JRVU
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 0/8] Initial support for Python 3
From: John Keeping @ 2013-01-12 19:23 UTC (permalink / raw)
To: git; +Cc: John Keeping, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
I started having a look to see how much work would be needed to make Git
work with Python 3 and the answer is mostly not much. The exception is
git-p4.py which is hit hard by the distinction between byte strings and
unicode strings, particularly because the Python output mode of p4
targets Python 2.
I don't know if it's worthwhile to actually apply these but here they
are in case anyone's interested.
Having said that, the changes are minimal and involve either wrapping
parentheses around arguments to print or being a bit more explicit about
how we expect byte strings to be decoded to unicode.
With these patches all tests pass with python3 except t98* (git-p4), but
there are a couple of topics in-flight which will affect that
(fc/remote-testgit-feature-done and er/replace-cvsimport).
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 | 40 +++++++++++++++++++-------------------
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 10 ++++++++--
git_remote_helpers/git/importer.py | 2 +-
git_remote_helpers/setup.py | 10 ++++++++++
6 files changed, 42 insertions(+), 25 deletions(-)
--
1.8.1
^ permalink raw reply
* [PATCH 1/8] git_remote_helpers: Allow building with Python 3
From: John Keeping @ 2013-01-12 19:23 UTC (permalink / raw)
To: git; +Cc: John Keeping, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
In-Reply-To: <cover.1358018078.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH 2/8] git_remote_helpers: fix input when running under Python 3
From: John Keeping @ 2013-01-12 19:23 UTC (permalink / raw)
To: git; +Cc: John Keeping, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
In-Reply-To: <cover.1358018078.git.john@keeping.me.uk>
Although 2to3 will fix most issues in Python 2 code to make it run under
Python 3, it does not handle the new strict separation between byte
strings and unicode strings. There is one instance in
git_remote_helpers where we are caught by this.
Fix it by explicitly decoding the incoming byte string into a unicode
string. In this instance, use the locale under which the application is
running.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
git_remote_helpers/git/importer.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git_remote_helpers/git/importer.py b/git_remote_helpers/git/importer.py
index e28cc8f..6814003 100644
--- a/git_remote_helpers/git/importer.py
+++ b/git_remote_helpers/git/importer.py
@@ -20,7 +20,7 @@ class GitImporter(object):
"""Returns a dictionary with refs.
"""
args = ["git", "--git-dir=" + gitdir, "for-each-ref", "refs/heads"]
- lines = check_output(args).strip().split('\n')
+ lines = check_output(args).decode().strip().split('\n')
refs = {}
for line in lines:
value, name = line.split(' ')
--
1.8.1
^ permalink raw reply related
* [PATCH 3/8] git_remote_helpers: Force rebuild if python version changes
From: John Keeping @ 2013-01-12 19:23 UTC (permalink / raw)
To: git; +Cc: John Keeping, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
In-Reply-To: <cover.1358018078.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
* [PATCH 4/8] git_remote_helpers: Use 2to3 if building with Python 3
From: John Keeping @ 2013-01-12 19:23 UTC (permalink / raw)
To: git; +Cc: John Keeping, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
In-Reply-To: <cover.1358018078.git.john@keeping.me.uk>
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 <john@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
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox