[PATCH 2/3] branch: add --unset-upstream option

We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto --- Documentation/git-branch.txt | 5 + builtin/

[PATCH 0/3] Improve branch UI for setting upstream information

Hi all, After way too long, here's the next iteration of the concept that began with swapping arguments in --set-upstream like -m does. After the feedback from the list, --set-upstream-to was born and --set-upstream is being deprecated in favour of either --track or --set-upstream-to depening on

[PATCH 1/3] branch: introduce --set-upstream-to

The existing --set-uptream option can cause confusion, as it uses the usual branch convention of assuming a starting point of HEAD if none is specified, causing git branch --set-upstream origin/master to create a new local branch 'origin/master' that tracks the current branch. As --set-upstre

Re: Porting git to HP NonStop

"Joachim Schmitz" writes: > OK, I'll go for a compat/mkdir.c though. No. See below. > We shouldn't call it tandem.c as Tandem, the Company, doesn't exist anymore > and since more than a decade (bough by Compaq, then HP), only the __TANDEM > survived in our compiler and headers/libraries. Could

RE: Porting git to HP NonStop

> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Monday, August 20, 2012 4:42 PM > To: Joachim Schmitz > Cc: 'Shawn Pearce'; git@vger.kernel.org; rsbec...@nexbridge.com > Subject: Re: Porting git to HP NonStop > > "Joachim Schmitz" writes: > > > OK, I'll go for a compat/mkdir.c though.

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

Erik Faye-Lund writes: > On Mon, Aug 20, 2012 at 9:00 AM, Junio C Hamano wrote: >> * ef/win32-cred-helper (2012-08-16) 1 commit >> - contrib: add win32 credential-helper >> >> Credential helper for Win32 (is this GUI???). > > No, and credential helpers shouldn't be either. Hrm, doesn't it even

Re: [PATCH/RFC v4 01/16] GSOC remote-svn

Florian Achleitner writes: > On Saturday 18 August 2012 13:13:47 Junio C Hamano wrote: >> That indicates that one necessary patch to add logic to Makefile to >> go and build that subdirectory, at least before running the test, >> but possibly as part of the "all" target, is missing, isn't it? >>

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

On Mon, Aug 20, 2012 at 6:21 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> On Mon, Aug 20, 2012 at 9:00 AM, Junio C Hamano wrote: >>> * ef/win32-cred-helper (2012-08-16) 1 commit >>> - contrib: add win32 credential-helper >>> >>> Credential helper for Win32 (is this GUI???). >> >> No,

Re: git on HP NonStop

Johannes Sixt writes: > Am 8/20/2012 12:36, schrieb Joachim Schmitz: >> int var = var; >> char *othervar = othervar; >> >> ... >> >> What is the reason for using that self-init stuff? I don't think it is >> really portable, is it? > > It is used to avoid "var may be used uninitialized" warnings

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

Erik Faye-Lund writes: > On Mon, Aug 20, 2012 at 6:21 PM, Junio C Hamano wrote: >> Erik Faye-Lund writes: >> >>> On Mon, Aug 20, 2012 at 9:00 AM, Junio C Hamano wrote: * ef/win32-cred-helper (2012-08-16) 1 commit - contrib: add win32 credential-helper Credential helper for

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

On Mon, Aug 20, 2012 at 6:35 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> On Mon, Aug 20, 2012 at 6:21 PM, Junio C Hamano wrote: >>> Erik Faye-Lund writes: >>> On Mon, Aug 20, 2012 at 9:00 AM, Junio C Hamano wrote: > * ef/win32-cred-helper (2012-08-16) 1 commit > - con

Re: [PATCH/RFC v4 01/16] GSOC remote-svn

Hi, Florian Achleitner wrote: > What version would you prefer? I think git-remote-svn should move out of contrib to the toplevel of git.git (as I think I've mentioned before). Since it's just a new git command in incubation, I don't want the maintenance hassle of keeping it in contrib/svn-fe.

Re: [RFC 1/5] GSOC: prepare svndump for branch detection

Florian Achleitner wrote: > Currently, the mark number is equal to the svn revision number the commit > corresponds to. I didn't want to break that, but not mandatory. We could also > split the mark namespace by reserving one or more of the most significant bits > as a type specifier. > I'll devel

Re: Porting git to HP NonStop

"Joachim Schmitz" writes: > I haven't found any other to be needed. Well, poll, maybe, but with only > minor tweaks for the win32 one works for me (and those tweaks are compatible > with win32 > >> A separate file, compat/tandem/mkdir.c, is fine, though. If you wouldn't have dozens of them, so c

Re: receive.denyNonNonFastForwards not denying force update

John Arthorne writes: > For all the details see this bugzilla, particularly comment #59 where we > finally narrowed this down: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150 What does "at the system level" in your "does *not* work at the system level." exactly mean? A configuration va

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

Erik Faye-Lund writes: >> OK, so is this a good description to go in the merge commit when it >> goes to 'master'? >> >> * ef/win32-cred-helper (2012-08-16) 1 commit >> - contrib: add win32 credential-helper >> >> Credential helper for Win32, to allow access to the keychain of >>

[PATCH 0/2] further fixes of check_ref_format() users

There were a few overtight "check_ref_format()" that was exposed with a natural "mirror" refspec "refs/*:refs/*". Junio C Hamano (2): fetch/push: allow refs/*:refs/* get_fetch_map(): tighten checks on dest refs builtin/fetch-pack.c | 2 +- builtin/receive-pack.c | 2 +- connect.c

[PATCH 1/2] fetch/push: allow refs/*:refs/*

There are a handful of places where we call check_refname_format() on a substring after "refs/" of a refname we are going to use, and filter out a valid match with "refs/stash" with such a pathspec. Not sending a stash may arguably be a feature (as stash is inherently a local workflow element), bu

[PATCH 2/2] get_fetch_map(): tighten checks on dest refs

The code to check the refname we store the fetched result locally did not bother checking the first 5 bytes of it, presumably assuming that it always begin with "refs/". For a fetch refspec (or the result of applying wildcard on one), we always want the RHS to map to something inside "refs/" hiera

Re: [RFC 1/5] GSOC: prepare svndump for branch detection

On Monday 20 August 2012 09:45:30 Jonathan Nieder wrote: > Florian Achleitner wrote: > > Currently, the mark number is equal to the svn revision number the commit > > corresponds to. I didn't want to break that, but not mandatory. We could > > also split the mark namespace by reserving one or more

[PATCH] precompose-utf8: do not call checks for non-ascii "utf8"

As suggested by Linus, this function is not checking UTF-8-ness of the string; it only is seeing if it is pure US-ASCII. Signed-off-by: Junio C Hamano --- * Just for completeness, this on top. compat/precompose_utf8.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) dif

[PATCH] parseopt: do not translate empty help string

The gettext .po files have a header, but it looks like the translation specification for an empty string. This results in _("") actually returning that header. Prevent parseopt from passing empty strings to gettext when it displays help about commands. In some instances it already did this, but

Re: Comparing the working tree with a commit should be independent of the index

On 08/18/2012 11:19 PM, Junio C Hamano wrote: >> Instead I get "deleted file". Adding the file to the index changes >> it. This is IMHO a bug. > > Among the 7 interesting cases, a path missing from the index have 3 > interesting cases. > > In $commitOn filesystem > > Yes

Re: [PATCH 3/3] branch: suggest how to undo a --set-upstream when given one branch

Carlos Martín Nieto writes: > This interface is error prone, and a better one (--set-upstream-to) > exists. Suggest how to fix a --set-upstream invocation in case the > user only gives one argument, which makes it likely that he meant to > do the opposite, like with > > git branch --set-upstr

Re: Comparing the working tree with a commit should be independent of the index

Maaartin writes: > On 08/18/2012 11:19 PM, Junio C Hamano wrote: > ... >> In short, I do not think there is a bug in the current behaviour. > > I can live with it. Many thanks for your answer. > > Do you care to copy-paste something to [1], so I could accept your answer? I never post to that sit

Re: [PATCH] parseopt: do not translate empty help string

Thomas Rast writes: > The gettext .po files have a header, but it looks like the translation > specification for an empty string. This results in _("") actually > returning that header. > > Prevent parseopt from passing empty strings to gettext when it > displays help about commands. In some in

Re: [PATCH] precompose-utf8: do not call checks for non-ascii "utf8"

On 08/20/2012 08:13 PM, Junio C Hamano wrote: As suggested by Linus, this function is not checking UTF-8-ness of the string; it only is seeing if it is pure US-ASCII. Signed-off-by: Junio C Hamano --- * Just for completeness, this on top. compat/precompose_utf8.c | 16 1

Re: [PATCH] parseopt: do not translate empty help string

Junio C Hamano writes: > Thomas Rast writes: > >> The gettext .po files have a header, but it looks like the translation >> specification for an empty string. This results in _("") actually >> returning that header. > > Thanks; this is a tricky bit to catch and makes me wonder where else > we h

How to request a fast-forward pull

Hi gitsters, Paul Gortmaker wrote: > When you have a moment, would you please migrate this > across to your main linux-stable repository? > > Both a branch and signed tag are present and pointing at > the same commit, but "git request-pull" does favour output > of the tag over the branch name. >

RE: git on HP NonStop

> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Monday, August 20, 2012 6:30 PM > To: Johannes Sixt > Cc: Joachim Schmitz; 'Jan Engelhardt'; git@vger.kernel.org > Subject: Re: git on HP NonStop > > Johannes Sixt writes: > > > Am 8/20/2012 12:36, schrieb Joachim Schmitz: > >> int var =

t9020 broken on pu ?

t9020 from pu doesn't work for me (neither linux nor Mac OS) I haven't been able to find out more than this: Initialized empty Git repository in /home/tb/projects/git/git.pu/t/trash directory.t9020-remote-svn/.git/ expecting success: init_git && git fetch svnsim && test

Re: t9020 broken on pu ?

On Monday 20 August 2012 22:56:35 Torsten Bögershausen wrote: > t9020 from pu doesn't work for me (neither linux nor Mac OS) > > I haven't been able to find out more than this: > > Initialized empty Git repository in /home/tb/projects/git/git.pu/t/trash > directory.t9020-remote-svn/.git/ > expect

[PATCH v5 00/16] GSOC remote-svn

New version with these changes: - includes fixups and changes by Junio from fa/remote-svn - move contrib/svn-fe/remote-svn.c to remote-testsvn.c (in toplevel) - add it to the toplevel Makefile (needed to copy the linker rule, is there a nicer way?) - check for prerequisite in test script (probab

[PATCH v5 01/16] Implement a remote helper for svn in C

Enable basic fetching from subversion repositories. When processing remote URLs starting with testsvn::, git invokes this remote-helper. It starts svnrdump to extract revisions from the subversion repository in the 'dump file format', and converts them to a git-fast-import stream using the function

[PATCH v5 06/16] Add documentation for the 'bidi-import' capability of remote-helpers

Signed-off-by: Florian Achleitner Signed-off-by: Junio C Hamano --- Documentation/git-remote-helpers.txt | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index f5836e4..5faa48e

[PATCH v5 13/16] remote-svn: add incremental import

Search for a note attached to the ref to update and read it's 'Revision-number:'-line. Start import from the next svn revision. If there is no next revision in the svn repo, svnrdump terminates with a message on stderr an non-zero return value. This looks a little weird, but there is no other way

[PATCH v5 08/16] remote-svn, vcs-svn: Enable fetching to private refs

The reference to update by the fast-import stream is hard-coded. When fetching from a remote the remote-helper shall update refs in a private namespace, i.e. a private subdir of refs/. This namespace is defined by the 'refspec' capability, that the remote-helper advertises as a reply to the 'capa

[PATCH v5 09/16] Allow reading svn dumps from files via file:// urls

For testing as well as for importing large, already available dumps, it's useful to bypass svnrdump and replay the svndump from a file directly. Add support for file:// urls in the remote url, e.g. svn::file:///path/to/dump When the remote helper finds an url starting with file:// it tries to

[PATCH v5 11/16] Create a note for every imported commit containing svn metadata

To provide metadata from svn dumps for further processing, e.g. branch detection, attach a note to each imported commit that stores additional information. The notes are currently hard-coded in refs/notes/svn/revs. Currently the following lines from the svn dump are directly accumulated in the no

[RFC 3/4] vcs-svn/svndump: rewrite handle_node(), begin|end_revision()

Split the decision of what to do and actually doing it in handle_node() to allow for detection of branches from svn nodes. Split it into handle_node() and apply_node(). svn dumps are structured in revisions, which contain multiple nodes. Nodes represent operations on data. Currently the function h

Re: [PATCH] precompose-utf8: do not call checks for non-ascii "utf8"

Torsten Bögershausen writes: > a) in readdir we die() when iconv_open() fails, and we could/should do > that in void precompose_argv() as well? Probably. > b) Should die("txt") be converted into die(_("txt")) to be able to > translate the message? I do not even know what die("txt") is trying t

Re: [PATCH] parseopt: do not translate empty help string

Thomas Rast writes: > Junio C Hamano writes: > >> Thomas Rast writes: >> >>> The gettext .po files have a header, but it looks like the translation >>> specification for an empty string. This results in _("") actually >>> returning that header. >> >> Thanks; this is a tricky bit to catch and m

Re: [PATCH] parseopt: do not translate empty help string

Junio C Hamano writes: >> Oh, I forgot that we actually had a wrapper instead of the usual _. >> Yes, I think that would be the better solution to guard against this. > > OK, then let's replace the patch text of your commit ;-). He, we need to update the log message a bit, too. -- >8 -- From: T

Re: [PATCH v5 02/16] Add git-remote-testsvn to Makefile.

Florian Achleitner writes: > Subject: Re: [PATCH v5 02/16] Add git-remote-testsvn to Makefile. Adds '.' at the end of the title. > The link-rule is a copy of the standard git$X rule but adds VCSSVN_LIB. > > Signed-off-by: Florian Achleitner > --- > Makefile |5 + > 1 file changed, 5 i

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

gits...@pobox.com wrote on Mon, 20 Aug 2012 00:00 -0700: > * pw/p4-submit-conflicts (2012-08-16) 12 commits > - git p4: add submit --prepare-p4-only option > - git p4: add submit --dry-run option > - git p4: accept -v for --verbose > - git p4: revert deleted files after submit cancel > - git p

Re: [PATCH v5 06/16] Add documentation for the 'bidi-import' capability of remote-helpers

Florian Achleitner writes: > Signed-off-by: Florian Achleitner > Signed-off-by: Junio C Hamano > --- > Documentation/git-remote-helpers.txt | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-remote-helpers.txt > b/Documentation/g

Re: [PATCH] Can show relative date of the commit with future timestamp

Jundong Xue writes: > tomxue@ubuntu:~/mycode/life$ git todo > * d768da9 - (in the future: 3 hours later) Meeting with vendor — Tom > Xue (HEAD, master) > * 5fcd556 - (in the future: 12 days later) Take my personal holiday — Tom Xue > * 9dd280b - (in the future: 11 months later) 端午节 — Tom Xue > *

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

Pete Wyckoff writes: > gits...@pobox.com wrote on Mon, 20 Aug 2012 00:00 -0700: >> * pw/p4-submit-conflicts (2012-08-16) 12 commits >> - git p4: add submit --prepare-p4-only option >> - git p4: add submit --dry-run option >> - git p4: accept -v for --verbose >> - git p4: revert deleted files

Re: [PATCH 00/66] parseopt i18n marking (again)

All queued; there were three commands that gained new options that are already in flight. If everybody agrees that it is a good idea to mark help text in parse_options with N_(), perhaps a better approach is to remove these three patches, queue each of them on top of its respective topic, and have

Re: [PATCH v5 15/16] remote-svn: add marks-file regeneration

Florian Achleitner writes: > fast-import mark files are stored outside the object database and are > therefore not fetched and can be lost somehow else. marks provide a > svn revision --> git sha1 mapping, while the notes that are attached > to each commit when it is imported provide a git sha1

Re: [PATCH] parseopt: do not translate empty help string

Junio C Hamano writes: > Junio C Hamano writes: > >>> Oh, I forgot that we actually had a wrapper instead of the usual _. >>> Yes, I think that would be the better solution to guard against this. >> >> OK, then let's replace the patch text of your commit ;-). > > He, we need to update the log me

Re: [PATCH v5 15/16] remote-svn: add marks-file regeneration

Junio C Hamano writes: > I think you meant something like: > > init_notes(NULL, notes_ref, NULL, 0); > marksfile = fopen(marksfilename, "r"); > if (!marksfile) { > regenerate_marks(marksfilename); > marksfile = fopen(marksfilename, "r"); >

[PATCH] git-p4: Strip branch name prefixes if --use-client-spec enabled

From: "Patrick C. McGinty" This removes the branch names from being included in the file system path when using the both --use-client-spec and --detect-branches options. Used alone, the --detect-branches option did the right thing, removing the branch names from the relative git path. By adding

Re: receive.denyNonNonFastForwards not denying force update

On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote: > John Arthorne writes: > >> For all the details see this bugzilla, particularly comment #59 where we >> finally narrowed this down: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150 > > What does "at the system level" in your "does

Re: receive.denyNonNonFastForwards not denying force update

Sitaram Chamarty writes: > On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote: >> John Arthorne writes: >> >>> For all the details see this bugzilla, particularly comment #59 where we >>> finally narrowed this down: >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150 >> >> What doe

[PATCH] Fallback on getpwuid if envar HOME is unset

>From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001 From: Conley Owens Date: Mon, 20 Aug 2012 18:23:40 -0700 Subject: [PATCH] Fallback on getpwuid if envar HOME is unset Signed-off-by: Conley Owens --- path.c | 5 + 1 file changed, 5 insertions(+) diff --git a/path.c b/

Re: receive.denyNonNonFastForwards not denying force update

On Mon, Aug 20, 2012 at 6:22 PM, Junio C Hamano wrote: > Sitaram Chamarty writes: > >> On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote: >>> John Arthorne writes: >>> For all the details see this bugzilla, particularly comment #59 where we finally narrowed this down: h

Re: [PATCH] subtree.sh: Use raw subject and body modifier "%B" instead of "%s%n%n%b"

Techlive Zheng writes: > "%s%n%n%b" is not always equal to "%B". If the commit msg does not have > a body, this will append an extra new-line character to the msg title > which would cause the splited commit has a new sha1 hash. In most cases, > this does not matter, but for a project which did n

Re: receive.denyNonNonFastForwards not denying force update

On Mon, Aug 20, 2012 at 06:22:26PM -0700, Junio C Hamano wrote: > > "git config --system receive.denynonfastforwards true" is not honored. > > At all. (And I checked there was nothing overriding it). > > > > "--global" does work (is honored). > > > > Tested on 1.7.11 > > Thanks, and interesting

Re: git on HP NonStop

"Joachim Schmitz" writes: > OK, so let's have a look at code, current git, > builtin/cat-file.c, line 196: > void *contents = contents; > > This variable is set later in an if branch (if (print_contents == BATCH), > but not in the else branch. It is later used always under the same condit

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 6:52 AM, Junio C Hamano wrote: > Sitaram Chamarty writes: > >> On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote: >>> John Arthorne writes: >>> For all the details see this bugzilla, particularly comment #59 where we finally narrowed this down: h

Re: receive.denyNonNonFastForwards not denying force update

On Mon, Aug 20, 2012 at 9:53 PM, Brandon Casey wrote: >git config --system -e > > Hopefully your editor exposes the path that it is editing even if you > don't have permission to modify it. GIT_EDITOR=echo git config --system -e works for me. j. -- To unsubscribe from this list: send the

Re: A possible subtree split bug

Fabien POTENCIER writes: > According to the docs: > > "Repeated splits of exactly the same history are > guaranteed to be identical (ie. to produce the same > commit ids). Because of this, if you add new commits > and then re-split, the new commits will be attached as > commits on top of the his

Re: [PATCH/RFC] [git-subtree.sh] Use raw subject and body modifier "%B" instead of "%s%n%n%b" for commit

Techlive Zheng writes: > I don't know if it is the right place to post this patch, I have sended > an email to the original author apenwarr and have no response. According > to > , > this is the place, but >

Re: [PATCH] Fallback on getpwuid if envar HOME is unset

On Mon, Aug 20, 2012 at 06:28:57PM -0700, Conley Owens wrote: > From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001 > From: Conley Owens > Date: Mon, 20 Aug 2012 18:23:40 -0700 > Subject: [PATCH] Fallback on getpwuid if envar HOME is unset Please drop these lines from the mess

Re: receive.denyNonNonFastForwards not denying force update

Jay Soffian writes: > On Mon, Aug 20, 2012 at 9:53 PM, Brandon Casey wrote: >>git config --system -e >> >> Hopefully your editor exposes the path that it is editing even if you >> don't have permission to modify it. > > GIT_EDITOR=echo git config --system -e > > works for me. Clever ;-) -

Re: receive.denyNonNonFastForwards not denying force update

Jeff King writes: > On Mon, Aug 20, 2012 at 06:22:26PM -0700, Junio C Hamano wrote: > >> Does anybody recall if this is something we did on purpose? After >> eyeballing the callchain starting from cmd_receive_pack() down to >> receive_pack_config(), nothing obvious jumps at me. > > No, I do not

Re: [PATCH] Fallback on getpwuid if envar HOME is unset

Conley Owens writes: > From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001 > From: Conley Owens > Date: Mon, 20 Aug 2012 18:23:40 -0700 > Subject: [PATCH] Fallback on getpwuid if envar HOME is unset > > Signed-off-by: Conley Owens > --- We can see you are doing what you clai

Re: Fix git-svn for SVN 1.7

Junio C Hamano writes: > Jonathan Nieder writes: > >> Hi, >> >> Eric Wong wrote: >>> "Michael G. Schwern" wrote: >> This patch series fixes git-svn for SVN 1.7 tested against SVN 1.7.5 and 1.6.18. Patch 7/8 is where SVN 1.7 starts passing. >>> >>> Thanks Michael. I've made minor edi

[PATCH 0/7] Gettext poison fixes

Not much to say. With this series, the test suite should pass again with gettext poison on. It's independent with the parseopt-i18n series I sent yesterday as the test suite was broken even before. Jiang Xin (7): Fix tests under GETTEXT_POISON on relative dates Fix tests under GETTEXT_POISON o

[PATCH 1/7] Fix tests under GETTEXT_POISON on relative dates

From: Jiang Xin Use a i18n-specific test_i18ncmp in t/t0006-data.sh for relative dates tests. This issue was was introduced in v1.7.10-230-g7d29a: 7d29a i18n: mark relative dates for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by:

[PATCH 3/7] Fix tests under GETTEXT_POISON on diffstat

From: Jiang Xin Use i18n-specific test functions in test scripts for diffstat. This issue was was introduced in v1.7.9-1-g7f814: 7f814 Use correct grammar in diffstat summary line and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọ

[PATCH 5/7] Fix tests under GETTEXT_POISON on pack-object

From: Jiang Xin Use i18n-specific test functions in test scripts for pack-object. This issue was was introduced in v1.7.10.2-556-g46140: 46140 index-pack: use streaming interface for collision test on large blobs cf2ba pack-objects: use streaming interface for reading large loose blobs

[PATCH 7/7] Fix tests under GETTEXT_POISON on parseopt

From: Jiang Xin Use i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: J

[PATCH 2/7] Fix tests under GETTEXT_POISON on git-stash

From: Jiang Xin Use i18n-specific test functions in test scripts for git-stash. This issue was was introduced in v1.7.4.1-119-g355ec: 355ec i18n: git-status basic messages and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọc Duy -

[PATCH 6/7] Fix tests under GETTEXT_POISON on git-remote

From: Jiang Xin Use i18n-specific test functions in test scripts for git-remote. This issue was was introduced in v1.7.10-233-gbb16d5: bb16d5 i18n: remote: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thá

[PATCH 4/7] Fix tests under GETTEXT_POISON on git-apply

From: Jiang Xin Use i18n-specific test functions in test scripts for git-apply. This issue was was introduced in the following commits: de373 i18n: apply: mark parseopt strings for translation 3638e i18n: apply: mark strings for translation and been broken under GETTEXT_POISON=YesPlease

[PATCH] Build in gettext poison feature unconditionally

Making gettext poison second citizen makes it easy to forget to run the test suite with it. This is step one to running test suite with gettext poison by default. The runtime cost should be small. "gcc -O2" inlines _() and use_gettext_poison(). But even if it does not, performance should not be im

Re: [PATCH 5/7] Fix tests under GETTEXT_POISON on pack-object

Hi, Nguyễn Thái Ngọc Duy wrote: > From: Jiang Xin > > Use i18n-specific test functions in test scripts for pack-object. Thanks for resending, and sorry I haven't made time to polish the translation-based poison implementation you sent before (which seemed very useful and pleasant to work with).

Re: [PATCH] Build in gettext poison feature unconditionally

Nguyễn Thái Ngọc Duy wrote: > The runtime cost should be small. "gcc -O2" inlines _() and > use_gettext_poison(). But even if it does not, performance should not > be impacted as _() calls are usually not on critical path. If some of > them are, we better fix there as gettext() may or may not be c

Re: [PATCH] test: some testcases failed if cwd is on a symlink

On 08/19/2012 06:43 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> I just verified that the combination of your two suggestions (i.e., the >> patch below) fixes the problem for me. > > Good to know. > > The only remaining two worries from me are if everybody has working > pwd at that

Re: receive.denyNonNonFastForwards not denying force update

On Mon, Aug 20, 2012 at 08:49:42PM -0700, Junio C Hamano wrote: > > No, I do not think it was on purpose. And it would be very hard to do > > so, anyway; config callbacks are not given any information about the > > source of the config variable, and cannot distinguish between repo, > > global, and

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 02:10:59AM -0400, Jeff King wrote: > I think that makes sense. Like this patch? > > -- >8 -- > Subject: [PATCH] config: warn on inaccessible files > > Before reading a config file, we check "!access(path, R_OK)" > to make sure that the file exists and is readable. If it's

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 02:22:19AM -0400, Jeff King wrote: > And this might be a good follow-on: > > -- >8 -- > Subject: [PATCH] gitignore: report access errors of exclude files ...and it would probably help if I gave you the version that actually compiled. -- >8 -- Subject: [PATCH] gitignore:

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 02:22:19AM -0400, Jeff King wrote: > And this might be a good follow-on: > > -- >8 -- > Subject: [PATCH] gitignore: report access errors of exclude files And if we are going to do that, then we almost certainly want to do this. -- >8 -- Subject: [PATCH] attr: warn on ina

Re: How to request a fast-forward pull

On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote: > > When you have a moment, would you please migrate this > > across to your main linux-stable repository? > > > > Both a branch and signed tag are present and pointing at > > the same commit, but "git request-pull" does favour outpu

Re: [PATCH 1/2] fetch/push: allow refs/*:refs/*

On 08/20/2012 07:39 PM, Junio C Hamano wrote: > There are a handful of places where we call check_refname_format() on a > substring after "refs/" of a refname we are going to use, and filter out a > valid match with "refs/stash" with such a pathspec. Not sending a stash > may arguably be a feature

Re: Feature request: fetch --prune by default

On Thu, Aug 16, 2012 at 04:22:54PM -0700, Junio C Hamano wrote: > > In the meantime, would it make sense to introduce a configuration > > variable to request this behavior? > > > > If so, should it be global? > > > > fetch.prune = always > > > > or per-remote? > > > > remote..prune = always > > >

Re: git stash data loss

On Thu, Aug 16, 2012 at 08:30:48PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Fri, Jul 27, 2012 at 09:29:53AM -0400, Jeff King wrote: > > > >> If we put actual files inside "x", which git does track, then they would > >> be part of the stash, and should be properly retained. But t

[PATCH] difftool: silence warning

Silence a warning given when running git difftool --dir-diff and there are no changes. This is because command_oneline returns undef when the command has no output, not ''. Signed-off-by: Ross Lagerwall --- git-difftool.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git

What's cooking in git.git (Aug 2012, #06; Sun, 19)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Now 1.7.12 is out, we will have a few days of calming down period on the 'master' front, just in case we have to deal with brown paper bag post-

Re: What's cooking in git.git (Aug 2012, #06; Sun, 19)

On Mon, Aug 20, 2012 at 9:00 AM, Junio C Hamano wrote: > * ef/win32-cred-helper (2012-08-16) 1 commit > - contrib: add win32 credential-helper > > Credential helper for Win32 (is this GUI???). No, and credential helpers shouldn't be either. -- To unsubscribe from this list: send the line "unsubs

Re: read-cache-v5.c: compiler warnings

On 08/19, Ramsay Jones wrote: > Hi Thomas, > > Just an FYI; two out of the three gcc compilers I use (Linux, cygwin > but not MingW), issue the following warnings: > > CC read-cache-v5.o > read-cache-v5.c: In function `write_index_v5': > read-cache-v5.c:1011: warning: 'dir' might

RE: Porting git to HP NonStop

> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Sunday, August 19, 2012 7:23 PM > To: Joachim Schmitz > Cc: 'Shawn Pearce'; git@vger.kernel.org; rsbec...@nexbridge.com > Subject: Re: Porting git to HP NonStop > > "Joachim Schmitz" writes: > > > Found the problem: our mkdir(dir,flags) f

RE: git on HP NonStop

> From: Jan Engelhardt [mailto:jeng...@inai.de] > Sent: Sunday, August 19, 2012 6:26 PM > To: Joachim Schmitz > Cc: 'Junio C Hamano'; git@vger.kernel.org > Subject: RE: git on HP NonStop > > > On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote: > > @@ -98,6 +99,11 @@ > > #include > > #include >

Re: git on HP NonStop

Am 8/20/2012 12:36, schrieb Joachim Schmitz: > int var = var; > char *othervar = othervar; > > ... > > What is the reason for using that self-init stuff? I don't think it is > really portable, is it? It is used to avoid "var may be used uninitialized" warnings for some compilers. Officially (acc

RE: git on HP NonStop

> From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, August 20, 2012 12:57 PM > To: Joachim Schmitz > Cc: 'Jan Engelhardt'; 'Junio C Hamano'; git@vger.kernel.org > Subject: Re: git on HP NonStop > > Am 8/20/2012 12:36, schrieb Joachim Schmitz: > > int var = var; > > char *othervar =

Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change

Dear Junio, On 20 Aug 2012, at 02:26, Junio C Hamano wrote: > We are not particularly interested in "it is possible" when many > implementations can all trivially allow it to be "possible"; the > question is what a sensible solution is among them, and I didn't > find "a directory with timestamp i

Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change

On 20 Aug 2012, at 13:32, Alexey Muranov wrote: > The problem of mapping branch names to file paths looks to me very similar to > the problem of mapping URLs to file paths for static web sites, so i would > propose to use the same solution: add a special extension to distinguish a > file from a

[PATCH 00/66] parseopt i18n marking (again)

There are not many changes since last time I sent this. A few new strings are introduced by new options, which are also marked. 'next' has some more, which causes conflicts but they should be easy to resolve. The last two patches are not really related to i18n. I looked at the marked strings and t

  1   2   >