Jeff King <peff@xxxxxxxx> writes:
> On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:
>
>> * jk/add-i-hunk-filter (2011-07-27) 5 commits
>> (merged to 'next' on 2011-08-11 at 8ff9a56)
>> + add--interactive: add option to autosplit hunks
>> + add--interactive: allow negatation of hunk filters
>> + add--interactive: allow hunk filtering on command line
>> + add--interactive: factor out regex error handling
>> + add--interactive: refactor patch mode argument processing
>>
>> Needs documentation updates.
>
> I think Duy already mentioned this, but you may want to update your
> "what's cooking" note: it needs not just doc updates, but code to
> actually pass the options along from real git commands that use
> add--interactive, like add, checkout, reset, and stash.
Thanks. Also tests are lacking, too. Although I do not necessarily see the
lack of integration with anything but "add" a show-stopper (I consider
"-p" to chekout, reset and stash are "nice to have"), you are correct that
"add -i" and then choosing '[p]atch' gets very confused with
Patch update>>
Use of uninitialized value in split at /git/git-pu/libexec/git-core/git-add--interactive line 742, <STDIN> line 3.
Unknown option: --
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[-c name=value] [--help]
<command> [<args>]
Unknown option: --color
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[-c name=value] [--help]
<command> [<args>]
So it certainly seems not ready for the prime time.
>> * jk/generation-numbers (2011-07-14) 7 commits
>> - limit "contains" traversals based on commit generation
>> - check commit generation cache validity against grafts
>> - pretty: support %G to show the generation number of a commit
>> - commit: add commit_generation function
>> - add metadata-cache infrastructure
>> - decorate: allow storing values instead of pointers
>> - Merge branch 'jk/tag-contains-ab' (early part) into HEAD
>>
>> The initial "tag --contains" de-pessimization without need for generation
>> numbers is already in; backburnered.
>
> So...what next? I don't really like leaving the contains traversal
> as-is.
Hmm, honestly speaking, I do not see much problem with it. My knee-jerk
reaction is to go with 1.a and if we really want to do something 1.b
perhaps but I suspect "these are bogus" cache wouldn't be so useful by
itself and we may need a bit more information.
>> * jk/http-auth-keyring (2011-08-03) 13 commits
>> (merged to 'next' on 2011-08-03 at b06e80e)
>> ...
>> Not urgent; will not be in 1.7.7.
>
> I'm OK with holding this off for another round. I'd really like to get
> more feedback from third-party helper writers. ...
I actually do not think the lack of finer-than-host level granularity a
problem we need to solve before moving forward. IIRC, when accessing
"http://github.com/frotz"; and "http://github.com/nitfol";, you would key
the authentication material with something like "http://github.com"; (or
was it "http:github.com"? the details do not matter for the purpose of
this discussion). If another site that has multiple independent userbases
within the same host, i.e. the user "xyzzy" at "http://gotheb.com/frotz";
and the user "xyzzy" at "http://gotheb.com/nitfol"; need to be treated as
separate identities, it obviously is not enoug to use "gotheb.com" as the
look-up key for the authentication material, but in such a case, the user
knows an important piece of information that git can never figure out by
itself, namely, where the authentication domain boundary lies.
We need to add "auth-domain" support, perhaps from the command line option
and configuration, if we ever need to support such a site.
We can consider what you already have as the default case for a more
general "we cut off at the hostname and take that as the auth-domain
boundary unless told otherwise". We may not have the way to "tell
otherwise" yet, but as long as we are reasonably confident that we know
how to extend the system in a backward compatible way, it is not a
show-stopper.
The primary reason why I wanted to hold this topic off was because of the
frequency of bug report we saw this round to topics _after_ they hit the
"master" branch, indicating that not many people are testing "next" during
the development cycle as they used to in olden days.
--
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