Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 9b11597..82a4a78 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -1884,6 +1884,10 @@ receive.updateserverinfo::
>> If set to tr
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> diff --git a/remote.c b/remote.c
>> index e53a6eb..d6fcfc0 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -48,6 +48,7 @@ static int branches_nr;
>>
>> static struct branch *current_branch;
>> static const char *default_remote_name;
>> +
Since command usages can be translated, they may include utf-8 encoded
strings, and the output in console may not align well any more. This is
because strlen() is different from strwidth() on utf-8 strings. A wrapper
utf8_fprintf() can help to return the correct columns required.
Signed-off-by: Ji
Hi, Junio
The following changes since commit ec3ae6ec46ed48383ae40643990f169b65a563cc:
Merge git://ozlabs.org/~paulus/gitk (2013-01-23 08:35:03 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po/ master
for you to fetch changes up to 1bbe7c3c124c435b45f87a7151
The delay for commands like git status is much worse on Windows than Linux; for
my workflow I would be happy with a Windows only implementation.
>From the description so far, I have some question: how does the daemon get
>started and stopped? Is there one per repository --- this seems to be im
Junio C Hamano writes:
> I checked read-cache.c and preload-index.c code. To get the
> discussion rolling, I think something like the outline below may be
> a good starting point and a feasible weekend hack for somebody
> competent:
>
> * At the beginning of preload_index(), instead of spawning
Duy Nguyen writes:
> Can we replace "open a socket to our daemon" with "open a special file
> in .git to get stat data written by our daemon"? TCP/IP socket means
> system-wide daemon, not attractive. UNIX socket is not available on
> Windows (although there may be named pipe, I don't know).
I d
On Fri, Feb 8, 2013 at 6:05 PM, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Nick Muerdter writes:
>
>>> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
>>> directory can't be accessed, it results in a fatal error. In git 1.8.1
>>> and below this same setup just resulted in w
On Sat, Feb 9, 2013 at 5:45 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ramkumar Ramachandra writes:
>>
>>> ... Will Git ever
>>> consider using inotify on Linux? What is the downside?
>>
>> I think this has come up from time to time, but my understanding is
>> that nobody thought
Tim Chen writes:
> When I am doing a git bisect to track down a problem commit on the Linux
> kernel tree, I found that git bisect actually led me to a patch that's one
> before the problem commit.
>
> In particular,
>
> $ git bisect replay bisectlog
> Previous HEAD position was d54b1a9... perf
On Sat, Feb 9, 2013 at 1:44 AM, Junio C Hamano wrote:
>> +static void real_report_pack_garbage(const char *path, int len, const char
>> *name)
>> +{
>
> Don't some callers call this on paths outside objects/pack/
> directory? Is it still report-pack-garbage?
In fact 3/3 uses it to report loose
When I am doing a git bisect to track down a problem commit on the Linux
kernel tree, I found that git bisect actually led me to a patch that's one
before the problem commit.
In particular,
$ git bisect replay bisectlog
Previous HEAD position was d54b1a9... perf script: Remove use of die/exit
H
> +information from taking up too much space on disk or in memory. Some
> +git commands may automatically run linkgit:git-gc[1], so you don't
> +have to worry about running it manually. However, compressing large
> +repositories may take some time, so you might want to disable
> +automatic comres
On Fri, Feb 08, 2013 at 08:05:24PM -0500, Jeff King wrote:
> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>
> > > Yeah, that actually is a good point. We should be using logmsg_reencode
> > > so that we look for strings in the user's encoding.
> >
> > Perhaps like this. Just
Junio C Hamano wrote:
> Nick Muerdter writes:
>> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
>> directory can't be accessed, it results in a fatal error. In git 1.8.1
>> and below this same setup just resulted in warnings. Was this an
>> intentional change?
>
> I think this wa
On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> > Yeah, that actually is a good point. We should be using logmsg_reencode
> > so that we look for strings in the user's encoding.
>
> Perhaps like this. Just like the previous one (which should be
> discarded), this makes the fun
Nick Muerdter writes:
> As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
> directory can't be accessed, it results in a fatal error. In git 1.8.1
> and below this same setup just resulted in warnings. Was this an
> intentional change?
I think this was done to not just help diagnos
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
>>
>>> Junio C Hamano writes:
>>>
>>> > Thomas Haller writes:
>>> >
>>> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>> >>
>>> >> retval
As of git 1.8.1.1 and above (tested up to 1.8.1.3), if the home
directory can't be accessed, it results in a fatal error. In git 1.8.1
and below this same setup just resulted in warnings. Was this an
intentional change?
I ran into this in a situation where sudo is being used to execute a
script as
Jeff King writes:
> On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > Thomas Haller writes:
>> >
>> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
>> >>
>> >> retval = grep_buffer(&opt->grep_filter,
>> >
On Fri, Feb 08, 2013 at 04:29:11PM -0800, Junio C Hamano wrote:
> Perhaps something along this line...
>
> -- >8 --
> Subject: "log --grep": commit's buffer may already have been discarded
>
> Following up on be5c9fb9049e (logmsg_reencode: lazily load missing
> commit buffers, 2013-01-26), extra
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Thomas Haller writes:
>>
>>> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>>
>>> retval = grep_buffer(&opt->grep_filter,
>>> commit->buffer,
>>> strlen(commit->buf
On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thomas Haller writes:
> >
> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
> >>
> >> retval = grep_buffer(&opt->grep_filter,
> >>
Junio C Hamano writes:
> Thomas Haller writes:
>
>> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>
>> retval = grep_buffer(&opt->grep_filter,
>> commit->buffer, strlen(commit->buffer));
>
> I think this has been fixed
Thomas Haller writes:
> it happens in file revision.c:2306 because "commit->buffer" is zero:
>
> retval = grep_buffer(&opt->grep_filter,
> commit->buffer, strlen(commit->buffer));
I think this has been fixed at be5c9fb9049e (logmsg_reencode: l
Hallo,
I just found that git crashes with a segmentation fault when calling
$ git log --graph --no-walk --grep pattern
It happens both for version 1.7.10.4 from Debian (wheezy,amd64) and
a fresh compiled git from github (git.git repository, master).
For the error to occure, the pattern must ma
From: "Junio C Hamano"
Sent: Friday, February 08, 2013 10:54 PM
"Philip Oakley" writes:
My initial https://github.com/PhilipOakley/git/commit/e6217d simply
updates
- N_("See 'git help ' for more information on a specific
command.");
+ N_("See 'git help ' for more information on a specific
c
"W. Trevor King" writes:
> I just read through the manual cover to cover, so I have a number of
> other fixes in the pipe (from which I've already submitted the
> receive.denyCurrentBranch patch).
Wonderful.
> ... Should I bundle them all into a
> single series to reduce clutter on the list,..
"W. Trevor King" writes:
> I just read through the manual cover to cover, so I have a number of
> other fixes in the pipe (from which I've already submitted the
> receive.denyCurrentBranch patch).
Wonderful.
> ... Should I bundle them all into a
> single series to reduce clutter on the list,..
"Philip Oakley" writes:
> My initial https://github.com/PhilipOakley/git/commit/e6217d simply
> updates
> - N_("See 'git help ' for more information on a specific
> command.");
> + N_("See 'git help ' for more information on a specific
> command.\n"
> + "Or 'git help ', such as 'tutorial' f
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> ... Will Git ever
>> consider using inotify on Linux? What is the downside?
>
> I think this has come up from time to time, but my understanding is
> that nobody thought things through to find a good layer in the
> codebase to interfac
Ramkumar Ramachandra writes:
> ... Will Git ever
> consider using inotify on Linux? What is the downside?
I think this has come up from time to time, but my understanding is
that nobody thought things through to find a good layer in the
codebase to interface to an external daemon that listens
From: "Junio C Hamano"
Sent: Friday, February 08, 2013 8:53 PM
"Philip Oakley" writes:
I'm looking at extending the 'git help' to include some information
for the basic user who isn't ready for the extensive man page
documentation for the various commands.
We have pointers at the beginning
Asheesh Laroia writes:
> Junio, thanks for the quick reply! I agree with your suggestions, and
> will take a look at addressing them, hopefully by Tuesday or so.
FYI, here is what I queued for now.
-- >8 --
From: Asheesh Laroia
Date: Thu, 7 Feb 2013 17:16:24 -0800
Subject: [PATCH] git-mergetoo
On Fri, 8 Feb 2013, Junio C Hamano wrote:
Asheesh Laroia writes:
Before this change, if git-mergetool was invoked with regard to
Drop "before this change,"; it is clear (and it is a recommended
practice) you are first describing what problem you are addressing.
Junio, thanks for the quic
"Philip Oakley" writes:
> I'm looking at extending the 'git help' to include some information
> for the basic user who isn't ready for the extensive man page
> documentation for the various commands.
We have pointers at the beginning of "git(1)" for that exact reason.
I am not saying the documen
I'm curious what your use case is.
The behavior has been inconvenient for me too, but I have only used it
in test cases; I have no real use case where I wanted to create an
unborn/orphan branch.
On Fri, Feb 8, 2013 at 11:50 AM, Ramkumar Ramachandra
wrote:
> Hi,
>
> Why should I have to `git rm -
I'm looking at extending the 'git help' to include some information for
the basic user who isn't ready for the extensive man page documentation
for the various commands.
If the user doesn't yet know which is the relevant command then they
should also be offered a clue on how to finding the var
Ramkumar Ramachandra writes:
> BTW, Is there a better way to clean out the worktree than `git rm -rf
> .`, since that fails for submodules? The impulsive `reset --hard`
> obviously fails because there is no HEAD.
I _think_ the "git rm" is one of the things on Jens's roadmap. Also
I think "rese
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
>> What sort of misfeature/ incomplete feature is this?
>
> One designed for the "going open source" use case, where you have
> existing code that you want to put into a
Ramkumar Ramachandra writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9b11597..82a4a78 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1884,6 +1884,10 @@ receive.updateserverinfo::
> If set to true, git-receive-pack will run g
Ramkumar Ramachandra writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9b11597..0b3b1f8 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -727,6 +727,12 @@ branch..remote::
> remote to fetch from/push to. It defaults to `origin`
Ramkumar Ramachandra wrote:
> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
> What sort of misfeature/ incomplete feature is this?
One designed for the "going open source" use case, where you have
existing code that you want to put into a new branch without history.
When th
Matthieu Moy writes:
> John Keeping writes:
>
>> diff --git a/graph.c b/graph.c
>> index 391a712..2a3fc5c 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
>> if (!graph)
>> return;
>>
>> +/*
>> + * When
[Moved from the thread where this was initially posted to reply to the
series.]
Matthieu Moy wrote:
> This works, but if we know we're not going to enter the while loop, it
> seams even easier to do this:
>
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,7 +1227,17 @@ void graph_show_commit(struct gi
Ramkumar Ramachandra writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
>> the code review creation push that uses a different bran
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> [remote "origin"]
>> url = ... where Ram fetches and pulls from ...
>> pushurl = ... where Ram pushes to ...
>> fetch = refs/heads/*:refs/remotes/*
>> updateTrackOnPush
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> We may do some redundant stat() here, but I don't think it can slow
> count-objects down much to worry about.
I don't either. Looks like a good change to me.
It appears that the sb.buf refactoring is better done to
Nguyễn Thái Ngọc Duy writes:
> prepare_packed_git_one() is modified to allow count-objects to hook a
> report function to so we don't need to duplicate the pack searching
> logic in count-objects.c. When report_pack_garbage is NULL, the
> overhead is insignificant.
>
> Signed-off-by: Nguyễn Thái
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator
Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from
On Fri, Feb 08, 2013 at 09:36:53AM -0800, Junio C Hamano wrote:
> I'd rather phrase it like "... may take long, so you would want to
> run it explicitly from time to time to avoid automatic gc kicking in
> when it is not convenient for you".
Works for me.
> Removal of this is a good change, thoug
Nguyễn Thái Ngọc Duy writes:
> This prints more helpful info when HEAD is detached: is it detached
> because of bisect or rebase? What is the original branch name in those
> cases?
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Keep "no branch" in all cases. Just append "rebasing/bisecting [%
Junio C Hamano wrote:
> [remote "origin"]
> url = ... where Ram fetches and pulls from ...
> pushurl = ... where Ram pushes to ...
> fetch = refs/heads/*:refs/remotes/*
> updateTrackOnPush = no
>
> Then "git fetch" (or "git pul
On Fri, Feb 08, 2013 at 10:13:23AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> >
> >> Jeff King writes:
> >>
> >> > That seems much cleaner to me. If done right, it could also let people
> >> > put:
> >> >
> >> > CONT
Jeff King writes:
> On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
>
>> Jeff King writes:
>>
>> > That seems much cleaner to me. If done right, it could also let people
>> > put:
>> >
>> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>>
>> Actually, you can already d
From: "W. Trevor King"
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation
Junio C Hamano wrote:
> Jeff King writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gen
John Keeping writes:
> diff --git a/graph.c b/graph.c
> index 391a712..2a3fc5c 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> + /*
> + * When showing a diff of a merge again
On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> Jeff King writes:
>
> > That seems much cleaner to me. If done right, it could also let people
> > put:
> >
> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>
> Actually, you can already do this:
>
> SCRIPT_PERL += c
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> This should have happened back in 2007, when `git gc` learned about
> auto:
>
> commit e9831e83e063844b90cf9e525d0003715dd8b395
> Author: Junio C Hamano
> Date: Mon Sep 17 00:39:52 2007 -0700
>
> git-gc --auto: add documentation.
Jeff King writes:
> That seems much cleaner to me. If done right, it could also let people
> put:
>
> CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
Actually, you can already do this:
SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
probably not by design, but it works!
Asheesh Laroia writes:
> Before this change, if git-mergetool was invoked with regard to
Drop "before this change,"; it is clear (and it is a recommended
practice) you are first describing what problem you are addressing.
> files with a percent sign (%) in their names, it would print an
> error
This makes the Makefile simpler, while providing more features, and more
consistency (the exact same rules with the exact same configuration as
Git official commands are applied with the new version).
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/.gitignore | 1 +
cont
Git's Makefile provides a few nice features for script build and
installation (substitute the first line with the right path, hardcode the
path to Git library, ...).
The Makefile already knows how to process files outside the toplevel
directory with e.g.
make SCRIPT_PERL=path/to/file.perl path/
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetch
Michael J Gruber writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing y
Jeff King writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they
Junio C Hamano writes:
> I really think this is going in a wrong direction. Whatever you
> happen to have chosen in this patch will be available to others,
> while whatever are left out will not be. When adding new things,
> people need to ask if it needs to be sharable or not, and the right
>
On 8 February 2013 16:23, Martijn van Oosterhout wrote:
> git_commit_non_empty_tree()
> {
> +if test $# = 1 && test -z "$(git ls-tree $1)" ; then
> +skip_commit "$@"
> +fi
> if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
>
From: "W. Trevor King"
This should have happened back in 2007, when `git gc` learned about
auto:
commit e9831e83e063844b90cf9e525d0003715dd8b395
Author: Junio C Hamano
Date: Mon Sep 17 00:39:52 2007 -0700
git-gc --auto: add documentation.
Signed-off-by: W. Trevor King
---
I'd als
On 08.02.13 08:20, Jiang Xin wrote:
> 2013/2/8 Torsten Bögershausen :
>> On 08.02.13 03:10, Jiang Xin wrote:
>>> + /* If no error occurs, returns columns really required with
>>> utf8_strwidth. */
>>> + if (0 <= columns)
>>> + columns = utf8_strwidth(buf.buf);
>>> + strbuf_
On Fri, Feb 08, 2013 at 07:09:28AM -0800, Matt Kraai wrote:
> From: Matt Kraai
>
> QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
> comma if the error macro's variable argument is left out.
>
> Instead of testing for a sufficiently recent version of GCC, make
> __VA_ARG
Hoi,
Found a small issue with git filter-branch not removing empty commits
if they are the first commit in the tree. Find test script attached
and example output below.
I think the issue is in the function git_commit_non_empty_tree, which
doesn't handle this case. I think something like the follo
From: Matt Kraai
QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
comma if the error macro's variable argument is left out.
Instead of testing for a sufficiently recent version of GCC, make
__VA_ARGS__ match all of the arguments.
Signed-off-by: Matt Kraai
---
git-compat
Junio C Hamano venit, vidit, dixit 07.02.2013 19:03:
> Michael J Gruber writes:
>
(cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
../HEAD:../cache.h:#define GET_SHA1_QUIETLY01
>>>
>>> Yuck.
>>
>> And even more yuck:
>>
>> (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:.
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder writes:
>
>> "Wait, why did the remote rewind?"
>
> Oh, I am very well aware of that glitch.
>
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
>
> It shouldn't
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Keep "no branch" in all cases. Just append "rebasing/bisecting [%s]"
when applicable.
builtin/branch.c
On Wed, Feb 06, 2013 at 04:19:07PM +0100, Thomas Koch wrote:
> I'd like to script a git export command that can be given a list of already
> exported worktrees and the tree SHA1s these worktrees correspond too. The git
> export command should then for every file it wants to export lookup in the
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means. The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your wor
This new configuration variable overrides branch-specific
configuration `branch..remote` for pushes. It is useful in the
typical scenario, where the remote I'm pulling from is not the remote
I'm pushing to.
Signed-off-by: Ramkumar Ramachandra
---
Junio C Hamano wrote:
> As the first cut, I wou
Ramkumar Ramachandra writes:
> Comments are welcome.
As the first cut, I would have expected the series to start from
more general (not "only this branch"), with later follow-up to let
more specific configuration.
Also I'd prefer to see the "push" semantics (e.g. "what does
upstream mean in th
Jonathan Nieder writes:
> "Wait, why did the remote rewind?"
Oh, I am very well aware of that glitch.
"git push" has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It shouldn't have been made to do so unconditionally; instead it
should have been de
83 matches
Mail list logo
