Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

[Cc Pat, who added git.rc] Am 1/22/2014 0:48, schrieb Junio C Hamano: > Ramsay Jones 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! >>

RE: BREAKING NEWS

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.net) for more info -- To unsubscribe from thi

Re: [PATCH] improve git svn performance

manjian2...@gmail.com wrote: > From: linzj > 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 memoize its resul

Re: [PATCH 06/11] git p4 test: run as user "author"

On Tue, Jan 21, 2014 at 6:16 PM, Pete Wyckoff 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 message > is

Re: [PATCH 03/11] git p4: work around p4 bug that causes empty symlinks

On Tue, Jan 21, 2014 at 6:16 PM, Pete Wyckoff 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 "p4 pri

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

"Philip Oakley" 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, which is what

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

From: "Junio C Hamano" "Philip Oakley" 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? It's that the 'git

[PATCH 0/2] Two mostly janitorial patches for builtin/blame.c

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 del

[PATCH 1/2] builtin/blame.c: struct blame_entry does not need a prev link

Signed-off-by: David Kastrup --- 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 drop_origin_blob(struct o

[PATCH 2/2] Eliminate same_suspect function in builtin/blame.c

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 --- builtin/blame.c | 25 ---

Re: [PATCH 00/11] git p4 tests and a few bug fixes

Pete Wyckoff 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, but agai

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Ramsay Jones 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 looks > good to m

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

"Philip Oakley" 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 list: send the l

Re: git repack --max-pack-size broken in git-next

Junio C Hamano writes: > Siddharth Agarwal 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

[PATCH 11/11] git p4 doc: use two-line style for options with multiple spellings

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 Sign

[PATCH 10/11] git p4 test: examine behavior with locked (+l) files

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 f

[PATCH 09/11] git p4: fix an error message when "p4 where" fails

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 --- gi

[PATCH 08/11] git p4: handle files with wildcards when doing RCS scrubbing

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 t

[PATCH 05/11] git p4 test: is_cli_file_writeable succeeds

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 --- t/t9807-git-p4-submit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

[PATCH 07/11] git p4 test: do not pollute /tmp

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 othe

[PATCH 06/11] git p4 test: run as user "author"

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 introduced

[PATCH 03/11] git p4: work around p4 bug that causes empty symlinks

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

[PATCH 04/11] git p4 test: explicitly check p4 wildcard delete

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 --- t/t9812-git-p4-wildcards.sh | 27 +++ 1 file changed, 27 inserti

[PATCH 02/11] git p4 test: ensure p4 symlink parsing works

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 --- t/t9802

[PATCH 00/11] git p4 tests and a few bug fixes

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 wa

[PATCH 01/11] git p4 test: wildcards are supported

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 --- t/t9809-git-p4-client-view.sh | 16 1 file changed, 8 insertions(+),

Re: [PATCH 1/2] builtin/blame.c: struct blame_entry does not need a prev link

Junio C Hamano writes: > David Kastrup 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 i

Re: git repack --max-pack-size broken in git-next

Siddharth Agarwal 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 outside pars

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Junio C Hamano writes: > Jonathan Nieder 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 >>

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

On 21/01/14 21:36, Junio C Hamano wrote: > Junio C Hamano writes: > >> Ramsay Jones 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 g

Re: [PATCH v2 04/16] trailer: process command line trailer arguments

Junio C Hamano 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 =

Re: [PATCH v2 2/2] list-objects: only look at cmdline trees with edge_hint

Jeff King 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 list slight

git repack --max-pack-size broken in git-next

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 bisecte

Re: [PATCH v2 04/16] trailer: process command line trailer arguments

Christian Couder 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 > --- > trailer.c | 77 > +++ > 1 file changed, 77 insertio

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

From: "Stefan Näwe" Am 16.01.2014 22:14, schrieb Philip Oakley: From: "Stefan Näwe" [...] I'd really like to see 'git help relnotes' working as well... Stefan Stefan, Were you thinking that all the release notes would be quoted verbatim in the one long man page? Or that it would be a

[ANNOUNCE] Git v1.9-rc0

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

Re: [PATCH 1/2] builtin/blame.c: struct blame_entry does not need a prev link

David Kastrup 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 sign-off. > buil

Re: GIT_WORK_TREE and GIT_DIR with git clone

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 fr

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Junio C Hamano writes: > Ramsay Jones 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 cof

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Jonathan Nieder 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 written

Re: REQUEST-PULL: Please pull from git-gui.

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

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Ramsay Jones 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 \ > -DMAJOR=1 -DMINOR=

Re: GIT_WORK_TREE and GIT_DIR with git clone

Cosmin Apreutesei 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 > directory, which from git

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Jonathan Nieder 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 to it

Re: [PATCH] Fix safe_create_leading_directories() for Windows

Sebastian Schuberth writes: > On Thu, Jan 2, 2014 at 10:08 PM, Junio C Hamano 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? >> >> That sounds like a w

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

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

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Jonathan Nieder writes: > David Kastrup wrote: >> Jonathan Nieder 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

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

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 f

Re: [PATCH 2/3] setup_pager: set MORE=R

Jeff King 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) { >> +st

Re: Verifiable git archives?

Michael Haggerty writes: > On 01/09/2014 09:11 PM, Junio C Hamano wrote: >> Andy Lutomirski 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 the archive is a correct

Re: [PATCH 2/3] setup_pager: set MORE=R

Jeff King 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 s

Re: [PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components

Sebastian Schuberth writes: > On Sun, Jan 19, 2014 at 12:40 AM, Michael Haggerty > 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 slash character rather than al

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

David Kastrup wrote: > Jonathan Nieder 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. >> */ > > Prob

[PATCH v2] gitk: Comply with XDG base directory specification

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.

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Jonathan Nieder 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 to it

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

Jonathan Nieder 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 the las

Re: [PATCH] gitk: Comply with XDG base directory specification

On Tue, Jan 21, 2014 at 11:10 AM, Paul Mackerras 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 exists >>

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

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 > dif

Re: [msysGit] Consecutive git gc fails on Windows network share

On Tue, Jan 21, 2014 at 5:57 PM, Johannes Schindelin wrote: > Hi kusma, > > On Tue, 21 Jan 2014, Erik Faye-Lund wrote: > >> On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin >> wrote: >> > >> > On Mon, 20 Jan 2014, Torsten Bögershausen wrote: >> > >> >> b) add "+++" at the places where you ad

Re: [msysGit] Consecutive git gc fails on Windows network share

Hi kusma, On Tue, 21 Jan 2014, Erik Faye-Lund wrote: > On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin > 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 "is this a g

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

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., yesterda

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

David Kastrup 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 have sent at

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

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

Re: [PATCH] gitk: chmod +x po2msg

On Mon, Dec 02, 2013 at 11:12:43AM -0800, Junio C Hamano wrote: > From: Jonathan Nieder > 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 directly. >

Re: [PATCH] gitk i18n: Added Bulgarian translation (304t)

On Wed, Jan 15, 2014 at 01:27:29PM +0200, al_sho...@yahoo.com wrote: > From: Alexander Shopov > > Signed-off-by: Alexander Shopov 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 a

Re: [PATCH] gitk: Comply with XDG base directory specification

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 u

Re: [PATCH] gitk: fix mistype

On Sat, Jan 18, 2014 at 02:58:51PM +0200, Max Kirillov wrote: > Signed-off-by: Max Kirillov 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 http://vger.kernel.org/majordomo-info

Re: [PATCH 2/3] setup_pager: set MORE=R

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