On Fri, 18 Jan 2013, Matt Seitz wrote:
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang,
David [david.l...@uhn.ca]
The other David Lang (da...@lang.hm) believes that using "git push" using NFS or CIFS/SMB
may not be safe and reliable. Based on the following artic
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang,
David [david.l...@uhn.ca]
> I thought the idea was that each developer installed git locally on their
> machines
Yes.
> and (as needed) committed their changes to the master repository which
> resides externally t
On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter
>> environ
On Thu, Jan 17, 2013 at 10:53 AM, John Keeping wrote:
> [1] http://wiki.python.org/moin/PortingPythonToPy3k
This link seems dead.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Jeff King writes:
> However, if instead of the rule being "blobs on the remote side
> cannot be replaced", if it becomes "the old value on the remote
> side must be referenced by what we replace it with", that _is_
> something we can calculate reliably on the sending side. And that
> is logicall
In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a
seg fault. It's caused by git-svn trying to parse a large yaml file
(introduced in
https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540
) which encounters a perl regex stack overflow bug that was presen
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping wrote:
> -sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
> +sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
It is not immediately obvious why you would open stdin in rb mode,
please add a comment.
--
Cheers,
Sverre Rabbelier
--
To uns
Looks harmless enough.
Acked-by: Sverre Rabbelier
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping wrote:
> This is harmless in Python 2, which sees the parentheses as redundant
> grouping, but is required for Python 3. Since this is the only change
> required to make this script just run under
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King wrote:
> However, if instead of the rule being
> "blobs on the remote side cannot be replaced", if it becomes "the old
> value on the remote side must be referenced by what we replace it with",
> that _is_ something we can calculate reliably on the sendin
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote:
> I was referring to your concern about rejecting based on type. A push
> causing a reference to move (for example) from a commit to a blob is
> rejected as "already exists" with this patch. You emphatically state
> this is not OK an
John Keeping wrote:
> When a single SVN repository is split into multiple Git repositories
> many SVN revisions will exist in only one of the Git repositories
> created. For some projects the only way to build a working artifact is
> to check out corresponding versions of various repositories, wi
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes
Jonathan Nieder writes:
> Thoughts? Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
Yeah, it would be a robust alternative approach to verify that (1
Jean-Noël AVILA wrote:
> OK. I have installed practically everything related to git from the package
> manager and there is a git-checkout-branches utility available.
>
> That result defeats the purpose of the test. This needs a tighter environment
> to work whatever the configuration of the use
On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote:
> >>This one [1] for instance. I also recall seing people having other
> >>"mystical" problems with setups like this so I somehow developed an idea
> >>than having a repository on a networked drive is asking for troubles.
> >>Of course,
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 p
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 h
John Keeping writes:
> On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
>> John Keeping 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 p
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" writes:
> >>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a
> >>> known is
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
> John Keeping 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?
Eve
John Keeping 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(+)
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 his
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 thos
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 o
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
On Tue, Jan 1, 2013 at 5:31 PM, wrote:
> Junio C Hamano writes:
>
>> "David A. Greene" writes:
>>
>>> From: James Nylen
>>>
>>> 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
On Thu, Jan 17, 2013 at 09:00:48PM +, John Keeping wrote:
> On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> Under Python 3 'hasher.update(...)' must take a byte string and not a
>>> unicode string. Explicitly encode the argument to this method a
On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
> John Keeping 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
On Mon, Dec 31, 2012 at 8:15 PM, wrote:
> James Nylen 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 messag
Junio C Hamano writes:
> John Keeping 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
John Keeping 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 Keepi
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 check
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
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
Ben Walton 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
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 i
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
---
git-remote-testpy.py | 8 +
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: f
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
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
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
---
git_remote_helpers/setup.py | 10 +
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
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions(+),
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, which is when reading
refs from "git for-each-ref".
Fi
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
---
git_remote_helpers/Makefile | 2 +-
1 file changed, 1 inser
This series does enough so that everything except git-p4 runs under
Python 3.
As discussed with Pete, it may not make sense to change git-p4 to
support Python 3 until Perforce's Python output mode is changed. So
does it make sense to merge this now and say "use Python 2 if you want
git-p4"?
Chan
Sorry, I am in cygwin mode, and I had crossed wires in my head.
s/ProcessMon/strace/
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Maxime Boissonneault
> Sent: Thursday, January 17, 2013 11:41 AM
> To: Pyeron, Jason J CTR (US)
> C
On Thu, Jan 17, 2013 at 08:44:20AM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk,
>> which
>> I think is a legitimate warning - perhaps someone who understands integer
>> type
>> p
BTW, I think it has been addressed [1] by clang already and that would
explain why you don't have the warning when using clang trunk version.
[1]: http://llvm-reviews.chandlerc.com/D113
Antoine,
On Thu, Jan 17, 2013 at 5:44 PM, Linus Torvalds
wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keepi
On Thu, Jan 17, 2013 at 3:00 AM, John Keeping wrote:
>
> There's also a warning that triggers with clang 3.2 but not clang trunk, which
> I think is a legitimate warning - perhaps someone who understands integer type
> promotion better than me can explain why the code is OK (patch->score is
> decl
I don't know of any lustre filesystem that is used on Windows. Barely
anybody uses Windows in the HPC industry.
This is a Linux cluster.
Maxime Boissonneault
Le 2013-01-17 11:40, Pyeron, Jason J CTR (US) a écrit :
-Original Message-
From: Eric Chamberland
Sent: Thursday, January 17, 20
> -Original Message-
> From: Eric Chamberland
> Sent: Thursday, January 17, 2013 11:31 AM
>
> On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
> >> Anyone has a new idea?
> >
> > Did you try Jeff King's code to confirm his idea?
> >
> > Philippe
> >
>
> Yes I did, but it was running withou
On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
Anyone has a new idea?
Did you try Jeff King's code to confirm his idea?
Philippe
Yes I did, but it was running without any problem
I find that my test case is "simple" (fresh git clone then "git gc" in a
crontab), I bet anyone who has a
As a git noob I am having trouble understanding when to use which
commands. I have a repository (bare) on my Linux server. I also created
a build directory as a local repository. In my build script I do a 'git
pull' to make sure the build directory is up to date. No changes are
made to my source so
On Thu, Jan 17, 2013 at 12:59 AM, Junio C Hamano wrote:
> Chris Rorvick writes:
>
>> On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano wrote:
>>> It is fine when pushing into "refs/tags/" hierarchy. It is *NOT*
>>> OK if the type check does not satisfy this function. In that case,
>>> we do not
Hi!
I still have the corruption problems
We just compiled a git without threads to try... (by the way,
--without-pthreads doesn't work, you have to do a --disable-pthreads
instead).
And to remove the warnings about threads at "git gc" execution, I did a:
git config --local pack.threads
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~^~~~
combine-diff.c:1006:19: note: use array
On Thu, Jan 17, 2013 at 11:32:39AM +0100, Antoine Pelisse wrote:
> John, could you confirm that you trigger the -Wtautological-compare
> warning with your version of clang ?
Yes, the warning is still there with both 3.2 and a recent trunk build
but this patch squelches it.
> And that this patch m
John, could you confirm that you trigger the -Wtautological-compare
warning with your version of clang ?
And that this patch makes clang compilation warning-free (with the
very latest clang) ?
Cheers,
On Wed, Jan 16, 2013 at 11:47 PM, Antoine Pelisse wrote:
> Create a GREP_HEADER_FIELD_MIN so we
On Wed, Jan 16, 2013 at 07:01:37PM +, John Keeping wrote:
> On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote:
> > On Wed, Jan 16, 2013 at 06:22:40PM +, John Keeping wrote:
> >
> > Thanks for checking. I'd rather squelch the warning completely (as in my
> > re-post of Max's patch f
58 matches
Mail list logo
