* What's cooking in git.git (Oct 2011, #10; Wed, 26)
From: Junio C Hamano @ 2011-10-27 0:40 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
It probably is a good point to stop taking new topics and start
switching our focus to fixing bugs in the topics already in 'master'.
Here are the repositories that have my integration branches:
With maint, master, next, pu and todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
I will stop pushing the generated documentation branches to the above
repositories, as they are not sources. The only reason the source
repository at k.org has hosted these branches was because it was the only
repository over there that was writable by me; it was an ugly historical
and administrative workaround and not a demonstration of the best
practice.
These branches are pushed to their own separate repositories instead:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* ef/mingw-upload-archive (2011-10-26) 3 commits
- upload-archive: use start_command instead of fork
- compat/win32/poll.c: upgrade from upstream
- mingw: move poll out of sys-folder
* js/grep-mutex (2011-10-26) 3 commits
(merged to 'next' on 2011-10-26 at 6fac2d6)
+ builtin/grep: simplify lock_and_read_sha1_file()
+ builtin/grep: make lock/unlock into static inline functions
+ git grep: be careful to use mutexes only when they are initialized
Will merge to "master" shortly.
* rj/gitweb-clean-js (2011-10-26) 1 commit
(merged to 'next' on 2011-10-26 at db36a24)
+ gitweb/Makefile: Remove static/gitweb.js in the clean target
Will merge to "master" shortly.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
- cache.h: put single NUL at end of struct cache_entry
- read-cache.c: allocate index entries individually
* rs/maint-estimate-cache-size (2011-10-26) 1 commit
(merged to 'next' on 2011-10-26 at 2f11375)
+ read-cache.c: fix index memory allocation
Will merge to "master" shortly.
* sn/complete-bash-wo-process-subst (2011-10-26) 1 commit
(merged to 'next' on 2011-10-26 at 8662ed6)
+ completion: fix issue with process substitution not working on Git for Windows
Will merge to "master" shortly.
--------------------------------------------------
[Graduated to "master"]
* cn/fetch-prune (2011-10-15) 5 commits
(merged to 'next' on 2011-10-16 at 02a449e)
+ fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
+ fetch: honor the user-provided refspecs when pruning refs
+ remote: separate out the remote_find_tracking logic into query_refspecs
+ t5510: add tests for fetch --prune
+ fetch: free all the additional refspecs
"git fetch --prune" used to prune remote tracking branches by comparing
what was actually fetched and what was configured to be fetched, which was
wrong.
* jm/maint-gitweb-filter-forks-fix (2011-10-21) 1 commit
(merged to 'next' on 2011-10-21 at debedcd)
+ gitweb: fix regression when filtering out forks
* jn/libperl-git-config (2011-10-21) 2 commits
(merged to 'next' on 2011-10-21 at 76e2d4b)
+ Add simple test for Git::config_path() in t/t9700-perl-git.sh
+ libperl-git: refactor Git::config_*
* lh/gitweb-site-html-head (2011-10-21) 1 commit
(merged to 'next' on 2011-10-23 at 65075df)
+ gitweb: provide a way to customize html headers
* mm/mediawiki-author-fix (2011-10-20) 1 commit
(merged to 'next' on 2011-10-23 at 9f85b67)
+ git-remote-mediawiki: don't include HTTP login/password in author
* tc/submodule-clone-name-detection (2011-10-21) 2 commits
(merged to 'next' on 2011-10-23 at c18af03)
+ submodule::module_clone(): silence die() message from module_name()
+ submodule: whitespace fix
"git submodule clone" used to show unnecessary error message when
submodule mapping from name to path is not found in .gitmodules file.
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
- gitweb: add a feature to show side-by-side diff
- gitweb: change format_diff_line() to remove leading SP from $diff_class
Fun.
Will keep in 'pu' until the planned re-roll comes.
--------------------------------------------------
[Cooking]
* nd/pretty-commit-log-message (2011-10-23) 2 commits
- pretty.c: use original commit message if reencoding fails
- pretty.c: free get_header() return value
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
It is either merge this quickly to 'master' and hope there won't be any
more unexpected breakage that forces us to delay the release, or hold it
on 'next' until the next cycle. I am inclined to do the former, but not
quite ready to commit to it yet.
* dm/pack-objects-update (2011-10-20) 4 commits
- pack-objects: don't traverse objects unnecessarily
- pack-objects: rewrite add_descendants_to_write_order() iteratively
- pack-objects: use unsigned int for counter and offset values
- pack-objects: mark add_to_write_order() as inline
Need to re-read this before deciding what to do; it came a bit too late in
the cycle for a series that touches a seriously important part of the
system.
* jk/git-tricks (2011-10-21) 3 commits
(merged to 'next' on 2011-10-23 at 7c9bf71)
+ completion: match ctags symbol names in grep patterns
+ contrib: add git-jump script
+ contrib: add diff highlight script
As this stuff is in contrib/ I do not care too much about the stability.
Will merge to 'master' unless there is strong objection.
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' until an Ack or two from completion folks.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
^ permalink raw reply
* 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
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