#835566 please clarify docs regarding mr run

#835566#5
Date:
2016-08-27 07:35:01 UTC
From:
To:
Hi,

I would like to do something like

mr run mr config $REPOS foo=bar

This would need a placeholder for the repository name currently acted
on. I am not sure whether this is supported.

Greetings
Marc

#835566#10
Date:
2019-10-15 01:59:29 UTC
From:
To:
The manual page documents that the MR_REPO environment variable is set
to the path of the top of the repository when running commands.

This command does what you want it to:

mr run sh -c 'mr config "$MR_REPO" foo=bar'

Any further thoughts or should I close this bug?

#835566#13
Date:
2019-10-15 01:59:29 UTC
From:
To:
The manual page documents that the MR_REPO environment variable is set
to the path of the top of the repository when running commands.

This command does what you want it to:

mr run sh -c 'mr config "$MR_REPO" foo=bar'

Any further thoughts or should I close this bug?

#835566#18
Date:
2019-10-15 02:50:21 UTC
From:
To:
Some further thoughts from me:

If you want to change how the run command works, you can do that in
your mrconfig, the default just runs the args directly:

   [DEFAULT]
   run = "$@"

You could just evaluate it as shell code instead, or run a subshell:

   [DEFAULT]
   run = eval "$*"

   [DEFAULT]
   run = sh -c "$*"

Then you would be able to run something like this:

   $ mr run mr config '$MR_REPO' foo=bar bar=baz

You could create a new configure command to mr config the current repo:

   [DEFAULT]
   configure = mr config "$MR_REPO" "$@"

Then you would be able to run something like this:

   $ mr configure foo=bar bar=baz

myrepos could also change how `mr config` works to make it so that
passing only one argument means that `mr config "$MR_REPO" "$1" gets
run instead of the current action of returning an error. This would
only allow setting one value at a time, make it more convenient to use
when already in a repository but could be a surprising footgun when
used in a directory tree containing many repositories.

   $ mr config foo=bar
   mr config: not enough parameters

Another option would be to create a -r / --recurse option that would
make normally non-recursive commands like config or register process
all repositories instead. The advantage of this would be that it also
allows you to configure repos with multiple key=value items instead of
just one and the footgun would be hidden behind an explicit option.

   $ mr -r config foo=bar bar=baz

I'm inclined to make these changes to myrepos:

 * Make the config section optional when the current dir is a
   registered repos and derive the section from the current dir.
 * Add a recursive option that would apply to the config and register
   commands and cause them to do their jobs recursively.

In the meantime you should define and use a `mr configure` command.

Further thoughts welcome!

#835566#21
Date:
2019-10-15 02:50:21 UTC
From:
To:
Some further thoughts from me:

If you want to change how the run command works, you can do that in
your mrconfig, the default just runs the args directly:

   [DEFAULT]
   run = "$@"

You could just evaluate it as shell code instead, or run a subshell:

   [DEFAULT]
   run = eval "$*"

   [DEFAULT]
   run = sh -c "$*"

Then you would be able to run something like this:

   $ mr run mr config '$MR_REPO' foo=bar bar=baz

You could create a new configure command to mr config the current repo:

   [DEFAULT]
   configure = mr config "$MR_REPO" "$@"

Then you would be able to run something like this:

   $ mr configure foo=bar bar=baz

myrepos could also change how `mr config` works to make it so that
passing only one argument means that `mr config "$MR_REPO" "$1" gets
run instead of the current action of returning an error. This would
only allow setting one value at a time, make it more convenient to use
when already in a repository but could be a surprising footgun when
used in a directory tree containing many repositories.

   $ mr config foo=bar
   mr config: not enough parameters

Another option would be to create a -r / --recurse option that would
make normally non-recursive commands like config or register process
all repositories instead. The advantage of this would be that it also
allows you to configure repos with multiple key=value items instead of
just one and the footgun would be hidden behind an explicit option.

   $ mr -r config foo=bar bar=baz

I'm inclined to make these changes to myrepos:

 * Make the config section optional when the current dir is a
   registered repos and derive the section from the current dir.
 * Add a recursive option that would apply to the config and register
   commands and cause them to do their jobs recursively.

In the meantime you should define and use a `mr configure` command.

Further thoughts welcome!

#835566#26
Date:
2019-11-14 12:09:04 UTC
From:
To:
Thanks for giving this so much thought. Those things are all valid, I
would probably not come up with this kind of creativity myself. Please
consider writing similary inspiring text in the docs.  No code changes
needed then.

Wouldnt the subshell immediately invoke quoting hell?

Thank you very much.

Greetings
Marc

#835566#31
Date:
2019-11-14 12:09:04 UTC
From:
To:
Thanks for giving this so much thought. Those things are all valid, I
would probably not come up with this kind of creativity myself. Please
consider writing similary inspiring text in the docs.  No code changes
needed then.

Wouldnt the subshell immediately invoke quoting hell?

Thank you very much.

Greetings
Marc

#835566#34
Date:
2019-11-14 12:09:04 UTC
From:
To:
Thanks for giving this so much thought. Those things are all valid, I
would probably not come up with this kind of creativity myself. Please
consider writing similary inspiring text in the docs.  No code changes
needed then.

Wouldnt the subshell immediately invoke quoting hell?

Thank you very much.

Greetings
Marc

#835566#39
Date:
2019-11-15 04:16:15 UTC
From:
To:
Control: clone -1 -2
Control: retitle -2 add --recurse option for `mr config` command
Control: tags -1 fixed-upstream
Control: forwarded -1 http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=975d8dd

I've now added some info to the documentation:

http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=975d8dd

It would make quoting more complicated yes, the eval would too though.

It would still be possible to do quoting properly if the needed quoting
is reasonably simple, complex quoting would make it much harder.

I've made the first change, for the second change there is already a
bug and todo item about detecting/registering unregistered repos and
I've elected to duplicate this bug as a reminder to add recursive config.

http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=5f101a3
https://bugs.debian.org/482371
https://myrepos.branchable.com/todo/detect_unregistered_repos_in_tree/