Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

[Johannes Schindelin]

Hi Junio,

On Tue, 27 Sep 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > In your previous kitchen status ("What's cooking") you hinted at a
> > possible v2.10.1 soon. I have a couple of bugfixes lined up for Git
> > for Windows and would like to avoid unnecessarily frequent release
> > engineering... Any more concrete ideas on a date for this version?
> 
> I scanned RelNotes for 2.11 and identified these topics that we'd want
> to have in 'maint'.
> 
> bw/pathspec-remove-unused-extern-decl # 1 (6 days ago) 
> rs/checkout-some-states-are-const # 1 (6 days ago) 
> rs/strbuf-remove-fix # 1 (6 days ago) 
> rs/unpack-trees-reduce-file-scope-global # 1 (6 days ago) 
> mr/vcs-svn-printf-ulong # 1 (6 days ago) 
> sy/git-gui-i18n-ja # 7 (12 days ago) 
> jk/fix-remote-curl-url-wo-proto # 1 (12 days ago) 
> js/git-gui-commit-gpgsign # 2 (12 days ago) 
> jk/patch-ids-no-merges # 2 (6 days ago) 
> ew/http-do-not-forget-to-call-curl-multi-remove-handle # 3 (6 days ago) 
> rs/xdiff-merge-overlapping-hunks-for-W-context # 1 (6 days ago) 
> ks/perf-build-with-autoconf # 1 (6 days ago) 
> jt/format-patch-base-info-above-sig # 1 (6 days ago) 
> jk/rebase-i-drop-ident-check # 1 (6 days ago) 
> jk/reduce-gc-aggressive-depth # 1 (6 days ago) 
> et/add-chmod-x # 1 (6 days ago) 
> tg/add-chmod+x-fix # 7 (24 hours ago) 
> 
> Most are internal clean-ups that I do not mind leaving out, but I
> think we want to have that "add --chmod=+x" fix in.  As it hasn't
> been enough time passed since the topic was merged to 'master', I'd
> say either
> 
>  (1) 2.10.1 with everything other than the last two in a few days
>  and 2.10.2 late next week with "add --chmod=+x" fix, or
> 
>  (2) just a single 2.10.1 with everything late next week.
> 
> I can go either way and welcome suggestions.  I'd start merging
> older topics in the above list to 'maint' soonish, but not today.

Sorry for the delay in answering. By now, it was probably obvious to you
that (2) was my preference ;-)

Thanks,
Dscho

Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

[Junio C Hamano]

Johannes Schindelin  writes:

> In your previous kitchen status ("What's cooking") you hinted at a
> possible v2.10.1 soon. I have a couple of bugfixes lined up for Git for
> Windows and would like to avoid unnecessarily frequent release
> engineering... Any more concrete ideas on a date for this version?

I scanned RelNotes for 2.11 and identified these topics that we'd
want to have in 'maint'.

bw/pathspec-remove-unused-extern-decl # 1 (6 days ago) 
rs/checkout-some-states-are-const # 1 (6 days ago) 
rs/strbuf-remove-fix # 1 (6 days ago) 
rs/unpack-trees-reduce-file-scope-global # 1 (6 days ago) 
mr/vcs-svn-printf-ulong # 1 (6 days ago) 
sy/git-gui-i18n-ja # 7 (12 days ago) 
jk/fix-remote-curl-url-wo-proto # 1 (12 days ago) 
js/git-gui-commit-gpgsign # 2 (12 days ago) 
jk/patch-ids-no-merges # 2 (6 days ago) 
ew/http-do-not-forget-to-call-curl-multi-remove-handle # 3 (6 days ago) 
rs/xdiff-merge-overlapping-hunks-for-W-context # 1 (6 days ago) 
ks/perf-build-with-autoconf # 1 (6 days ago) 
jt/format-patch-base-info-above-sig # 1 (6 days ago) 
jk/rebase-i-drop-ident-check # 1 (6 days ago) 
jk/reduce-gc-aggressive-depth # 1 (6 days ago) 
et/add-chmod-x # 1 (6 days ago) 
tg/add-chmod+x-fix # 7 (24 hours ago) 

Most are internal clean-ups that I do not mind leaving out, but I
think we want to have that "add --chmod=+x" fix in.  As it hasn't
been enough time passed since the topic was merged to 'master', I'd
say either

 (1) 2.10.1 with everything other than the last two in a few days
 and 2.10.2 late next week with "add --chmod=+x" fix, or

 (2) just a single 2.10.1 with everything late next week.

I can go either way and welcome suggestions.  I'd start merging
older topics in the above list to 'maint' soonish, but not today.

Thanks.

Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

[Junio C Hamano]

Johannes Schindelin  writes:

> Also, I found https://tinyurl.com/gitCal very convenient a URL to point
> to, do you plan to update that for v2.11.0?

Thanks for reminding.  I've barely had enough bandwidth to keep up
with the list traffic for the past few weeks, and haven't got around
to it.  Will find time this afternoon to do so.

Please just assume the usual 8-12 week cycle til then ;-)

Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

[Johannes Schindelin]

Hi Junio,

On Fri, 23 Sep 2016, Junio C Hamano wrote:

> A bunch of topics have graduated to 'next', including a few that
> were so far marked as "needs review" or "will hold", as I think
> giving them a greater visibility and guinea pigs would be the most
> efficient way to get feedback from the real world ;-) Some of them
> may be "Meh" topic, which might be why they weren't getting any
> feedback so far, but at least this way we'd know if there are
> breakages in them (in which case we can just revert and discard
> them).

In your previous kitchen status ("What's cooking") you hinted at a
possible v2.10.1 soon. I have a couple of bugfixes lined up for Git for
Windows and would like to avoid unnecessarily frequent release
engineering... Any more concrete ideas on a date for this version?

Also, I found https://tinyurl.com/gitCal very convenient a URL to point
to, do you plan to update that for v2.11.0?

Thanks,
Dscho

What's cooking in git.git (Sep 2016, #07; Fri, 23)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

A bunch of topics have graduated to 'next', including a few that
were so far marked as "needs review" or "will hold", as I think
giving them a greater visibility and guinea pigs would be the most
efficient way to get feedback from the real world ;-) Some of them
may be "Meh" topic, which might be why they weren't getting any
feedback so far, but at least this way we'd know if there are
breakages in them (in which case we can just revert and discard
them).

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* jk/clone-recursive-progress (2016-09-22) 1 commit
  (merged to 'next' on 2016-09-22 at 8310c42)
 + clone: pass --progress decision to recursive submodules

 "git clone --recurse-submodules" lost the progress eye-candy in
 recent update, which has been corrected.

 Will merge to 'master'.


* jk/doc-cvs-update (2016-09-22) 3 commits
  (merged to 'next' on 2016-09-22 at c0f949f)
 + docs/cvs-migration: mention cvsimport caveats
 + docs/cvs-migration: update link to cvsps homepage
 + docs/cvsimport: prefer cvs-fast-export to parsecvs

 Documentation around tools to import from CVS was fairly outdated.

 Will merge to 'master'.


* jk/verify-packfile-gently (2016-09-22) 1 commit
 - verify_packfile: check pack validity before accessing data

 A low-level function verify_packfile() was meant to show errors
 detected without dying itself, but under some conditions it didn't
 and died instead, which has been fixed.

 Will merge to 'next'.


* jt/fetch-pack-in-vain-count-with-stateless (2016-09-23) 1 commit
 - fetch-pack: do not reset in_vain on non-novel acks

 When "git fetch" tries to find where the history it has diverged
 from what the other side has, it has a mechanism to avoid digging
 too deep into irrelevant side branches.  This however did not work
 well over the "smart-http" transport due to a design bug, which has
 been fixed.

 Will merge to 'next'.


* rs/checkout-init-macro (2016-09-22) 1 commit
  (merged to 'next' on 2016-09-22 at 6513755)
 + introduce CHECKOUT_INIT

 Code cleanup.

 Will merge to 'master'.


* ik/gitweb-force-highlight (2016-09-23) 2 commits
 - gitweb: use highlight's shebang detection
 - gitweb: remove unused paarmeter from guess_file_syntax()

 "gitweb" can spawn "highlight" to show blob contents with
 (programming) language-specific syntax highlighting, but only
 when the language is known.  "highlight" can however be told
 to make the guess itself by giving it "--force" option, which
 has been enabled.

 Waiting for the discussion to conclude.
 cf. <2a4c3efb-2145-b699-c980-3079f165a...@gmail.com>


* jk/ident-ai-canonname-could-be-null (2016-09-23) 1 commit
 - ident: handle NULL ai_canonname

 In the codepath that comes up with the hostname to be used in an
 e-mail when the user didn't tell us, we looked at ai_canonname
 field in struct addrinfo without making sure it is not NULL first.

 Will merge to 'next'.

--
[Stalled]

* jc/bundle (2016-03-03) 6 commits
 - index-pack: --clone-bundle option
 - Merge branch 'jc/index-pack' into jc/bundle
 - bundle v3: the beginning
 - bundle: keep a copy of bundle file name in the in-core bundle header
 - bundle: plug resource leak
 - bundle doc: 'verify' is not about verifying the bundle

 The beginning of "split bundle", which could be one of the
 ingredients to allow "git clone" traffic off of the core server
 network to CDN.

 While I think it would make it easier for people to experiment and
 build on if the topic is merged to 'next', I am at the same time a
 bit reluctant to merge an unproven new topic that introduces a new
 file format, which we may end up having to support til the end of
 time.  It is likely that to support a "prime clone from CDN", it
 would need a lot more than just "these are the heads and the pack
 data is over there", so this may not be sufficient.

 Will discard.


* jc/attr (2016-05-25) 18 commits
 - attr: support quoting pathname patterns in C style
 - attr: expose validity check for attribute names
 - attr: add counted string version of git_attr()
 - attr: add counted string version of git_check_attr()
 - attr: retire git_check_attrs() API
 - attr: convert git_check_attrs() callers to use the new API
 - attr: convert git_all_attrs() to use "struct git_attr_check"
 - attr: (re)introduce git_check_attr() and struct git_attr_check
 - attr: rename function and struct related to checking attributes
 - attr.c: plug small leak in parse_attr_line()
 - attr.c: tighten constness around "git_attr" structure
 - attr.c: simplify