Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> 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.
> * 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.
> * 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.
> * 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".
> * 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?
> * 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?
> * 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?
> * 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html