On Tue, Oct 30, 2012 at 7:00 PM, Chris Webb ch...@arachsys.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Yes, it seems this is an API issue; repo.branchtip doesn't exist in
python 2.2.
Hi. Presumably this is a problem with old mercurial not a problem with old
python as
On Wed, Oct 31, 2012 at 10:10:24AM -0400, Jeff King wrote:
On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote:
covers the basics (current behavior and intent of the change) in its
first two paragraphs and anyone wanting more detail can use
Hi,
v1 is here:
http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
I've fixed the issues pointed out in the review by Jens.
Sorry about the delay; need to find a new dayjob.
Ramkumar Ramachandra (3):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.driver.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
builtin/diff.c
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1
On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
I forgot to mention that I am using scm manager:
https://bitbucket.org/sdorra/scm-manager/wiki/Home
So that maybe the custom layer you are talking about.
Yeah, that is very important. If I am reading the scm-manager code right
Am 01.11.2012 03:58, schrieb Felipe Contreras:
On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote:
Johannes Schindelin johannes.schinde...@gmx.de wrote:
On Wed, 31 Oct 2012, Felipe Contreras wrote:
It doesn't get any more obvious than that. But to each his own.
In my
On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Also, and I'm sure you didn't know that, Jedem das Seine (to each his own)
was the slogan of the Buchenwald concentration camp. For that reason some
(including me) hear the unspoken cynical half-sentence and some
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
You probably didn't intend it, but your sentences at the top can be read
more like: This is a logical consequence. If you don't understand that,
your mental capabilities must be lacking.. That's obviously (ha!) a
On Thu, Nov 1, 2012 at 2:46 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 01.11.2012 03:58, schrieb Felipe Contreras:
On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano gits...@pobox.com wrote:
Johannes Schindelin johannes.schinde...@gmx.de wrote:
On Wed, 31 Oct 2012, Felipe Contreras
Felipe,
I'll invite you to reread some of your words:
That being said, I did wonder what must be going through his mind to
not see that as obvious,
(...)
Following the guideline of always assuming good faith
So perhaps it does apply that you could try to assume good
intellectual faith in
Hi Peff,
thanks for this information.
I will report the issue to scm-manager. In the meantime I will try to
use ssh protocol to connect to my remote server.
Thanks again,
Kevin
2012/11/1 Jeff King p...@peff.net:
On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
I forgot to
On Thu, Nov 1, 2012 at 3:47 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
Felipe,
I'll invite you to reread some of your words:
That being said, I did wonder what must be going through his mind to
not see that as obvious,
(...)
Following the guideline of always assuming good faith
Hi,
On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote:
Hi,
Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
However, that line turns out to be longer than 72 characters, and the
Jeff King wrote:
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--
[snip]
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows cvsimport to read per-author timezone from the author
Jeff King wrote:
Thinking on it more, my patch, hacky thought it seems, may not be the
worst solution. Here are the options that I see:
1. Use a regex library that does not require NUL termination. If we
are bound by the regular regexec interface, this is not feasible.
But the
When we use git on a network filesystem, occasionally and sporadically
we will see the following from a git checkout command:
error: git checkout-index: unable to create file foo (File exists)
Through a very basic grepping and following of the source it seems that
the core of the error message
Junio C Hamano wrote:
We've been hoping we can do without a rigid code of conduct written
down to maintain cordial community focused on technical merits, and
instead relied on people's common sense, but sense may not be so
common, unfortunately, so we may have to have one.
I think that
On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam tho...@xteddy.org wrote:
Hi,
On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote:
Hi,
Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra:
Hi,
v1 is here:
http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
I've fixed the issues pointed out in the review by Jens.
Thanks, looking good to me.
--
To unsubscribe from this list: send the line unsubscribe git
Ramkumar Ramachandra artag...@gmail.com writes:
| Hi,
| Some of my colleagues are lazy to fire up an editor and write proper
| commit messages- they often write one-liners using `git commit -m`.
| However, that line turns out to be longer than 72 characters, and the
| resulting `git log` output
As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.
On Thu, Nov 1, 2012 at 5:29 PM, Lars Gullik Bjønnes lar...@gullik.org wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
| Hi,
| Some of my colleagues are lazy to fire up an
Right now, there are events which can cause git fetch to hang forever.
This is really problematic in automatic use.
A git fetch --timeout which would exit with a nonzero exit code if no
forward progress is made would be really helpful.
-hpa
--
To unsubscribe from this list: send the line
Kevin wrote:
As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.
I suspect the underlying problem is that we make it too hard to tell
git which text editor to run.
Ram, what platform do your colleagues use?
Thanks,
Jonathan
--
To
On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote:
Jeff King wrote:
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--
[snip]
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow
Hey all.
Using git-merge --log to merge commit messages that spawn multiple lines
will produce overlong summary lines.
That's because each summary line for a commit includes the entire commit
message (all lines concatenated).
According to git-fmt-merge-msg(1), --log should 'populate the log
Hi,
I found more issues in fast-export. remote-testgit, and eventually I decided
there's no reason to use this python script, so I wrote a much simpler version
that does the same, and more. I'm not going to list all the reasons because
apparently opinions are not welcome in the list any more. For
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that were
Basically this is what we want:
== pull ==
testgit transport-helper
* export - import
# testgit.marks git.marks
== push ==
testgit transport-helper
* import- export
#
This script is not really exercising the remote-helper functionality,
but more the python framework for remote helpers that live in
git_remote_helpers.
It's also not a good example of how to write remote-helpers, unless you
are planning to use python, and even then you might not want to use this
It's way simpler. It exerceises the same features of remote helpers.
It's easy to read and understand. It doesn't depend on python.
It does _not_ exercise the python remote helper framework; there's
another tool and another test for that.
For now let's just copy the old remote-helpers test
Only makes sense for remote-testpy.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2eca42e..a03d087 100755
---
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 67 +++
1 file changed,
Unfortunately they do not work.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit| 18 +
t/t5801-remote-helpers.sh | 49 +++
2 files changed, 63 insertions(+), 4 deletions(-)
mode change 100755 =
Doesn't make a difference for the tests, but it does for the ones
seeking reference.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit | 11 +++
1 file changed, 11 insertions(+)
diff --git a/git-remote-testgit b/git-remote-testgit
index 6c348b0..4e8b356
People seeking for reference would find it useful.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index 4e8b356..1116587 100755
---
First the expected, then the actual, otherwise the diff would be the
opposite of what we want.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9350-fast-export.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t9350-fast-export.sh
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we
Setting 'commit' to 'commit' is a no-op. It might have been there to
avoid a compiler warning, but if so, it was the compiler to blame, and
it's certainly not there any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 2 +-
1 file changed, 1
They have been marked as UNINTERESTING for a reason, lets respect that.
Currently the first ref is handled properly, but not the rest, so:
% git fast-export master ^master
Would currently throw a reset for master (2nd ref), which is not what we
want.
% git fast-export master ^foo ^bar ^roo
41 matches
Mail list logo
