* RE: Question re. git remote repository
From: David Lang @ 2013-01-17 23:19 UTC (permalink / raw)
To: Lang, David
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrUIr001039@smtpb01.one-mail.on.ca>
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:david@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.
>
>
^ permalink raw reply
* Re: git pull - reporting that I modified files, but I did not
From: Max Horn @ 2013-01-17 22:59 UTC (permalink / raw)
To: Jay Vee; +Cc: git
In-Reply-To: <CADq_mb-k8mP6PAsPciYEkx6fvFNdGK+ejsFEZ4nCJVcUQ6odGg@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 22:57 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117223050.GL4574@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
>> John Keeping <john@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 < 0x02000000:
>>>>> + # 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(
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Jean-Noël AVILA @ 2013-01-17 22:47 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Jeff King, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy
In-Reply-To: <50F64597.2070100@web.de>
Le mercredi 16 janvier 2013 07:15:51, Torsten Bögershausen a écrit :
> On 01/16/2013 12:24 AM, Jeff King wrote:
> > On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
> >> "Jean-Noël AVILA"<avila.jn@gmail.com> writes:
> >>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a
> >>> known issue?
> >>
> >> Which branch?
> >
> > t9902.10 is overly sensitive to extra git commands in your PATH, as well
> > as cruft in your build dir (especially if you have been building 'pu',
> > which has git-check-ignore). Try "make clean&& make test".
> >
> > -Peff
>
> This may help, or it may not.
>
> If there are other binaries like
> "git-check-email" or "git-check-ignore" in the PATH
> .....
>
> When you switch to a branch generating a file like
> git-check-ignore then "make clean" will know about it
> and will remove it.
> If you switch to master, then "make clean" will not remove it.
>
> What does "git status" say?
>
> We had a discussion about this some weeks ago, but never concluded.
>
> How about this:
> http://comments.gmane.org/gmane.comp.version-control.git/211907
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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <7v622vtplm.fsf@alter.siamese.dyndns.org>
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
> John Keeping <john@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 < 0x02000000:
>>>> + # 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(
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 22:24 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117210048.GI4574@serenity.lan>
John Keeping <john@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 < 0x02000000:
>> > + # 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(
^ permalink raw reply
* [PATCH] simplify-merges: drop merge from irrelevant side branch
From: Junio C Hamano @ 2013-01-17 22:23 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Phil Hord
In-Reply-To: <7vk3re0zyt.fsf@alter.siamese.dyndns.org>
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 <gitster@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
^ permalink raw reply related
* [PATCH] git-svn: teach find-rev to find near matches
From: John Keeping @ 2013-01-17 22:19 UTC (permalink / raw)
To: git; +Cc: Eric Wong
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 <john@keeping.me.uk>
---
Documentation/git-svn.txt | 10 ++++++++++
git-svn.perl | 12 ++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 69decb1..34d438b 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -346,6 +346,16 @@ Any other arguments are passed directly to 'git log'
corresponding git commit hash (this can optionally be followed by a
tree-ish to specify which branch should be searched). When given a
tree-ish, returns the corresponding SVN revision number.
++
+--before;;
+ Don't require an exact match if given an SVN revision, instead find
+ the commit corresponding to the state of the SVN repository (on the
+ current branch) at the specified revision.
++
+--after;;
+ Don't require an exact match if given an SVN revision; if there is
+ not an exact match return the closest match searching forward in the
+ history.
'set-tree'::
You should consider using 'dcommit' instead of this command.
diff --git a/git-svn.perl b/git-svn.perl
index bd5266c..d086694 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -114,6 +114,7 @@ my ($_stdin, $_help, $_edit,
$_message, $_file, $_branch_dest,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
+ $_before, $_after,
$_merge, $_strategy, $_preserve_merges, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
$_commit_url, $_tag, $_merge_info, $_interactive);
@@ -258,7 +259,8 @@ my %cmd = (
} ],
'find-rev' => [ \&cmd_find_rev,
"Translate between SVN revision numbers and tree-ish",
- {} ],
+ { 'before' => \$_before,
+ 'after' => \$_after } ],
'rebase' => [ \&cmd_rebase, "Fetch and rebase your working directory",
{ 'merge|m|M' => \$_merge,
'verbose|v' => \$_verbose,
@@ -1191,7 +1193,13 @@ sub cmd_find_rev {
"$head history\n";
}
my $desired_revision = substr($revision_or_hash, 1);
- $result = $gs->rev_map_get($desired_revision, $uuid);
+ if ($_before) {
+ $result = $gs->find_rev_before($desired_revision, 1);
+ } elsif ($_after) {
+ $result = $gs->find_rev_after($desired_revision, 1);
+ } else {
+ $result = $gs->rev_map_get($desired_revision, $uuid);
+ }
} else {
my (undef, $rev, undef) = cmt_metadata($revision_or_hash);
$result = $rev;
--
1.8.1.1
^ permalink raw reply related
* RE: Question re. git remote repository
From: Lang, David @ 2013-01-17 21:53 UTC (permalink / raw)
To: David Lang
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>
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:david@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.
^ permalink raw reply
* [PATCH] git-svn: do not escape certain characters in paths
From: Peter Wu @ 2013-01-17 22:07 UTC (permalink / raw)
To: git
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 <lekensteyn@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
^ permalink raw reply related
* Re: [PATCH 2/8] Add --unannotate
From: James Nylen @ 2013-01-17 21:07 UTC (permalink / raw)
To: greened; +Cc: Junio C Hamano, git
In-Reply-To: <87sj6kfsbz.fsf@waller.obbligato.org>
On Tue, Jan 1, 2013 at 5:31 PM, <greened@obbligato.org> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "David A. Greene" <greened@obbligato.org> writes:
>>
>>> From: James Nylen <jnylen@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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117210048.GI4574@serenity.lan>
On Thu, Jan 17, 2013 at 09:00:48PM +0000, John Keeping wrote:
> On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
>> John Keeping <john@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 <john@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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <7vtxqftulq.fsf@alter.siamese.dyndns.org>
On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
> John Keeping <john@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 <john@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.
> 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.
> 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?
You're right - I think we need to add ", errors='replace'" to the call
to encode.
> > 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 < 0x02000000:
> > + # 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(
^ permalink raw reply
* Re: [PATCH] Add --unannotate option to git-subtree
From: James Nylen @ 2013-01-17 20:56 UTC (permalink / raw)
To: greened; +Cc: git
In-Reply-To: <87a9st4sb8.fsf@waller.obbligato.org>
On Mon, Dec 31, 2012 at 8:15 PM, <greened@obbligato.org> wrote:
> James Nylen <jnylen@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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 20:43 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <7vtxqftulq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> John Keeping <john@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 <john@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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 20:36 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <66c42ff65eddde494f40d0a582e89a081b4ab8e8.1358448207.git.john@keeping.me.uk>
John Keeping <john@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 <john@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 < 0x02000000:
> + # 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(
^ permalink raw reply
* Re: Changing Spell checker under GIT
From: Jonathan Nieder @ 2013-01-17 20:17 UTC (permalink / raw)
To: Mike Hall; +Cc: git@vger.kernel.org, Pat Thoyts
In-Reply-To: <189327E1D7E3B64286ED8625AAEC642C08633B01@MDHQEXCH01.enginsol.com>
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
^ permalink raw reply
* git pull - reporting that I modified files, but I did not
From: Jay Vee @ 2013-01-17 19:29 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* Changing Spell checker under GIT
From: Mike Hall @ 2013-01-17 19:08 UTC (permalink / raw)
To: git@vger.kernel.org
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
^ permalink raw reply
* Re: [PATCH 2/3] Allow Git::get_tz_offset to properly handle DST boundary times
From: Junio C Hamano @ 2013-01-17 19:09 UTC (permalink / raw)
To: Ben Walton; +Cc: esr, git
In-Reply-To: <1358291405-10173-3-git-send-email-bdwalton@gmail.com>
Ben Walton <bdwalton@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 <bdwalton@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]);
> }
^ permalink raw reply
* [PATCH v2 8/8] git-remote-testpy: call print as a function
From: John Keeping @ 2013-01-17 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <cover.1358448207.git.john@keeping.me.uk>
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>
---
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
^ permalink raw reply related
* [PATCH v2 7/8] git-remote-testpy: don't do unbuffered text I/O
From: John Keeping @ 2013-01-17 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <cover.1358448207.git.john@keeping.me.uk>
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>
---
git-remote-testpy.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index f8dc196..bc5e3cf 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -154,7 +154,7 @@ def do_import(repo, args):
refs = [ref]
while True:
- line = sys.stdin.readline()
+ line = sys.stdin.readline().decode()
if line == '\n':
break
if not line.startswith('import '):
@@ -225,7 +225,7 @@ def read_one_line(repo):
line = sys.stdin.readline()
- cmdline = line
+ cmdline = line.decode()
if not cmdline:
warn("Unexpected EOF")
@@ -277,7 +277,7 @@ def main(args):
more = True
- sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
+ sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
while (more):
more = read_one_line(repo)
--
1.8.1.1.260.g99b33f4.dirty
^ permalink raw reply related
* [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <cover.1358448207.git.john@keeping.me.uk>
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 <john@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 < 0x02000000:
+ # 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
^ permalink raw reply related
* [PATCH v2 5/8] svn-fe: allow svnrdump_sim.py to run with Python 3
From: John Keeping @ 2013-01-17 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <cover.1358448207.git.john@keeping.me.uk>
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 <john@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 < 0x02040000:
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
^ permalink raw reply related
* [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: John Keeping @ 2013-01-17 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <cover.1358448207.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.1.260.g99b33f4.dirty
^ 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