Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
"W. Trevor King" writes: > On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote: >> * jl/submodule-recursive-checkout (2013-12-26) 5 commits >> - Teach checkout to recursively checkout submodules >> - submodule: teach unpack_trees() to update submodules >> - submodule: teach unpack_trees() to repopulate submodules >> - submodule: teach unpack_trees() to remove submodule contents >> - submodule: prepare for recursive checkout of submodules >> >> Expecting a reroll. > > I think this was rerolled with Jens' v2 [1]: > > * jl/submodule-recursive-checkout (2014-02-03) 9 commits > - submodule: prepare for recursive checkout of submodules > - Teach reset the --[no-]recurse-submodules option > - Teach checkout the --[no-]recurse-submodules option > - Teach merge the --[no-]recurse-submodules option > - Teach bisect--helper the --[no-]recurse-submodules option > - Teach bisect the --[no-]recurse-submodules option > - submodule: teach unpack_trees() to remove submodule contents > - submodule: teach unpack_trees() to repopulate submodules > - submodule: teach unpack_trees() to update submodules > > Cheers, > Trevor > > [1]: http://thread.gmane.org/gmane.comp.version-control.git/241455 Thanks, I'll add a reference to the RFC v2, but it also had significant discussion threads on it, so it would still be in "Expecting a reroll" state anyway. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
On 16/04/14 00:18, Duy Nguyen wrote:
> On Tue, Apr 15, 2014 at 11:45 PM, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> On 11/04/14 23:22, Junio C Hamano wrote:
>>> [...]
[New Topics]
* nd/index-pack-one-fd-per-thread (2014-04-09) 1 commit
- index-pack: work around thread-unsafe pread()
Enable threaded index-pack on platforms without thread-unsafe
pread() emulation.
Will merge to 'next' and keep it there for the remainder of the cycle.
>>>
>>> The commit message for commit 512ebe5d ("index-pack: work around
>>> thread-unsafe pread()", 25-03-2014) is a little misleading.
>>
>> OK. Can we have a concrete alternative?
>>
>> Multi-threaing of index-pack was disabled with c0f8654
>> (index-pack: Disable threading on cygwin - 2012-06-26), because
>> pread() implementations for Cygwin and MSYS were not thread
>> safe. Recent Cygwin does offer usable pread() and we enabled
>> multi-threading with 103d530f (Cygwin 1.7 has thread-safe pread,
>> 2013-07-19).
>>
>> Work around this problem on platforms with a thread-unsafe
>> pread() emulation by opening one file handle per thread; it
>> would prevent parallel pread() on different file handles from
>> stepping on each other.
>>
>> Also remove NO_THREAD_SAFE_PREAD that was introduced in c0f8654
>> because it's no longer used anywhere.
>>
>> This workaround is unconditional, even for platforms with
>> thread-safe pread() because the overhead is small (a couple file
>> handles more) and not worth fragmenting the code.
>>
>
> OK to me.
Yep, this looks good to me too.
Thanks!
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
On Tue, Apr 15, 2014 at 11:45 PM, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On 11/04/14 23:22, Junio C Hamano wrote:
>> [...]
>>> [New Topics]
>>>
>>> * nd/index-pack-one-fd-per-thread (2014-04-09) 1 commit
>>> - index-pack: work around thread-unsafe pread()
>>>
>>> Enable threaded index-pack on platforms without thread-unsafe
>>> pread() emulation.
>>>
>>> Will merge to 'next' and keep it there for the remainder of the cycle.
>>
>> The commit message for commit 512ebe5d ("index-pack: work around
>> thread-unsafe pread()", 25-03-2014) is a little misleading.
>
> OK. Can we have a concrete alternative?
>
> Multi-threaing of index-pack was disabled with c0f8654
> (index-pack: Disable threading on cygwin - 2012-06-26), because
> pread() implementations for Cygwin and MSYS were not thread
> safe. Recent Cygwin does offer usable pread() and we enabled
> multi-threading with 103d530f (Cygwin 1.7 has thread-safe pread,
> 2013-07-19).
>
> Work around this problem on platforms with a thread-unsafe
> pread() emulation by opening one file handle per thread; it
> would prevent parallel pread() on different file handles from
> stepping on each other.
>
> Also remove NO_THREAD_SAFE_PREAD that was introduced in c0f8654
> because it's no longer used anywhere.
>
> This workaround is unconditional, even for platforms with
> thread-safe pread() because the overhead is small (a couple file
> handles more) and not worth fragmenting the code.
>
OK to me.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
Ramsay Jones writes:
> On 11/04/14 23:22, Junio C Hamano wrote:
> [...]
>> [New Topics]
>>
>> * nd/index-pack-one-fd-per-thread (2014-04-09) 1 commit
>> - index-pack: work around thread-unsafe pread()
>>
>> Enable threaded index-pack on platforms without thread-unsafe
>> pread() emulation.
>>
>> Will merge to 'next' and keep it there for the remainder of the cycle.
>
> The commit message for commit 512ebe5d ("index-pack: work around
> thread-unsafe pread()", 25-03-2014) is a little misleading.
OK. Can we have a concrete alternative?
Multi-threaing of index-pack was disabled with c0f8654
(index-pack: Disable threading on cygwin - 2012-06-26), because
pread() implementations for Cygwin and MSYS were not thread
safe. Recent Cygwin does offer usable pread() and we enabled
multi-threading with 103d530f (Cygwin 1.7 has thread-safe pread,
2013-07-19).
Work around this problem on platforms with a thread-unsafe
pread() emulation by opening one file handle per thread; it
would prevent parallel pread() on different file handles from
stepping on each other.
Also remove NO_THREAD_SAFE_PREAD that was introduced in c0f8654
because it's no longer used anywhere.
This workaround is unconditional, even for platforms with
thread-safe pread() because the overhead is small (a couple file
handles more) and not worth fragmenting the code.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
On 04/12/2014 12:22 AM, Junio C Hamano wrote: > [...] > * mh/ref-transaction (2014-04-07) 27 commits > - ref_transaction_commit(): work with transaction->updates in place > - struct ref_update: add a type field > - struct ref_update: add a lock field > - ref_transaction_commit(): simplify code using temporary variables > - struct ref_update: store refname as a FLEX_ARRAY > - struct ref_update: rename field "ref_name" to "refname" > - refs: remove API function update_refs() > - update-ref --stdin: reimplement using reference transactions > - refs: add a concept of a reference transaction > - update-ref --stdin: harmonize error messages > - update-ref --stdin: improve the error message for unexpected EOF > - t1400: test one mistake at a time > - update-ref --stdin -z: deprecate interpreting the empty string as zeros > - update-ref.c: extract a new function, parse_next_sha1() > - t1400: test that stdin -z update treats empty as zeros > - update-ref --stdin: simplify error messages for missing oldvalues > - update-ref --stdin: make error messages more consistent > - update-ref --stdin: improve error messages for invalid values > - update-ref.c: extract a new function, parse_refname() > - parse_cmd_verify(): copy old_sha1 instead of evaluating twice > - update-ref --stdin: read the whole input at once > - update_refs(): fix constness > - refs.h: rename the action_on_err constants > - t1400: add some more tests involving quoted arguments > - parse_arg(): really test that argument is properly terminated > - t1400: provide more usual input to the command > - t1400: fix name and expected result of one test > (this branch is used by rs/ref-closer-to-atomic.) > > Update "update-ref --stdin [-z]" and then introduce a transactional > support for (multi-)reference updates. > > Is this ready to be merged to 'next' for wider exposure? Yes, as far as I know there are no outstanding objections to this version (v3) of this series and it is ready for 'next'. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
On 11/04/14 23:22, Junio C Hamano wrote:
[...]
> [New Topics]
>
> * nd/index-pack-one-fd-per-thread (2014-04-09) 1 commit
> - index-pack: work around thread-unsafe pread()
>
> Enable threaded index-pack on platforms without thread-unsafe
> pread() emulation.
>
> Will merge to 'next' and keep it there for the remainder of the cycle.
The commit message for commit 512ebe5d ("index-pack: work around
thread-unsafe pread()", 25-03-2014) is a little misleading.
The pread() implementation is only thread-unsafe on older versions of
cygwin (anything prior to v1.7 - aka v1.5). Indeed, index-pack has been
threaded on cygwin (v1.7) since commit 103d530f ("Cygwin 1.7 has thread-
safe pread", 19-07-2013). (So, it was released in v1.8.4, I guess).
Since I upgraded my cygwin installation long ago (well about 9 months
ago), I can no longer test patches on cygwin v1.5. Also, since commit
a50dec22 ("Makefile: update defaults for modern Cygwin", 01-04-2010)
tells us that cygwin v1.5 is no longer being actively supported, it
may be difficult to find anyone who can do that testing. (v1.5 was
the last version supported on windows 95, 98 and ME, so maybe ... :)
Yesterday, I briefly compared the performance of the master and pu
branches (respectively with and without this patch) on cygwin.
(There seems to be little difference in the performance, as expected).
$ uname -a
CYGWIN_NT-5.1 toshiba 1.7.29(0.272/5/3) 2014-04-07 13:44 i686 Cygwin
First, on the master branch:
$ ./git version
git version 1.9.2.459.g68773ac
$ git log -1 --decorate --oneline
68773ac (HEAD, origin/master, origin/HEAD, master) Sync with 1.9.2
$ cd t
$ time ./t5302-pack-index.sh
ok 1 - setup
...
ok 31 - running index-pack in the object store
# passed all 31 test(s)
1..31
real1m11.984s
user1m24.986s
sys 0m41.521s
$
$ cd perf
$ ./p5302-pack-index.sh
warning: $GIT_PERF_LARGE_REPO is $GIT_BUILD_DIR.
warning: This will work, but may not be a sufficiently large repo
warning: for representative measurements.
ok 1 - repack
perf 2 - index-pack 0 threads: 1 2 3 ok
perf 3 - index-pack 1 thread : 1 2 3 ok
perf 4 - index-pack 2 threads: 1 2 3 ok
perf 5 - index-pack 4 threads: 1 2 3 ok
perf 6 - index-pack 8 threads: 1 2 3 ok
perf 7 - index-pack default number of threads: 1 2 3 ok
# passed all 7 test(s)
1..7
Can't locate Git.pm in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/site_perl/5.14
/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/5.14 /usr/lib/perl5/site_perl/5.10
/usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 .) at
./aggregate.perl line 5.
BEGIN failed--compilation aborted at ./aggregate.perl line 5.
$ PERL5LIB=/home/ramsay/lib/perl5/site_perl/5.14 ./aggregate.perl
./p5302-pack-index.sh
Test this tree
5302.2: index-pack 0 threads 38.60(34.38+0.93)
5302.3: index-pack 1 thread36.48(34.74+0.90)
5302.4: index-pack 2 threads 26.60(36.57+1.87)
5302.5: index-pack 4 threads 27.32(37.46+2.38)
5302.6: index-pack 8 threads 27.18(38.38+3.01)
5302.7: index-pack default number of threads 25.40(36.07+2.09)
$
NOTE: that t/perf/aggregate.perl can't locate Git.pm; I haven't investigated
that.
Now, on the pu branch:
$ ./git version
git version 1.9.2.667.ge5b74e1
$ git log -1 --decorate --oneline
e5b74e1 (HEAD, origin/pu, pu) Merge branch 'jc/graph-post-root-gap' into pu
$ cd t
$ time ./t5302-pack-index.sh
ok 1 - setup
...
ok 31 - running index-pack in the object store
# passed all 31 test(s)
1..31
real1m8.063s
user1m26.151s
sys 0m40.477s
$
$ cd perf
$ PERL5LIB=/home/ramsay/lib/perl5/site_perl/5.14 ./p5302-pack-index.sh
warning: $GIT_PERF_LARGE_REPO is $GIT_BUILD_DIR.
warning: This will work, but may not be a sufficiently large repo
warning: for representative measurements.
ok 1 - repack
perf 2 - index-pack 0 threads: 1 2 3 ok
perf 3 - index-pack 1 thread : 1 2 3 ok
perf 4 - index-pack 2 threads: 1 2 3 ok
perf 5 - index-pack 4 threads: 1 2 3 ok
perf 6 - index-pack 8 threads: 1 2 3 ok
perf 7 - index-pack default number of threads: 1 2 3 ok
# passed all 7 test(s)
1..7
Test this tree
5302.2: index-pack 0 threads 37.90(34.40+0.82)
5302.3: index-pack 1 thread37.93(34.79+0.96)
5302.4: index-pack 2 threads 27.75(36.46+1.98)
5302.5: index-pack 4 threads 27.93(37.24+2.82)
5302.6: index-pack 8 threads 29.34(38.23+3.04)
5302.7:
Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
Felipe Contreras writes:
> Junio C Hamano wrote:
>> * fc/complete-aliased-push (2014-04-09) 1 commit
>> - completion: fix completing args of aliased "push", "fetch", etc.
>>
>> Will merge to 'next'.
>>
>>
>> * fc/remote-helper-fixes (2014-04-09) 4 commits
>> - remote-bzr: include authors field in pushed commits
>
> Before you do, you might want to pick the unrelated fix I just sent[1],
> otherwise this test might fail on some machines.
Will pick up $gmane/246157 (or at least will try to remember ;-).
Thanks.
>> - remote-bzr: add support for older versions
>> - remote-hg: always normalize paths
>> - remote-helpers: allow all tests running from any dir
>>
>> Will merge to 'next'.
>
>> * fc/publish-vs-upstream (2014-04-11) 8 commits
>> - sha1_name: add support for @{publish} marks
>> - sha1_name: simplify track finding
>> - sha1_name: cleanup interpret_branch_name()
>> - branch: display publish branch
>> - push: add --set-publish option
>> - branch: add --set-publish-to option
>> - Add concept of 'publish' branch
>> - t5516 (fetch-push): fix test restoration
>>
>> Add branch@{publish}; this round v3 hasn't yet seen much reviews
>> yet.
>>
>> Seems to have some interactions to break tests when merged to 'pu'.
>
> That was v2, wasn't it?
The tip d95807a0e1b7 (sha1_name: add support for @{publish} marks,
2014-04-11) is with timestamp "Fri Apr 11 12:59:11 2014 -0500",
which matches $gmane/246122, so I am reasonably sure that I applied
the v3 on the same base as the base I queued the v2 on, compared
them and then updated the branch. Also I can tell by seeing some
patches lost the retitle I did for the previous round.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Apr 2014, #03; Fri, 11)
Junio C Hamano wrote:
> * fc/complete-aliased-push (2014-04-09) 1 commit
> - completion: fix completing args of aliased "push", "fetch", etc.
>
> Will merge to 'next'.
>
>
> * fc/remote-helper-fixes (2014-04-09) 4 commits
> - remote-bzr: include authors field in pushed commits
Before you do, you might want to pick the unrelated fix I just sent[1],
otherwise this test might fail on some machines.
> - remote-bzr: add support for older versions
> - remote-hg: always normalize paths
> - remote-helpers: allow all tests running from any dir
>
> Will merge to 'next'.
> * fc/publish-vs-upstream (2014-04-11) 8 commits
> - sha1_name: add support for @{publish} marks
> - sha1_name: simplify track finding
> - sha1_name: cleanup interpret_branch_name()
> - branch: display publish branch
> - push: add --set-publish option
> - branch: add --set-publish-to option
> - Add concept of 'publish' branch
> - t5516 (fetch-push): fix test restoration
>
> Add branch@{publish}; this round v3 hasn't yet seen much reviews
> yet.
>
> Seems to have some interactions to break tests when merged to 'pu'.
That was v2, wasn't it?
[1] http://article.gmane.org/gmane.comp.version-control.git/246157
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
