On Wed, Jan 16, 2013 at 07:01:37PM +, John Keeping wrote:
On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote:
On Wed, Jan 16, 2013 at 06:22:40PM +, John Keeping wrote:
Thanks for checking. I'd rather squelch the warning completely (as in my
re-post of Max's patch from a
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
Hi!
I still have the corruption problems
We just compiled a git without threads to try... (by the way,
--without-pthreads doesn't work, you have to do a --disable-pthreads
instead).
And to remove the warnings about threads at git gc execution, I did a:
git config --local pack.threads 1
On Thu, Jan 17, 2013 at 12:59 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy
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
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
-Original Message-
From: Eric Chamberland
Sent: Thursday, January 17, 2013 11:31 AM
On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
Anyone has a new idea?
Did you try Jeff King's code to confirm his idea?
Philippe
Yes I did, but it was running without any problem
I 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,
On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote:
There's also a warning that triggers with clang 3.2 but not clang trunk, which
I think is a legitimate warning - perhaps someone who understands integer type
promotion better than me can explain why the code is OK
BTW, I think it has been addressed [1] by clang already and that would
explain why you don't have the warning when using clang trunk version.
[1]: http://llvm-reviews.chandlerc.com/D113
Antoine,
On Thu, Jan 17, 2013 at 5:44 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jan
On Thu, Jan 17, 2013 at 08:44:20AM -0800, Linus Torvalds wrote:
On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote:
There's also a warning that triggers with clang 3.2 but not clang trunk,
which
I think is a legitimate warning - perhaps someone who understands integer
Sorry, I am in cygwin mode, and I had crossed wires in my head.
s/ProcessMon/strace/
-Original Message-
From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
Behalf Of Maxime Boissonneault
Sent: Thursday, January 17, 2013 11:41 AM
To: Pyeron, Jason J CTR (US)
Cc:
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?
Change inline Python to call print as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/Makefile | 2 +-
1 file
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files
Using the approach detailed on the Python wiki[1], run 2to3 on the code
as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://wiki.python.org/moin/PortingPythonToPy3k
Signed-off-by: John Keeping j...@keeping.me.uk
---
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+),
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Signed-off-by: John Keeping j...@keeping.me.uk
---
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
Ben Walton bdwal...@gmail.com writes:
The Git::get_tz_offset is meant to provide a workalike replacement for
the GNU strftime %z format specifier. The algorithm used failed to
properly handle DST boundary cases.
For example, the unix time 1162105199 in CST6CDT saw set_tz_offset
improperly
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
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
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.
John Keeping j...@keeping.me.uk writes:
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Junio C Hamano gits...@pobox.com writes:
John Keeping j...@keeping.me.uk writes:
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required
On Mon, Dec 31, 2012 at 8:15 PM, gree...@obbligato.org wrote:
James Nylen jny...@gmail.com writes:
Rather than adding a marker to each commit when splitting out the
commits back to the subproject, --unannotate removes the specified
string (or bash glob pattern) from the beginning of the
On Thu, Jan 17, 2013 at 09:00:48PM +, John Keeping wrote:
On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this
On Tue, Jan 1, 2013 at 5:31 PM, gree...@obbligato.org wrote:
Junio C Hamano gits...@pobox.com writes:
David A. Greene gree...@obbligato.org writes:
From: James Nylen jny...@gmail.com
Teach git-subtree about --unannotate. This option strips a prefix
from a commit message when doing a
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
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
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
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue, no?
git-remote-testpy.py | 8
1 file changed, 4
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue,
John Keeping j...@keeping.me.uk writes:
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
You're right - I think we need to add , errors='replace' to the call
to encode.
Of if it is used just as a opaque token, you can .encode('hex')
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
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
On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote:
This one [1] for instance. I also recall seing people having other
mystical problems with setups like this so I somehow developed an idea
than having a repository on a networked drive is asking for troubles.
Of course, if there are
Jean-Noël AVILA wrote:
OK. I have installed practically everything related to git from the package
manager and there is a git-checkout-branches utility available.
That result defeats the purpose of the test. This needs a tighter environment
to work whatever the configuration of the user
Jonathan Nieder jrnie...@gmail.com writes:
Thoughts? Maybe it would be enough to check that the intended get
commands are present in the completion list and other git commands are
not, ignoring binaries that might live elsewhere on the $PATH?
Yeah, it would be a robust alternative approach
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
John Keeping j...@keeping.me.uk wrote:
When a single SVN repository is split into multiple Git repositories
many SVN revisions will exist in only one of the Git repositories
created. For some projects the only way to build a working artifact is
to check out corresponding versions of various
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote:
I was referring to your concern about rejecting based on type. A push
causing a reference to move (for example) from a commit to a blob is
rejected as already exists with this patch. You emphatically state
this is not OK and
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote:
However, if instead of the rule being
blobs on the remote side cannot be replaced, if it becomes the old
value on the remote side must be referenced by what we replace it with,
that _is_ something we can calculate reliably on the
Looks harmless enough.
Acked-by: Sverre Rabbelier srabbel...@gmail.com
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping j...@keeping.me.uk wrote:
This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3. Since this is the only change
required
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping j...@keeping.me.uk wrote:
-sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
+sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
It is not immediately obvious why you would open stdin in rb mode,
please add a comment.
--
Cheers,
Sverre
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
Jeff King p...@peff.net writes:
However, if instead of the rule being blobs on the remote side
cannot be replaced, if it becomes the old value on the remote
side must be referenced by what we replace it with, that _is_
something we can calculate reliably on the sending side. And that
is
On Thu, Jan 17, 2013 at 10:53 AM, John Keeping j...@keeping.me.uk wrote:
[1] http://wiki.python.org/moin/PortingPythonToPy3k
This link seems dead.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
On 18.01.13 01:04, Jonathan Nieder wrote:
Jean-Noël AVILA wrote:
OK. I have installed practically everything related to git from the package
manager and there is a git-checkout-branches utility available.
That result defeats the purpose of the test. This needs a tighter
environment
to
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang,
David [david.l...@uhn.ca]
I thought the idea was that each developer installed git locally on their
machines
Yes.
and (as needed) committed their changes to the master repository which
resides externally to
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
51 matches
Mail list logo
