Re: What's cooking in git.git (Mar 2013, #07; Tue, 26)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 27, 2013, 21:47 UTC
Message-ID: <7vy5d8jz0y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <878v58worp.fsf@linux-k42r.v.cablecom.net>

Thomas Rast <trast@student.ethz.ch> writes:

Show 23 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
>>
>>> [Cooking]
>>> [...]
>>> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>>>  - index-pack: always zero-initialize object_entry list
>>> 
>>>  "index-pack --fix-thin" used uninitialize value to compute delta
>>>  depths of objects it appends to the resulting pack.
>>
>> Any reason this is still in pu? I'd have expected it to be fairly
>> uncontroversial and slated for maint.
>
> Me too, along with the other two we found in the same topic:
>
>> * nd/index-pack-threaded-fixes (2013-03-19) 2 commits
>>  - index-pack: guard nr_resolved_deltas reads by lock
>>  - index-pack: protect deepest_delta in multithread code
>>
>>  "index-pack --verify-stat" used a few counters outside protection
>>  of mutex, possibly showing incorrect numbers.

Yes.

Speaking of which... (cc'ed various people involved in the topics listed below)

> [Stalled]

It may be time to discard all the stalled topics (without prejudice), except for some.

Show 11 quoted lines

> * jc/format-patch (2013-02-21) 2 commits
>  - format-patch: --inline-single
>  - format-patch: rename "no_inline" field
>
>  A new option to send a single patch to the standard output to be
>  appended at the bottom of a message.  I personally have no need for
>  this, but it was easy enough to cobble together.  Tests, docs and
>  stripping out more MIMEy stuff are left as exercises to interested
>  parties.
>
>  Not ready for inclusion.

Somebody may want to pick this up to give it finishing touches.

I am reasonably sure that some MIMEy stuff are still leaked to the output. From the UI point of view, this does not let you say

    git format-patch --inline-single [<commit>]

with omitted <commit> defalting to HEAD (instead you have to say "-1").

> * po/help-guides (2013-03-03) 5 commits

I know Philip said a reroll is planned, so if it comes, it can be requeued.

Show 5 quoted lines

> * mb/gitweb-highlight-link-target (2012-12-20) 1 commit
>  - Highlight the link target line in Gitweb using CSS
>
>  Expecting a reroll.
>  $gmane/211935

Highlighting was cute but the anchor was not.

> [Cooking]
>
> * jc/merge-tag-object (2013-03-19) 1 commit
>  - merge: a random object may not necssarily be a commit

Probably we should eventually merge this as a bugfix to maintenance track.

> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>  - index-pack: always zero-initialize object_entry list

This is in the same class as the ones you two were wondering about, I think.

Show 5 quoted lines

> * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>   (merged to 'next' on 2013-03-19 at e68014a)
>  + difftool --dir-diff: symlink all files matching the working tree
>  + difftool: avoid double slashes in symlink targets
>  + git-difftool(1): fix formatting of --symlink description

I lost track of various discussions on "difftool" and its "symlink so that the user can edit working tree files in the tool".

Show 9 quoted lines

> * tr/line-log (2013-03-23) 6 commits
>  - Speed up log -L... -M
>  - log -L: :pattern:file syntax to find by funcname
>  - Implement line-history search (git log -L)
>  - Export rewrite_parents() for 'log -L'
>  - fixup
>  - Refactor parse_loc
>
>  Rerolled; collides with nd/magic-pathspecs.

Honestly I am not sure what to make of this one. I'd say we should merge this down as-is to 'master', expecting that in some future we would fix "log --follow" to keep the refspecs per history traversal path, so that this can be more naturally reimplemented. Objections?

Show 18 quoted lines

> * jc/push-2.0-default-to-simple (2013-03-18) 15 commits
>  - advice: Remove unused advice_push_non_ff_default
>  - t5570: do not assume the "matching" push is the default
>  - t5551: do not assume the "matching" push is the default
>  - t5550: do not assume the "matching" push is the default
>  - doc: push.default is no longer "matching"
>  - push: switch default from "matching" to "simple"
>  - t9401: do not assume the "matching" push is the default
>  - t9400: do not assume the "matching" push is the default
>  - t7406: do not assume the "matching" push is the default
>  - t5531: do not assume the "matching" push is the default
>  - t5519: do not assume the "matching" push is the default
>  - t5517: do not assume the "matching" push is the default
>  - t5516: do not assume the "matching" push is the default
>  - t5505: do not assume the "matching" push is the default
>  - t5404: do not assume the "matching" push is the default
>
>  Will cook in 'next' until Git 2.0.

At least we should reorder the three test patches near the tip to come before the "switch the default", and perhaps squash the tip one and "doc" patch to "switch the default" one, but other than that, are we ready to commit to this?

Show 10 quoted lines

> * jn/add-2.0-u-A-sans-pathspec (2013-03-20) 5 commits
>  - git add: -u/-A now affects the entire working tree
>  - add -A: only show pathless 'add -A' warning when changes exist outside cwd
>  - add -u: only show pathless 'add -u' warning when changes exist outside cwd
>  - add: make warn_pathless_add() a no-op after first call
>  - add: make pathless 'add [-u|-A]' warning a file-global function
>
>  Replaces jc/add-2.0-u-A-sans-pathspec topic by not warning against
>  "add -u/-A" that is ran without pathspec when there is no change
>  outside the current directory.

I recall we had a lengthy discussion on this, but how committed are we on the progression of this series? Are the bottom four ready to be merged to 1.8.3, or do they need more polishing?

Show 14 quoted lines

> * jc/add-2.0-delete-default (2013-03-08) 3 commits
>  - git add <pathspec>... defaults to "-A"
>  - git add: start preparing for "git add <pathspec>..." to default to "-A"
>  - builtin/add.c: simplify boolean variables
>
>  "git add dir/" updated modified files and added new files, but does
>  not notice removed files, which may be "Huh?" to some users.  They
>  can of course use "git add -A dir/", but why should they?
>
>  There seemed to be some interest in this topic, so resurrected and
>  rebased on top of recent documentation updates to propose a
>  possible transition plan.
>
>  Will cook in 'next' until Git 2.0.

The other day I saw somebody at work did "git add ." (it could have been "git add dir/") to mark the resolution of a conflicting merge, when one of the paths should be removed. It made me wish we had this already.

I think we discussed this topic in the past a few times, and it is uncontroversial enough to be in Git 2.0.

Is there any other "we have already well discussed it, we already know how the implementation would look like if we were to do this, and we have at least a rough sketch of how the transition may look like" change we would want to start preparing for Git 2.0? I am not asking for pie-in-the-sky proposals (I know you two I am responding to know this---I am just clarifying for others).

Thanks.