On Jan 20, 2014, at 21:30, Jeff King wrote:
Ugh. Having just read the LESS discussion, it makes me wonder if the
strchr(getenv(LESS), 'R')
check I add elsewhere in the series is sufficient. I suspect in
practice
it is good enough, but I would not be surprised if there is a way to
fool it
On Wed, Jan 15, 2014 at 01:27:29PM +0200, al_sho...@yahoo.com wrote:
From: Alexander Shopov a...@kambanaria.org
Signed-off-by: Alexander Shopov a...@kambanaria.org
Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Fri, Dec 13, 2013 at 07:46:36PM +, Astril Hayato wrote:
Write the gitk config data to $XDG_CONFIG_HOME/git/gitk
($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.
If $HOME/.gitk already exists use
On Sat, Jan 18, 2014 at 02:58:51PM +0200, Max Kirillov wrote:
Signed-off-by: Max Kirillov m...@max630.net
Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Mon, Dec 02, 2013 at 11:12:43AM -0800, Junio C Hamano wrote:
From: Jonathan Nieder jrnie...@gmail.com
Date: Mon, 25 Nov 2013 13:00:10 -0800
The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run
On 13-12-18 11:04 AM, Marc Branchaud wrote:
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that is almost always backwards in time. Replacing the text with arrows
makes it clear where the buttons will take
David Kastrup d...@gnu.org writes:
This is more a warmup than anything else: I'm actually doing a quite
more involved rewrite of git-blame right now. But it's been a long
time since I sent patches for Git, so I'm starting out with something
reasonably uncontroversial.
Ping?
Now I might
David Kastrup wrote:
Now I might have sent at an unopportune time: blame.c is mostly
attributed to Junio who seems to have been a few days absent now.
I also have seen quite a few mails and patch submissions on the list go
basically unanswered in the last few days.
In the U.S., yesterday
Hi kusma,
On Tue, 21 Jan 2014, Erik Faye-Lund wrote:
On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Mon, 20 Jan 2014, Torsten Bögershausen wrote:
b) add +++ at the places where you added the stat() and chmod(),
c) and to send the question
On Tue, Jan 21, 2014 at 5:57 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi kusma,
On Tue, 21 Jan 2014, Erik Faye-Lund wrote:
On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Mon, 20 Jan 2014, Torsten Bögershausen wrote:
b) add
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed under GPLv2
b) significant contributions to it will not be relicensed under
different
On Tue, Jan 21, 2014 at 11:10 AM, Paul Mackerras pau...@samba.org wrote:
+if {![file exists $config_file]} {
+ if {![file exists [file dirname $config_file]]} {
+ file mkdir [file dirname $config_file]
+ }
+ # for backward compatability use the old config file if it
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Now I might have sent at an unopportune time: blame.c is mostly
attributed to Junio who seems to have been a few days absent now.
I also have seen quite a few mails and patch submissions on the list go
basically unanswered in
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed under GPLv2
b) significant contributions
Write the gitk config data to $XDG_CONFIG_HOME/git/gitk ($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.
If $HOME/.gitk already exists use that for backward compatibility, so only new
installations are affected.
David Kastrup wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Any idea how this could be made more clear? E.g., maybe we should
bite the bullet and add a line to all source files that don't already
state a license:
/*
* License: GPLv2. See COPYING for details.
*/
Sebastian Schuberth sschube...@gmail.com writes:
On Sun, Jan 19, 2014 at 12:40 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
This patch applies on top of v3 of mh/safe-create-leading-directories.
The only logical change from Sebastian's patch is that this version
restores the original
Jeff King p...@peff.net writes:
...
does complicate the point of my series, which was to add more intimate
logic about how we handle LESS.
...
return !x || strchr(x, 'R');
}
[...]
}
but we are still hard-coding a lot of intelligence about less here.
I am not
Michael Haggerty mhag...@alum.mit.edu writes:
On 01/09/2014 09:11 PM, Junio C Hamano wrote:
Andy Lutomirski l...@amacapital.net writes:
It's possible, in principle, to shove enough metadata into the output
of 'git archive' to allow anyone to verify (without cloning the repo)
to verify that
Jeff King p...@peff.net writes:
Perhaps instead of just dumping it into a macro, we could actually parse
it at compile time into C code, and store the result as a header file.
Then that header file becomes the proper dependency, and this run-time
error:
+while (*pager_env) {
+
David Kastrup wrote:
The combination of the SubmittingPatches text with the file notices in
builtin/blame.c is not really painting a full picture of the situation.
BTW, thanks for bringing this up. It last came up at [1]. Perhaps we
can do better by adding a note to README or some similar
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Any idea how this could be made more clear? E.g., maybe we should
bite the bullet and add a line to all source files that don't already
state a license:
/*
* License:
David Kastrup wrote:
and contrib. The README file states
Git is an Open Source project covered by the GNU General Public
License version 2 (some parts of it are under different licenses,
compatible with the GPLv2). It was originally written by Linus
Torvalds with help of a
Sebastian Schuberth sschube...@gmail.com writes:
On Thu, Jan 2, 2014 at 10:08 PM, Junio C Hamano gits...@pobox.com wrote:
Seems like the path to clone to is taken as-is from argv in
cmd_clone(). So maybe another solution would be to replace all
backslashes with forward slashes already there?
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed under GPLv2
b) significant contributions
Cosmin Apreutesei cosmin.apreute...@gmail.com writes:
I would like to be able to tell my users that they can simply do:
git clone --git-dir=_/git/module1/.git module1-url
git clone --git-dir=_/git/module2/.git module2-url
which will overlay the files from both modules into the current
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
If the git version number consists of less than three period
separated numbers, then the windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION = 1.9.rc0
windres -O coff \
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
and contrib. The README file states
Git is an Open Source project covered by the GNU General Public
License version 2 (some parts of it are under different licenses,
compatible with the GPLv2). It was originally
Junio C Hamano gits...@pobox.com writes:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
If the git version number consists of less than three period
separated numbers, then the windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION =
Hi, thanks for answering.
I would like to be able to tell my users that they can simply do:
git clone --git-dir=_/git/module1/.git module1-url
git clone --git-dir=_/git/module2/.git module2-url
which will overlay the files from both modules into the current
directory, which from git's
David Kastrup d...@gnu.org writes:
---
Thanks. At some point during its development I must have thought
that having it as a dual-linked list may make it easier when we have
to split a block into pieces, but it seems that split_overlap() does
not need to look at this information.
Needs
An early preview release Git v1.9-rc0 is now available for testing
at the usual places. I tagged this late last week, but forgot to
send out the announcement before I left for the weekend, and then I
wasn't well yesterday, but anyway. There still may be a few minor
topics not in this preview but
From: Stefan Näwe stefan.na...@atlas-elektronik.com
Am 16.01.2014 22:14, schrieb Philip Oakley:
From: Stefan Näwe stefan.na...@atlas-elektronik.com
[...]
I'd really like to see 'git help relnotes' working as well...
Stefan
Stefan,
Were you thinking that all the release notes would be
Christian Couder chrisc...@tuxfamily.org writes:
This patch parses the trailer command line arguments
and put the result into an arg_tok doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 77
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
while `git repack --max-pack-size=1073741824` says
error: unknown option `max_pack_size=1073741824'
I
Jeff King p...@peff.net writes:
This tradeoff probably makes sense in the context of
pack-objects, where we have set revs-edge_hint to have the
traversal feed us the set of boundary objects. For a
regular rev-list, though, it is probably not a good
tradeoff. It is true that it makes our
Junio C Hamano gits...@pobox.com writes:
+static struct trailer_item *create_trailer_item(const char *string)
+{
+struct strbuf tok = STRBUF_INIT;
+struct strbuf val = STRBUF_INIT;
+struct trailer_item *new;
+
+parse_trailer(tok, val, string);
+
+int tok_alnum_len =
On 21/01/14 21:36, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
If the git version number consists of less than three period
separated numbers, then the windows resource file compilation
issues a syntax error:
$ touch
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed
Siddharth Agarwal s...@fb.com writes:
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
Thanks, Siddharth.
It seems that we have a hand-crafted parser
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
---
Thanks. At some point during its development I must have thought
that having it as a dual-linked list may make it easier when we have
to split a block into pieces, but it seems that split_overlap() does
not
Since 9d57c4a (git p4: implement view spec wildcards with p4
where, 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9809-git-p4-client-view.sh | 16
1 file changed, 8
Most of this is work on tests for git p4.
Patch 03 is a regression fix, found and narrowed down thanks to
much work by Damien Gérard. But it is obscure enough that I'm
not proposing it for a maintenance release.
There are a couple other behavior fixes, but again, these
are quite minor and can
While this happens to work, there was no test to make sure
that the basic importing of a symlink from p4 to git functioned.
Add a simple test to create a symlink in p4 and import it into git,
then verify that the symlink exists and has the correct target.
Signed-off-by: Pete Wyckoff
There was no test where p4 deleted a file with a wildcard
character. Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9812-git-p4-wildcards.sh | 27 +++
1 file
Damien Gérard highlights an interesting problem. Some p4
repositories end up with symlinks that have an empty target. It
is not possible to create this with current p4, but they do
indeed exist.
The effect in git p4 is that p4 print on the symlink returns an
empty string, confusing the curret
The tests use aut...@example.com as the canonical submitter,
but he does not have an entry in the p4 users database.
This causes the generated change description to complain
that the git and p4 users disagree. The complaint message
is still valid, just isn't useful in tests. It was was
Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with test -w on cygwin, but mistakenly
marked the new test as failing. Fix this.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9807-git-p4-submit.sh | 2 +-
1 file changed, 1 insertion(+), 1
Generating the submit template for p4 uses tempfile.mkstemp(),
which by default puts files in /tmp. For a test that fails,
possibly on purpose, this is not cleaned up. Run with TMPDIR
pointing into the trash directory so the temp files go away
with the test results.
To do this required some
Commit 9d7d446 (git p4: submit files with wildcards, 2012-04-29)
fixed problems with handling files that had p4 wildcard
characters, like @ and *. But it missed one case, that of
RCS keyword scrubbing, which uses p4 fstat to extract type
information. Fix it by calling wildcard_encode() on the
When p4 where fails, for whatever reason, the error message tries to
show an undefined variable. This minor bug applies only when using a
client spec, and was introduced recently in 9d57c4a (git p4: implement
view spec wildcards with p4 where, 2013-08-30).
Signed-off-by: Pete Wyckoff
The p4 server can enforce file locking, so that only one user
can edit a file at a time. Git p4 is unable to submit changes
to locked files. Currently it exits poorly. Ideally it would
notice the locked condition and clean up nicely.
Add a bunch of tests that describe the problem, hoping that
Thomas Rast noticed the docs have a mix of styles when
it comes to options with multiple spellings. Standardize
the couple in git-p4.txt that are odd.
Instead of:
-n, --dry-run::
Do this:
-n::
--dry-run::
See
http://thread.gmane.org/gmane.comp.version-control.git/219936/focus=219945
Junio C Hamano gits...@pobox.com writes:
Siddharth Agarwal s...@fb.com writes:
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
Thanks, Siddharth.
It
Philip Oakley philipoak...@iee.org writes:
Determining which is the current release note is possibly more
problematic, which should be when making the documentation.
Hmmm Why?
You are already aware of the stale-notes section, no? Isn't the top
one the latest?
--
To unsubscribe from this
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by now after seeing
https://sourceware.org/ml/binutils/2012-07/msg00199.html
Ah, nice find!
I will test your patch (below) and let you know soon, but it
Pete Wyckoff p...@padd.com writes:
Most of this is work on tests for git p4.
Patch 03 is a regression fix, found and narrowed down thanks to
much work by Damien Gérard. But it is obscure enough that I'm
not proposing it for a maintenance release.
There are a couple other behavior fixes,
Signed-off-by: David Kastrup d...@gnu.org
---
builtin/blame.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index e44a6bb..2195595 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -197,7 +197,6 @@ static void
Since the origin pointers are interned and reference-counted, comparing
the pointers rather than the content is enough. The only uninterned
origins are cached values kept in commit-util, but same_suspect is not
called on them.
Signed-off-by: David Kastrup d...@gnu.org
---
builtin/blame.c | 25
Same series as sent previously, just signed off this time.
David Kastrup (2):
builtin/blame.c: struct blame_entry does not need a prev link
Eliminate same_suspect function in builtin/blame.c
builtin/blame.c | 38 ++
1 file changed, 10 insertions(+), 28
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
Determining which is the current release note is possibly more
problematic, which should be when making the documentation.
Hmmm Why?
You are already aware of the stale-notes section, no? Isn't the top
one
Philip Oakley philipoak...@iee.org writes:
I already have a local patch that creates a stalenote.txt file, and
includes that in a release-notes(7) man page, but it still leaves
the actual release notes in a separate plain text file, linked from
the man page, rather than being right at hand,
On Tue, Jan 21, 2014 at 6:16 PM, Pete Wyckoff p...@padd.com wrote:
Damien Gérard highlights an interesting problem. Some p4
repositories end up with symlinks that have an empty target. It
is not possible to create this with current p4, but they do
indeed exist.
The effect in git p4 is that
On Tue, Jan 21, 2014 at 6:16 PM, Pete Wyckoff p...@padd.com wrote:
The tests use aut...@example.com as the canonical submitter,
but he does not have an entry in the p4 users database.
This causes the generated change description to complain
that the git and p4 users disagree. The complaint
manjian2...@gmail.com wrote:
From: linzj li...@ucweb.com
I am trying to improve git svn's performance according to some
profiling data.As the data showed,_rev_list subroutine and rebuild
subroutine are consuming a large proportion of time.So I improve
_rev_list's performance by
From: Cindye T. Richburg
Sent: Wednesday, January 22, 2014 12:39 AM
To: Cindye T. Richburg
Subject: RE: BREAKING NEWS
New Year Donation To You, Contact Mr Paul White
(paul-wh...@zbavitu.netmailto:paul-wh...@zbavitu.net) for more info
--
To unsubscribe from this
[Cc Pat, who added git.rc]
Am 1/22/2014 0:48, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by now after seeing
https://sourceware.org/ml/binutils/2012-07/msg00199.html
Ah, nice
68 matches
Mail list logo
