* Re: [PATCH v2] completion: fix issue with process substitution not working on Git for Windows
From: Stefan Näwe @ 2011-10-27 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: spearce, git
In-Reply-To: <7vipnb1myv.fsf@alter.siamese.dyndns.org>
Am 26. Oktober 2011 23:07 schrieb Junio C Hamano <gitster@pobox.com>:
> Stefan Naewe <stefan.naewe@gmail.com> writes:
>
>> $ export GIT_PS1_SHOWUPSTREAM=1
>> sh.exe": cannot make pipe for process substitution: Function not implemented
>> sh.exe": cannot make pipe for process substitution: Function not implemented
>> sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect
>
> Are these the exact strings you want to have in the commit log message? I
> am particularly wondering about the dq after (but not around) 'sh.exe'.
Yes. That's exactly what I get.
Stefan
--
----------------------------------------------------------------
python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')"
^ permalink raw reply
* Recent gits corrupts repository
From: Øyvind A. Holm @ 2011-10-27 6:50 UTC (permalink / raw)
To: git
Something really weird is happening to a repository I'm working on, and
it's only a problem in recent Gits. A bisect shows that from
v1.7.6-1-g2548183 ("fix phantom untracked files when core.ignorecase is
set") and newer, this happens:
$ git clone git://gitorious.org/tz/tzfiles.git
Cloning into tzfiles...
remote: Counting objects: 358, done.
remote: Compressing objects: 100% (352/352), done.
remote: Total 358 (delta 8), reused 343 (delta 3)
Receiving objects: 100% (358/358), 44.15 MiB | 3.76 MiB/s, done.
Resolving deltas: 100% (8/8), done.
$ cd tzfiles/
$ git status
git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size)
>= (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
- 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
pagemask) == 0)' failed.
Aborted
$ git status
*** glibc detected *** git: free(): invalid next size (normal): 0x089f5588 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xb74d3591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xb74d4de8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb74d7ecd]
/lib/tls/i686/cmov/libc.so.6(+0x5c410)[0xb74c4410]
/lib/tls/i686/cmov/libc.so.6(fopen64+0x2c)[0xb74c69ec]
git[0x80c1fdd]
git[0x811b82b]
git[0x80637ea]
git[0x804bc87]
git[0x804be93]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb747ebd6]
git[0x804b521]
======= Memory map: ========
08048000-08160000 r-xp 00000000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08160000-08161000 r--p 00117000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08161000-08166000 rw-p 00118000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08166000-081b0000 rw-p 00000000 00:00 0
089ec000-08a0d000 rw-p 00000000 00:00 0 [heap]
b7300000-b7321000 rw-p 00000000 00:00 0
b7321000-b7400000 ---p 00000000 00:00 0
b7444000-b7461000 r-xp 00000000 ca:00 24591 /lib/libgcc_s.so.1
b7461000-b7462000 r--p 0001c000 ca:00 24591 /lib/libgcc_s.so.1
b7462000-b7463000 rw-p 0001d000 ca:00 24591 /lib/libgcc_s.so.1
b7463000-b7464000 rw-p 00000000 00:00 0
b7464000-b7466000 r-xp 00000000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7466000-b7467000 r--p 00001000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7467000-b7468000 rw-p 00002000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7468000-b75bb000 r-xp 00000000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bb000-b75bc000 ---p 00153000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bc000-b75be000 r--p 00153000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75be000-b75bf000 rw-p 00155000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bf000-b75c3000 rw-p 00000000 00:00 0
b75c3000-b75d8000 r-xp 00000000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75d8000-b75d9000 r--p 00014000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75d9000-b75da000 rw-p 00015000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75da000-b75dc000 rw-p 00000000 00:00 0
b75dc000-b7714000 r-xp 00000000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b7714000-b771c000 r--p 00137000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b771c000-b772a000 rw-p 0013f000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b772a000-b772e000 rw-p 00000000 00:00 0
b772e000-b7741000 r-xp 00000000 ca:00 24635 /lib/libz.so.1.2.3.3
b7741000-b7742000 r--p 00012000 ca:00 24635 /lib/libz.so.1.2.3.3
b7742000-b7743000 rw-p 00013000 ca:00 24635 /lib/libz.so.1.2.3.3
b774b000-b774f000 rw-p 00000000 00:00 0
b774f000-b776a000 r-xp 00000000 ca:00 25083 /lib/ld-2.11.1.so
b776a000-b776b000 r--p 0001a000 ca:00 25083 /lib/ld-2.11.1.so
b776b000-b776c000 rw-p 0001b000 ca:00 25083 /lib/ld-2.11.1.so
bfc1b000-bfc3c000 rw-p 00000000 00:00 0 [stack]
f57fe000-f57ff000 r-xp 00000000 00:00 0 [vdso]
Aborted
$
Reverting 2548183 fixes the problem.
It also seems that the behaviour is not consistent. Sometimes, after
running the second "git status", this happens:
$ git st
error: index uses extension, which we do not understand
fatal: index file corrupt
And no, this is not memory corruption or something like that, the same
thing happens on my laptop.
Another curious thing: When using an earlier git (for example v1.7.6 in
the example below) on this repo after a "git status" with a recent git,
it segfaults. This indicates that recents Gits messes up something so
even old gits won't work in that repo anymore. This is the last lines of
an strace:
open(".git/objects/pack",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 4 entries */, 32768) = 192
access(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.keep",
F_OK) = -1 ENOENT (No such file or directory)
stat64(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.pack",
{st_mode=S_IFREG|0444, st_size=46297839, ...}) = 0
getdents64(3, /* 0 entries */, 32768) = 0
close(3) = 0
open(".git/objects/info/alternates", O_RDONLY|O_LARGEFILE|O_NOATIME)
= -1 ENOENT (No such file or directory)
open(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.idx",
O_RDONLY|O_LARGEFILE|O_NOATIME) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=11096, ...}) = 0
mmap2(NULL, 11096, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76e1000
close(3) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
open(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.pack",
O_RDONLY|O_LARGEFILE|O_NOATIME) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=46297839, ...}) = 0
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "PACK\0\0\0\2\0\0\1f", 12) = 12
_llseek(3, 46297819, [46297819], SEEK_SET) = 0
read(3, ",j\212\0375c\335\0k\244)\256\376\24\v\344\6]0\230", 20) = 20
mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb53fc000
open(".git/info/grafts", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open(".git/shallow", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
brk(0x977e000) = 0x977e000
open("/proc/meminfo", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb76e0000
read(4, "MemTotal: 1028684 kB\nMemF"..., 1024) = 1024
close(4) = 0
munmap(0xb76e0000, 4096) = 0
access(".git/info/exclude", R_OK) = 0
open(".git/info/exclude", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=240, ...}) = 0
read(4, "# git ls-files --others --exclud"..., 240) = 240
close(4) = 0
access("/home/sunny/src/git/home-sunny/.gitexclude", R_OK) = 0
open("/home/sunny/src/git/home-sunny/.gitexclude", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=86, ...}) = 0
read(4, "\n# ~/.gitexclude\n# File ID: bcf6"..., 86) = 86
close(4) = 0
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
getdents64(4, /* 7 entries */, 32768) = 216
open(".gitignore", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Complete strace dump is stored at https://gist.github.com/1318830 .
I'm currently using 1.7.7.419.g87009 , compiled with a regular "make"
from the master branch. A quick test with newest master
(v1.7.7.1-475-g997a194) shows the same error. Not installed properly,
though, as I haven't run the test suite yet.
System info:
Ubuntu 10.04.3 LTS
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303
Same thing happens with Ubuntu 10.10 on my laptop.
Even when creating a bundle and recloning, this happens. Also when
initialising a new, clean repo and fetching from the original local
clone, same story.
The repository was created on 2011-10-08 06:54:00 +0200, and because I
create a tag everytime I compile (using
<https://github.com/sunny256/utils/blob/master/build-git>), I know the
repository was created with git v1.7.7-138-g7f41b6b.
Because Gmail probably will wrap long lines, a copy of this message is
stored at <https://gist.github.com/1318935>.
Regards,
Øyvind
^ permalink raw reply
* Re: Problem with git svn clone --authors-file
From: Michael Haggerty @ 2011-10-27 6:58 UTC (permalink / raw)
To: edman747; +Cc: git
In-Reply-To: <CABDh3gSsi9xwvw-6stw7URGK112LvF8Rt4XJeTwGM3q-tML=2Q@mail.gmail.com>
On 10/27/2011 01:51 AM, edman747 wrote:
> Hello,
> Attempting to clone a remote svn repo where I don't know all the
> previous SVN author names.
> installed msysgit (vista)
> gitbash,
> $ mkdir test
> $ cd test
>
> create authors file with a few known authors.
>
> $ git svn clone --authors-file=authors http://svn.repo/trunk
> ...
> runs fine until
> Author: (no author) not defined in authors file
>
> edit authors file add line: (no author) = none <email>
>
> ------
> rerun previous git svn command
>
> $ git svn clone --authors-file=authors http://svn.repo/trunk
> Using existing [svn-remote "svn"]
> svn-remote.svn.fetch already set to track :refs/remotes/git-svn
I'm not quite sure what your complaint is.
"git svn clone" is equivalent to a "git svn init" followed by "git svn
fetch". I would have thought that by the time "git svn clone" notices a
problem with the authors file, it would already be in the "git svn
fetch" phase. So it seems to me that after the first "clone" fails, one
should probably run "git svn fetch" instead of "git svn clone" again.
If this is the case (and the cause of your problem), then the
documentation and error message should be made clearer.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Recent gits corrupts repository
From: Matthieu Moy @ 2011-10-27 7:00 UTC (permalink / raw)
To: Øyvind A. Holm; +Cc: git
In-Reply-To: <CAA787rnrG-mLRpq_a3xbbUyYuHz1kfdOzMqHQpxhBwc0rjt3Ww@mail.gmail.com>
Øyvind A. Holm <sunny@sunbase.org> writes:
> $ git status
> git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
> (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
> malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size)
>>= (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
> fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
> - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
> pagemask) == 0)' failed.
> Aborted
This looks very much like
http://thread.gmane.org/gmane.comp.version-control.git/184094
for which a patch is pending in "next":
8f41c07 read-cache.c: fix index memory allocation
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Recent gits corrupts repository
From: Øyvind A. Holm @ 2011-10-27 7:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk47qc40s.fsf@bauges.imag.fr>
On 27 October 2011 09:00, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Øyvind A. Holm <sunny@sunbase.org> writes:
> > $ git status
> > git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
> > (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
> > malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size)
> > >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
> > fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
> > - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
> > pagemask) == 0)' failed.
> > Aborted
>
> This looks very much like
>
> http://thread.gmane.org/gmane.comp.version-control.git/184094
>
> for which a patch is pending in "next":
>
> 8f41c07 read-cache.c: fix index memory allocation
Argh, that was some wasted hours, should have searched the mailing list
first. But hey, I'm not complaining. :) Glad there's a fix coming up. I
cherry-picked 8f41c07, and it seems to work nicely. Thanks.
Regards,
Øyvind
^ permalink raw reply
* Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory()
From: Nguyen Thai Ngoc Duy @ 2011-10-27 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxcn3b8w.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 4:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> Current read_directory() treats given path separately from contents
>> inside the path. If the given path has ".git", it's ok (but it'll stop
>> at .git if during tree recursion). The new read_directory() does not
>> make this exception, so when note-merge call
>> read_directory(".git/NOTES_MERGE_WORKTREE"), read_directory() sees
>> ".git" and stops immediately, assuming it's a gitlink.
>
> When read_directory("where/ever") is called, what kind of paths does it
> collect? Do the paths the function collects share "where/ever" as their
> common prefix? I thought it collects the paths relative to whatever
> top-level directory given to the function, so that "where/ever" could be
> anything.
Correct. But read_directory() takes pathspec now so naturally it does
not treat "where/ever" a common prefix anymore. So it has to open(".")
and starts from there. Even current code does not trust "where/ever"
completely. treat_leading_path() may dismiss "where/ever" if it's
excluded by .gitignore.
> Why does it even have to look at the given path in the first place and
> make a decision heavier than "can I opendir() and read from it"?
Because opendir("wh*/*r") may fail.
> In other
> words, if you see read_directory("some/thing/.git/more/stuff") and find a
> substring ".git/" in there, what "magic" gitlink handling does the code
> have to do?
"some/thing/.git" can be considered a new entry in index, so it should
stop traversing at ".git". But because "some/thing/.git" does not
exacly match "some/thing/.git/more/stuff", it is filtered out.
git-add deals with this case especially in order to avoid accidentally
replace "some/thing/.git" in index with "some/thing/.git/more/stuff".
But I feel it should be handled by read_directory(), not git-add.
> I do not think it matters for _this_ particular case, but I can for
> example imagine an alternative implementation of a merge that uses
> temporary working tree somewhere other than the main working tree, and one
> of the natural "temporary" places such a feature in the future may want to
> use is inside .git/ somewhere. If you are planning to close the door by
> breaking the behaviour of read_directory(".git/some_where") for such
> callers with this series, we need to be aware of it, and that is why I am
> not satisfied by your explanation.
Maybe I should step back a bit. Instead of treating any input to
read_directory() as pathspec, callers may provide two sets: a prefix
set and a pathspec set. read_directory() starts from the prefix set
without any checks, then descends in using pathspec.
But then what about the "if (treat_one_path(..) == path_ignored)" in
treat_leading_path()? Remove it?
--
Duy
^ permalink raw reply
* Re: [PATCH/WIP 03/11] t5403: avoid doing "git add foo/bar" where foo/.git exists
From: Nguyen Thai Ngoc Duy @ 2011-10-27 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr51z3bqx.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 4:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> - reads content of current directory, it sees "clone2" as a directory
>> - it descends in and see ".git" so "clone2" must be a git link
>> - because clone2 is a separate repository (again $GIT_DIR is not
>> consulted), "b" should be managed by "clone2"
>> - so it stops.
>>
>> This is the only place I see a submodule (from the first glance) is
>> actually top level repository. Yes I guess we can support this, but
>> it's just too weird to be widely used in pratice..
>
> Where did you get this idea that submodule is somehow involved in this test?
Because "clone2" looks like a submodule (it has ".git" inside with valid HEAD)
> I do not see there is any submodules involved; the test uses two
> repositories 1 and 2 that appear in the working tree of the main
> repository test infrastructure created, but otherwise there is no
> sub/super relation among these three, and there are many other tests with
> "clone" or "mkdir+init" or "init <newdir>" in the main test repository.
If I tweak the test a bit
git clone ./. clone2 &&
GIT_DIR=clone2/.git git add clone2 &&
GIT_DIR=clone2/.git git add clone2/b
then the last command fails with "Path 'clone2/b' is in submodule
'clone2'". So clone2 could be a submodule from that perspective. Doing
the the other way around
git clone ./. clone2 &&
GIT_DIR=clone2/.git git add clone2/b &&
GIT_DIR=clone2/.git git add clone2
"clone2" is not just a normal path. Should we stick with one way only?
--
Duy
^ permalink raw reply
* Re: [PATCH v2] completion: fix issue with process substitution not working on Git for Windows
From: SZEDER Gábor @ 2011-10-27 9:05 UTC (permalink / raw)
To: Stefan Naewe; +Cc: spearce, git, gitster
In-Reply-To: <1319656389-9515-1-git-send-email-stefan.naewe@gmail.com>
On Wed, Oct 26, 2011 at 09:13:09PM +0200, Stefan Naewe wrote:
> Git for Windows comes with a bash that doesn't support process substitution.
> It issues the following error when using git-completion.bash with
> GIT_PS1_SHOWUPSTREAM set:
>
> $ export GIT_PS1_SHOWUPSTREAM=1
> sh.exe": cannot make pipe for process substitution: Function not implemented
> sh.exe": cannot make pipe for process substitution: Function not implemented
> sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect
>
> Replace the process substitution with a 'here string'.
>
> Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
> ---
> contrib/completion/git-completion.bash | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 8648a36..0b3d47e 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -110,6 +110,7 @@ __git_ps1_show_upstream ()
> local upstream=git legacy="" verbose=""
>
> # get some config options from git-config
> + output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> while read key value; do
> case "$key" in
> bash.showupstream)
> @@ -125,7 +126,7 @@ __git_ps1_show_upstream ()
> upstream=svn+git # default upstream is SVN if available, else git
> ;;
> esac
> - done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')
> + done <<< "$output"
The $output variable is not declared as local and therefore it leaks
into the environment. But instead of declaring it local, why not
eliminate it altogether, and use the "$(git config ....)" command
substitution as here string?
Gábor
^ permalink raw reply
* Re: [PATCH v2] completion: fix issue with process substitution not working on Git for Windows
From: Jonas Berlin @ 2011-10-27 10:27 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Stefan Naewe, spearce, git, gitster
In-Reply-To: <20111027090530.GA23424@goldbirke>
On Thu, 27 Oct 2011 11:05:30 +0200
SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Wed, Oct 26, 2011 at 09:13:09PM +0200, Stefan Naewe wrote:
> > Git for Windows comes with a bash that doesn't support process substitution.
> > It issues the following error when using git-completion.bash with
> > GIT_PS1_SHOWUPSTREAM set:
> >
> > $ export GIT_PS1_SHOWUPSTREAM=1
> > sh.exe": cannot make pipe for process substitution: Function not implemented
> > sh.exe": cannot make pipe for process substitution: Function not implemented
> > sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect
> >
> > Replace the process substitution with a 'here string'.
> >
> > Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
> > ---
> > contrib/completion/git-completion.bash | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 8648a36..0b3d47e 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -110,6 +110,7 @@ __git_ps1_show_upstream ()
> > local upstream=git legacy="" verbose=""
> >
> > # get some config options from git-config
> > + output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> > while read key value; do
> > case "$key" in
> > bash.showupstream)
> > @@ -125,7 +126,7 @@ __git_ps1_show_upstream ()
> > upstream=svn+git # default upstream is SVN if available, else git
> > ;;
> > esac
> > - done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')
> > + done <<< "$output"
>
> The $output variable is not declared as local and therefore it leaks
> into the environment. But instead of declaring it local, why not
> eliminate it altogether, and use the "$(git config ....)" command
> substitution as here string?
Wouldn't this work:
git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ' | \
while read key value; do
...
done
- xkr47
^ permalink raw reply
* Re: [PATCH v2] completion: fix issue with process substitution not working on Git for Windows
From: Jonas Berlin @ 2011-10-27 10:40 UTC (permalink / raw)
To: Jonas Berlin; +Cc: SZEDER Gábor, Stefan Naewe, spearce, git, gitster
In-Reply-To: <20111027132754.1503b98b@outerspace.dyndns.org>
On Thu, 27 Oct 2011 13:27:54 +0300
Jonas Berlin <xkr47@outerspace.dyndns.org> wrote:
> On Thu, 27 Oct 2011 11:05:30 +0200
> SZEDER Gábor <szeder@ira.uka.de> wrote:
> > The $output variable is not declared as local and therefore it leaks
> > into the environment. But instead of declaring it local, why not
> > eliminate it altogether, and use the "$(git config ....)" command
> > substitution as here string?
>
> Wouldn't this work:
>
> git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ' | \
> while read key value; do
> ...
> done
Sorry, please disregard, I didn't notice it was already dismissed in v1 of the PATCH..
- xkr47
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Sverre Rabbelier @ 2011-10-27 11:06 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAOpHH-VEhtOg6ai5p9VxWBKA3AFpG3meiJVGrWR4j68ffyQ6Bg@mail.gmail.com>
Heya,
On Tue, Oct 25, 2011 at 11:56, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Mon, Oct 24, 2011 at 7:01 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> I for one welcome our new branch deleting overlords :).
>>
>> You mention that checkpointing solves some of the concerns raised by
>> others in this thread, would automatic checkpointing be way to make
>> sure everything is as it should be?
>
> Apparently I did not explain myself correctly. Let me try again :)
>
> This is what I am doing:
>
> 1) import topic
> 2) checkpoint
> 3) diff-tree and processing
> 4) exit if processing returns ok
> 5) reset topic to another HEAD
> 6) goto 1)
>
> In this scenario it is the checkpoint that "breaks" everything because
> it will write the original tree to disk. When fast-import exits it will
> find the old tree on disk but not within "topic" tree.
I'm afraid I don't understand why it's a bad thing that fast-import
will find the old tree on disk, won't it just be gc-ed if it is no
longer used?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-10-27 11:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAGdFq_iY92Gc=WLFVVMpi8w5JNZMo5bSk5=wjHyCmjXmP4RXrQ@mail.gmail.com>
On Thu, Oct 27, 2011 at 12:06 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> I'm afraid I don't understand why it's a bad thing that fast-import
> will find the old tree on disk, won't it just be gc-ed if it is no
> longer used?
No, because fast-import actively checks this to make sure the frontend
script did not do anything wrong during the import. I think the check
makes sense and may help debugging a corner case the frontend script
does not support. So, using "--force" is also not a solution because it
ignores everything and not only the specific commits I want to leave
behind.
Vitor
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Sverre Rabbelier @ 2011-10-27 14:36 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAOpHH-W30umoP6CuvrXgiSPBC2NjLvNWUX0uxhU4SU3kBB4H-A@mail.gmail.com>
Heya,
On Thu, Oct 27, 2011 at 13:22, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Thu, Oct 27, 2011 at 12:06 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> I'm afraid I don't understand why it's a bad thing that fast-import
>> will find the old tree on disk, won't it just be gc-ed if it is no
>> longer used?
>
> No, because fast-import actively checks this to make sure the frontend
> script did not do anything wrong during the import. I think the check
> makes sense and may help debugging a corner case the frontend script
> does not support. So, using "--force" is also not a solution because it
> ignores everything and not only the specific commits I want to leave
> behind.
Ok, so the problem is that fast-import notices that a tree that was
written out as part of a checkpoint is later removed and doesn't like
that? Shouldn't we just teach the check about trees deleted by the
drop command?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git grep: be careful to use mutices only when they are initialized
From: René Scharfe @ 2011-10-27 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, msysgit
In-Reply-To: <7vmxcn1pob.fsf@alter.siamese.dyndns.org>
Am 26.10.2011 22:08, schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The remainder of this message are hints and random thoughts on potential
>> follow-up patches that may want to build on top of this patch for further
>> clean-ups (not specifically meant for Dscho but for other people on both
>> mailing lists).
>> ...
>> - Could we lose "#ifndef NO_PTHREADS" inside grep_sha1(), grep_file(),
>> and possibly cmd_grep() functions and let the compiler optimize things
>> away under NO_PTHREADS compilation?
>
> I suspect that the result of the conversion would look a lot cleaner if
> the code is first cleaned up to move global variable like skip_first_line
> and the mutexes into the grep_opt structure. Without such clean-up, I do
> not think a conversion like this does not add much value.
Each thread get its own copy of the grep_opt struct, but the mutexes and
also skip_first_line must not be duplicated. They could be moved into a
new struct that is pointed to by grep_opt, but I'm not sure it's a win.
René
^ permalink raw reply
* Re: Is there a place for benchmarking scripts?
From: René Scharfe @ 2011-10-27 16:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4EA7D7E3.2020009@alum.mit.edu>
Am 26.10.2011 11:50, schrieb Michael Haggerty:
> I've been doing a lot of benchmarking of git performance in the presence
> of lots of references. I've written a few scripts to automate the
> benchmarking [1]. They are not beautiful and would require a couple of
> local adjustments [2,3]. They are too time-consuming to be made part of
> the usual test suite. I wouldn't want to commit to maintaining them.
> But they have certainly been useful to me, and they generate readable
> output [4].
>
> My question is: would such benchmarking scripts be welcome within the
> git project? If so, where should I put it? Is any benchmarking
> code/framework already in use?
That would be nice. A whole performance regression testing suite would
be even nicer and can perhaps be built piece by piece.
We have contrib/ and we have the test-* commands; t/ doesn't seem to fit
too well with its focus on OK or fail.
René
^ permalink raw reply
* Credentials and the Secrets API...
From: John Szakmeister @ 2011-10-27 16:05 UTC (permalink / raw)
To: git
Just wanted to keep folks in the loop. It turns out that the Secrets
API is still to young. I asked about the format to store credentials
in (as far as attributes), and got a response from a KDE developer
that says it's still to young on their front. They hope to have
support in the next release of KDE. But there's still the issue of
what attributes to use.
With that information, I went ahead and created a
gnome-credential-keyring that uses Gnome's Keyring facility. I still
need to do a few more things (mainly run it against Jeff's tests), but
it's generally working. Just wanted to keep folks in the loop.
Hopefully, I can get patches out this weekend.
Jeff: it would be really excellent to break out the various pieces. I
think it would also be better to split the asking for passwords from
the storing of passwords.
-John
^ permalink raw reply
* [PATCH] Fix 'Cloning into' message
From: Richard Hartmann @ 2011-10-27 16:46 UTC (permalink / raw)
To: git, gitster; +Cc: Richard Hartmann
In-Reply-To: <1319648748-9150-1-git-send-email-richih.mailinglist@gmail.com>
Without this patch,
git clone foo .
results in this:
Cloning into ....
done.
With it:
Cloning into '.'...
done.
Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com>
---
builtin/clone.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 488f48e..efe8b6c 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -577,9 +577,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (0 <= option_verbosity) {
if (option_bare)
- printf(_("Cloning into bare repository %s...\n"), dir);
+ printf(_("Cloning into bare repository '%s'...\n"), dir);
else
- printf(_("Cloning into %s...\n"), dir);
+ printf(_("Cloning into '%s'...\n"), dir);
}
init_db(option_template, INIT_DB_QUIET);
write_config(&option_config);
--
1.7.7
^ permalink raw reply related
* Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory()
From: Junio C Hamano @ 2011-10-27 17:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8C4iHffr4UYP9SvCU0OPC-LocUORwAQ492LqaV_tyvFQA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> When read_directory("where/ever") is called, what kind of paths does it
>> collect? Do the paths the function collects share "where/ever" as their
>> common prefix? I thought it collects the paths relative to whatever
>> top-level directory given to the function, so that "where/ever" could be
>> anything.
>
> Correct. But read_directory() takes pathspec now so naturally it does
> not treat "where/ever" a common prefix anymore. So it has to open(".")
> and starts from there.
That is a puzzling statement. The read_directory() function takes:
- dir: use this struct to pass traversal status and collected paths;
- path, len: this is the directory (not a pathspec) we start traversal
from; and
- pathspec: these are the patterns that specify which parts of the
directory hierarchy under <path,len> are traversed.
I do not see any good reason for <path,len> to become a match pattern. Are
you trying to get it prepended to elements in pathspec[] and match the path
collected including the <path> part?
Why?
I could see that "open . and start from there, treating as if <path,len>
is also pathspec" could be made to work, but I do not see why that is
desirable.
In other words, are there existing callers that abuse read_directory()
to feed a pattern in <path,len>? Maybe they should be the one that needs
fixing instead?
^ permalink raw reply
* Re: [PATCH] gitweb/Makefile: Remove static/gitweb.js in the clean target
From: Ramsay Jones @ 2011-10-26 21:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Drew Northup, Junio C Hamano, GIT Mailing-list
In-Reply-To: <201110260236.59509.jnareb@gmail.com>
Jakub Narebski wrote:
> Drew Northup napisał:
>> On Tue, 2011-10-25 at 18:15 +0100, Ramsay Jones wrote:
>>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>> ---
>>> gitweb/Makefile | 4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/gitweb/Makefile b/gitweb/Makefile
>>> index 1c85b5f..4191c6b 100644
>>> --- a/gitweb/Makefile
>>> +++ b/gitweb/Makefile
>>> @@ -185,7 +185,9 @@ install: all
>>> ### Cleaning rules
>>>
>>> clean:
>>> - $(RM) gitweb.cgi static/gitweb.min.js static/gitweb.min.css GITWEB-BUILD-OPTIONS
>>> + $(RM) gitweb.cgi static/gitweb.js \
>>> + static/gitweb.min.js static/gitweb.min.css \
>>> + GITWEB-BUILD-OPTIONS
>>>
>>> .PHONY: all clean install test test-installed .FORCE-GIT-VERSION-FILE FORCE
>>>
>> Forgive me for sounding a bit numb, but what does this fix? I don't see
>> it in the commit message.
>
> gitweb.js is nowadays a generated file. Though that bit should be
> in commit message...
Yep, will do ...
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 0/2] git-credential-cache--daemon on Cygwin
From: Ramsay Jones @ 2011-10-27 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: GIT Mailing-list
In-Reply-To: <20111022191509.GB1785@sigill.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 22, 2011 at 06:23:25PM +0100, Ramsay Jones wrote:
>
>> Assuming that a modified http-auth-keyring series will make a return to pu
>> sometime, could you please squash these patches into (the patch corresponding to)
>> commit 2d6874d (credentials: add "cache" helper, 18-07-2011). Thanks!
>
> I'm planning a reroll, so I'll squash them (or something similar) in.
Thanks!
> It's definitely coming back, so if you feel like working on it, please
> do. Also note that if it would be easier to have an alternate
> abstraction for inter-process communication on windows, I'm open to
> doing that in the cache daemon.
My initial reaction was to use a "named pipe" (aka fifo), but on reflection,
I don't think it would be any easier; the unix socket emulation should not be too
difficult (famous last words!). :-D
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 1/2] credential-cache--daemon.c: Don't leave stale socket on --exit
From: Ramsay Jones @ 2011-10-27 17:29 UTC (permalink / raw)
To: Jeff King; +Cc: GIT Mailing-list
In-Reply-To: <20111022191711.GC1785@sigill.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 22, 2011 at 06:24:51PM +0100, Ramsay Jones wrote:
>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>> ---
>> credential-cache--daemon.c | 23 ++++++++++++-----------
>> 1 files changed, 12 insertions(+), 11 deletions(-)
>
> Looks sane, and I'll probably squash it in. Alternatively, we could also
> set a signal/exit handler to clean up our socket when we die. That would
> also cover the error exit cases.
I considered this, *very* briefly, but decided it wasn't worth the effort
or complexity.
> In either case, I think we need to handle stale sockets better. They
> will happen eventually due to power loss or kill -9, anyway.
Indeed, hence patch #2. ;-)
I suspect that, given the current code, the *vast* majority of stale sockets
would be (somewhat gratuitously) created by the --exit action - hence this
patch. :-P
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Fix 'Cloning into' message
From: Junio C Hamano @ 2011-10-27 17:39 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <1319734013-8956-1-git-send-email-richih.mailinglist@gmail.com>
Richard Hartmann <richih.mailinglist@gmail.com> writes:
> Without this patch,
>
> git clone foo .
>
> results in this:
>
> Cloning into ....
> done.
>
> With it:
>
> Cloning into '.'...
> done.
>
> Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com>
We try to be consistent and many places do quote user supplied paths in
pair of single quotes in human readable messages, and this is in line with
that pattern.
$ git clone foo "joey's foo"
would result in
Cloning into 'joey's foo'...
but that is probably Ok ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH/WIP 03/11] t5403: avoid doing "git add foo/bar" where foo/.git exists
From: Junio C Hamano @ 2011-10-27 17:41 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8C2nUJkN5=E7p2u_wjHqWy7EC_BS3Sr4+_QgunWHDdtKg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Thu, Oct 27, 2011 at 4:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Where did you get this idea that submodule is somehow involved in this test?
>
> Because "clone2" looks like a submodule (it has ".git" inside with valid HEAD)
But there is a crucial difference between "it looks like" and "it is". If
it is not a submodule, and the established behaviour is not to treat it
like a submodule, then we shouldn't suddenly change our behaviour to start
treating as one.
> ... Should we stick with one way only?
Whatever we have been doing should not change, especially in corner cases.
^ permalink raw reply
* Re: [PATCH 0/2] git-credential-cache--daemon on Cygwin
From: Jeff King @ 2011-10-27 17:41 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EA99266.7030002@ramsay1.demon.co.uk>
On Thu, Oct 27, 2011 at 06:18:30PM +0100, Ramsay Jones wrote:
> > It's definitely coming back, so if you feel like working on it, please
> > do. Also note that if it would be easier to have an alternate
> > abstraction for inter-process communication on windows, I'm open to
> > doing that in the cache daemon.
>
> My initial reaction was to use a "named pipe" (aka fifo), but on reflection,
> I don't think it would be any easier; the unix socket emulation should not be too
> difficult (famous last words!). :-D
The problem with named pipes is that all clients share the same pipe. So
if two clients connect, their writes will be intermingled at the server,
and they will both get the responses for each other. Assuming your
platform provides atomic write() over pipes, you could design a
packet-ized protocol, and just have clients ignore packets not meant for
them. But that's getting pretty complex.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] credential-cache--daemon.c: Don't leave stale socket on --exit
From: Jeff King @ 2011-10-27 17:42 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EA9950A.9020208@ramsay1.demon.co.uk>
On Thu, Oct 27, 2011 at 06:29:46PM +0100, Ramsay Jones wrote:
> Jeff King wrote:
> > On Sat, Oct 22, 2011 at 06:24:51PM +0100, Ramsay Jones wrote:
> >
> >> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> >> ---
> >> credential-cache--daemon.c | 23 ++++++++++++-----------
> >> 1 files changed, 12 insertions(+), 11 deletions(-)
> >
> > Looks sane, and I'll probably squash it in. Alternatively, we could also
> > set a signal/exit handler to clean up our socket when we die. That would
> > also cover the error exit cases.
>
> I considered this, *very* briefly, but decided it wasn't worth the effort
> or complexity.
Actually, I think with the sigchain code, it would only end up as a few
lines. I'll probably take a look when I re-roll.
Thanks for your patches.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox