Re: [RFC 0/2] svn-fetch|push - an alternate approach

On 08/19/2012 12:21 PM, Marco Schulze wrote: > > On 18-08-2012 14:39, James R. McKaskill wrote: >> As a twist the code does not use the svn library, but rather talks the >> svn protocol directly. I actually found it much easier to go this route >> then trying to bend everything to how the svn libr

Re: Having an invalid HEAD file causes git not to recognize the repository

On Fri, Aug 17, 2012 at 02:42:33PM +0300, Egon Elbre wrote: > Having an invalid HEAD file causes git not to recognize the repository > and will cause an invalid message "fatal: Not a git repository (or any > of the parent directories): .git" although there is a .git folder and > everything seems o

[PATCHv2 1/2] t6300: test sort with multiple keys

Documentation of git-for-each-ref says that --sort= option can be used multiple times, in which case the last key becomes the primary key. However this functionality was never checked in test suite and is currently broken. This commit adds appropriate test in preparation for fix. Signed-off-by: Ka

[PATCHv2 2/2] for-each-ref: Fix sort with multiple keys

The linked list describing sort options was not correctly set up in opt_parse_sort. In the result, contrary to the documentation, only the last of multiple --sort options to git-for-each-ref was taken into account. This commit fixes it. Signed-off-by: Kacper Kornet --- builtin/for-each-ref.c |

Re: Having an invalid HEAD file causes git not to recognize the repository

On Tue, Aug 21, 2012 at 10:24 AM, Jeff King wrote: > >> I ran into this problem when I had a BSOD during a rebase (ignore that >> I'm having to use Windows). This meant that only half of the hash got >> written into HEAD and all git commands I tried failed. > > That generally shouldn't happen, as

Wrong file casing: git blame shows "Not commited yet" entries

Hi, if I have a file "File.txt" in my repo, then "git blame file.txt" gives me "Not commited yet" for every single line in this file. "git blame File.txt" gives the correct output. I am using "core.ignorecaes=true" so this behaviour is not what I expected. Is this a bug or a feature? Regards, Tho

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

On Sat, Aug 18, 2012 at 01:39:41PM -0700, Junio C Hamano wrote: > mhag...@alum.mit.edu writes: > > > Given that a flag day would anyway be required to add a d/f-tolerant > > system, I could live with a separate "graveyard" namespace as > > originally proposed by Jeff. > > > > However, I still thi

Re: [RFC 2/3] Delete reflogs for dead references to allow pruning

On Sat, Aug 18, 2012 at 07:14:45PM +0200, mhag...@alum.mit.edu wrote: > From: Michael Haggerty > > This test is broken by "retain reflogs for deleted refs". Explicitly > delete the reflogs in the graveyard to allow the corresponding commits > to be pruned. > > Signed-off-by: Michael Haggerty

Re: [PATCH] difftool: silence warning

On Mon, Aug 20, 2012 at 11:59 PM, Ross Lagerwall wrote: > 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 Thanks This patch is obv

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

Thank you for reconsider my patch! As you said, my implementation is not good while the idea is not bad. I checked out the latest git source code and patch it with your replacement, and it looks nice, I like it. This patch comes from my real need. And I think someone may need it as well. To be hon

Re: [PATCH] difftool: silence warning

On 08/21/2012 11:04 AM, David Aguilar wrote: > This patch is obviously correct, but it won't apply in git's "next" branch. > Can you please prepare a patch based on the version in next? > Sure. > > A small question on Perl style for the list... is it better say this? > >exit(0) unless $diff

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

On Monday 20 August 2012 16:20:27 Junio C Hamano wrote: > Junio C Hamano writes: > > I think you meant something like: > > init_notes(NULL, notes_ref, NULL, 0); > > > > marksfile = fopen(marksfilename, "r"); > > if (!marksfile) { > > > > regenerate_mar

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

On Monday 20 August 2012 16:20:27 Junio C Hamano wrote: > 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(marksf

[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

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

On Tue, Aug 21, 2012 at 12:17 PM, Jonathan Nieder wrote: >> --- a/t/t5530-upload-pack-error.sh >> +++ b/t/t5530-upload-pack-error.sh >> @@ -35,7 +35,7 @@ test_expect_success 'upload-pack fails due to error in >> pack-objects packing' ' >> printf "0032want %s\n0009done\n" \ >>

Re: [PATCH] daemon: --access-hook option

Right, this approach of having ACL using the --access-hook option looks much better. At least you got inspired this could be useful for somebody ;-) Michal On 08/15/2012 07:12 AM, Junio C Hamano wrote: > The --access-hook option to "git daemon" specifies an external > command to be run every time

misleading diff-hunk header

[posted originally to git-users@ but advised this would be a better forum] diff.{type}.xfuncname seems to start searching backwards in from the beginning of the hunk, not the first differing line. To reproduce: $ mkdir tmp $ cd tmp $ git init $ cat > foo.c

misleading diff-hunk header

[posted originally to git-users@ but advised this would be a better forum] diff.{type}.xfuncname seems to start searching backwards in from the beginning of the hunk, not the first differing line. To reproduce: $ mkdir tmp $ cd tmp $ git init $ cat > foo.c

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

Nguyen Thai Ngoc Duy wrote: > On Tue, Aug 21, 2012 at 12:17 PM, Jonathan Nieder wrote: >>> @@ -35,7 +35,7 @@ test_expect_success 'upload-pack fails due to error in >>> pack-objects packing' ' >>> printf "0032want %s\n0009done\n" \ >>> $(git rev-parse HEAD) >input && >

Re: misleading diff-hunk header

Tim Chase writes: > diff.{type}.xfuncname seems to start searching backwards in > from the beginning of the hunk, not the first differing line. [...] > @@ -4,4 +4,5 @@ int call_me(int maybe) > >int main() >{ > + return 0; >} > > misleadingly suggesting that the change occurred in

Re: misleading diff-hunk header

On 08/21/12 10:22, Thomas Rast wrote: > Tim Chase writes: > >> diff.{type}.xfuncname seems to start searching backwards in >> from the beginning of the hunk, not the first differing line. > [...] >> @@ -4,4 +4,5 @@ int call_me(int maybe) >> >>int main() >>{ >> + return 0; >>} >>

Re: [PATCH] Build in gettext poison feature unconditionally

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

Re: receive.denyNonNonFastForwards not denying force update

Jeff King writes: > You can get multiple warnings from this, as some programs read the > config multiple times. I don't think it's really worth caring about, as > you would want to fix such a misconfiguration quickly anyway. I agree that we wouldn't care too much about the multiple warnings, and

Re: receive.denyNonNonFastForwards not denying force update

Jeff King writes: > 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 e

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

On Mon, Aug 20, 2012 at 7:30 PM, Jeff King wrote: > 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

Re: How to request a fast-forward pull

Jeff King writes: > 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 req

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

Michael Haggerty writes: >> diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c >> index 6207ecd..a3e3fa3 100644 >> --- a/builtin/fetch-pack.c >> +++ b/builtin/fetch-pack.c >> @@ -546,7 +546,7 @@ static void filter_refs(struct ref **refs, int nr_match, >> char **match) >> for (ref = *r

Re: misleading diff-hunk header

Am 21.08.2012 17:42, schrieb Tim Chase: > On 08/21/12 10:22, Thomas Rast wrote: >>> misleadingly suggesting that the change occurred in the call_me() >>> function, rather than in main() >> >> I think that's intentional, and matches what 'diff -p' does... > > Okay...I tested "diff -p" and can't arg

Re: misleading diff-hunk header

Tim Chase writes: > On 08/21/12 10:22, Thomas Rast wrote: >> Tim Chase writes: >> >>> diff.{type}.xfuncname seems to start searching backwards in >>> from the beginning of the hunk, not the first differing line. >> [...] >>> @@ -4,4 +4,5 @@ int call_me(int maybe) >>> >>>int main() >>>

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

Jonathan Nieder writes: > Nguyen Thai Ngoc Duy wrote: >> On Tue, Aug 21, 2012 at 12:17 PM, Jonathan Nieder wrote: > @@ -35,7 +35,7 @@ test_expect_success 'upload-pack fails due to error in pack-objects packing' ' printf "0032want %s\n0009done\n" \

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

Jeff King writes: > So in other words, I do not think any ultimate destination that I find > palatable would be achievable without making the full format jump > anyway. If all things were equal, I'd say there is no reason not to get > as close as we can. But I find some of the proposals significa

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

Conley Owens writes: > On Mon, Aug 20, 2012 at 7:30 PM, Jeff King wrote: >> 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: [

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

On Tue, Aug 21, 2012 at 11:22 AM, Junio C Hamano wrote: > Conley Owens writes: > >> On Mon, Aug 20, 2012 at 7:30 PM, Jeff King wrote: >>> On Mon, Aug 20, 2012 at 06:28:57PM -0700, Conley Owens wrote: >>> From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001 From: Conle

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

Junio C Hamano writes: > Where do shells (e.g. bash and dash) go when you say "cd" without > parameter when $HOME is unset, for example? $ bash -c 'unset HOME; cd' bash: line 0: cd: HOME not set $ dash -c 'unset HOME; cd' [no output and cwd not changed] POSIX says: If no directory operand

Re: Test failures in t4034

Junio C Hamano wrote: > Ramsay Jones writes: > >> I had the same problem (or at least it *looks* like the same problem) on >> Linux >> last year (May 2011), which turned out to be a bug in the regex routines in >> an >> old version of glibc. >> >> I don't know OS X at all, so this may not be r

Re: [PATCH] fast_export.c: Fix a compiler warning

Florian Achleitner wrote: > On Sunday 19 August 2012 16:29:02 Ramsay Jones wrote: > Ok, I'll add it to the next version. This warning only occurs when building > for 32bit, thus I never saw it. There would be a format flag for printf that > sprecifies the platform's size_t integer type: "z". >

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

Thomas Gummerer wrote: > 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-v

[PATCH] precompompose_utf8.c: iconv_open_or_die

Add the function iconv_open_or_die(), which is used in both readdir() and precompose_argv() Optimized away one save/restore of errno, which is no longer nedded Signed-off-by: Torsten Bögershausen --- (Needs to be applied to pu) compat/precompose_utf8.c | 63 ---

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

Conley Owens writes: > Yes, that's the upstart I'm referring to. This makes sense. However, it's a > confusing situation to run into. Would a warning about an unset $HOME be > appropriate? Unsetting HOME is an easy way to skip what is in ~/.gitconfig when helping other people on this list, an

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 09:50:27AM -0700, Junio C Hamano wrote: > > Subject: [PATCH] gitignore: report access errors of exclude files > > > > When we try to access gitignore files, we check for their > > existence with a call to "access". We silently ignore > > missing files. However, if a file is

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

On Tue, Aug 21, 2012 at 12:22:18PM -0700, Junio C Hamano wrote: > Conley Owens writes: > > > Yes, that's the upstart I'm referring to. This makes sense. However, it's > > a > > confusing situation to run into. Would a warning about an unset $HOME be > > appropriate? > > Unsetting HOME is an

Re: Fix git-svn for SVN 1.7

Junio C Hamano wrote: > Unless you found a reason not to in the meantime, that is. Is what > I have on 'pu' still good, or do you (Eric and/or Michael) have any > updates you'd rather have me pull instead? No updates, everything is still good. -- To unsubscribe from this list: send the line "uns

Re: [PATCHv2 1/2] t6300: test sort with multiple keys

Kacper Kornet writes: > Documentation of git-for-each-ref says that --sort= option can be > used multiple times, in which case the last key becomes the primary key. > However this functionality was never checked in test suite and is > currently broken. This commit adds appropriate test in prepara

Re: Fix git-svn for SVN 1.7

Eric Wong writes: > Junio C Hamano wrote: >> Unless you found a reason not to in the meantime, that is. Is what >> I have on 'pu' still good, or do you (Eric and/or Michael) have any >> updates you'd rather have me pull instead? > > No updates, everything is still good. Thanks. -- To unsubscri

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

Florian Achleitner writes: > On Monday 20 August 2012 16:20:27 Junio C Hamano wrote: >> Junio C Hamano writes: >> > I think you meant something like: >> > >> > init_notes(NULL, notes_ref, NULL, 0); >> > >> > marksfile = fopen(marksfilename, "r"); >> > if (!marksfile) { >>

Re: [PATCH/RFC] git svn: don't introduce new paragraph for git-svn-id

Robert Luberda wrote: > I have been quite a busy recently, so it took me longer that I thought. No worries, thanks for following up. > It was quite hard for me to think some sensible option name, and finally > have chosen --trim-svn-log (svn.trimsvnlog as config key name). Please > let me know i

Re: receive.denyNonNonFastForwards not denying force update

Junio C Hamano writes: > Modulo the above "you might want to turn the call to warn() to > another helper that can be used from elsewhere", this patch looks > perfect to me. And that "modulo" is fairly simple if we wanted to go that route. attr.c| 2 +- dir.c | 2 +- git

Re: receive.denyNonNonFastForwards not denying force update

On Tue, Aug 21, 2012 at 02:52:02PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Modulo the above "you might want to turn the call to warn() to > > another helper that can be used from elsewhere", this patch looks > > perfect to me. > > And that "modulo" is fairly simple if we wan

Re: [PATCH/RFC] git svn: handle errors and concurrent commits in dcommit

Robert Luberda wrote: > While working on my next patch, I've accidentally discovered that bash gives > the following errors in the test file introduced in my commit : > > ./t9164-git-svn-dcommit-concrrent.sh: line 65: $hook: ambiguous redirect > ./t9164-git-svn-dcommit-concrrent.sh: line 66: $hoo

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

Nguyễn Thái Ngọc Duy writes: > 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. > > Sign

Re: [PATCH 1/2] git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip

Steven Walter wrote: > Consider the case where you have trunk, branch1 of trunk, and branch2 of > branch1. trunk is merged back into branch2, and then branch2 is > reintegrated into trunk. The merge of branch2 into trunk will have > svn:mergeinfo property references to both branch1 and branch2.

Re: Test failures in t4034

Ramsay Jones writes: > I think that, after some testing, this (or something like it) is the > best that we can do. What do you think? > > ATB, > Ramsay Jones > > -- >8 -- > Subject: [PATCH] test-regex: Add a test to check for a bug in the regex > routines > > Signed-off-by: Ramsay Jones > --- >

Re: misleading diff-hunk header

Johannes Sixt writes: > Am 21.08.2012 17:42, schrieb Tim Chase: >> On 08/21/12 10:22, Thomas Rast wrote: misleadingly suggesting that the change occurred in the call_me() function, rather than in main() >>> >>> I think that's intentional, and matches what 'diff -p' does... >> >> Okay..

Re: [PATCH/RFC] git svn: don't introduce new paragraph for git-svn-id

Eric Wong writes: > Robert Luberda wrote: >> I have been quite a busy recently, so it took me longer that I thought. > > No worries, thanks for following up. > >> It was quite hard for me to think some sensible option name, and finally >> have chosen --trim-svn-log (svn.trimsvnlog as config key

Re: [PATCH 1/2] git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip

Eric Wong writes: > Steven Walter wrote: >> Consider the case where you have trunk, branch1 of trunk, and branch2 of >> branch1. trunk is merged back into branch2, and then branch2 is >> reintegrated into trunk. The merge of branch2 into trunk will have >> svn:mergeinfo property references to

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

On Mon, 2012-08-20 at 11:50 -0700, Junio C Hamano wrote: > 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 m

Re: [RFC 0/2] svn-fetch|push - an alternate approach

On Tue, Aug 21, 2012 at 3:06 AM, Michael Haggerty wrote: > On 08/19/2012 12:21 PM, Marco Schulze wrote: >> It is a bit of a pain to work with libsvn, but I think it is worth using >> it, not only due to protocol support, but also due to ready-to-use >> support for SVN deltas and dumps. Pipelining

[PATCH] Support generate poison .mo files for testing

test-poisongen does a similar job to gettext poison feature except that it does it at build time. Gibberish .mo files are generated for all supported langauges and put in po/build/poison-locale. Target "poison-locale" is for this. User can run the test with these .mo files by setting POISON_LOCALE

Re: [PATCH] precompompose_utf8.c: iconv_open_or_die

On Wed, Aug 22, 2012 at 2:20 AM, Torsten Bögershausen wrote: > +static iconv_t iconv_open_or_die(const char* tocode, const char* fromcode) > +{ > + iconv_t my_iconv; > + my_iconv = iconv_open(tocode, fromcode); > + if (my_iconv == (iconv_t) -1) { > + die(_("iconv_op