bzr bind should use saved push location

[Jeff Bailey]

A reasonably common workflow for me is to bzr push X; bzr bind X. It would be handy if the bzr bind command would use the cached push location.

[John A Meinel (jameinel)]

I also do the same thing. I could have sworn we discussed it, and *didn't* do it for some reason. But the reason escapes me right now.

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Bailey wrote:
> Public bug reported:
>
> A reasonably common workflow for me is to bzr push X; bzr bind X. It
> would be handy if the bzr bind command would use the cached push
> location.

If you use the 'dirstate-tags' format, "bzr bind" will automatically
bind to wherever you were bound last. Does that help your use case?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGC+4V0F+nu1YWqI0RAqU3AJ0WaoXggk6ALxkTQecWwxBs/HuUBACcDvw3
h4oD6bO1NAOqsnuFYZVjWFU=
=hjDQ
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

I think his use case is like mine, where I want to take something I've been working on locally, and turn it into a checkout of a public branch. (newly created).

I do this when working on someone else's plugin. Or if I was working on my laptop without an internet connection.

I personally do this at the same time. So it is a single:

bzr push foo/bar
<up arrow, edit push to bind, enter>

So *my* use case would be "bzr push-and-bind", or 'bzr make-public-checkout'.

On IRC, Jeff was saying he pushes to the public location for a while, before he decides it is easier to just use a checkout.

There is a different use case which is having a checkout, that you then unbind, and then re-bind when you come online, which --dirstate-tags does handle. But I think this is separate.

[Krzysztof Kosinski (tweenk)]

What about a new command 'bzr checkin X' that would work exactly like 'bzr push X && bzr bind X'?

[Vincent Ladeuil (vila)]

What's wrong with 'bzr bind :push' ?

[Krzysztof Kosinski (tweenk)]

"What's wrong with 'bzr bind :push' ?"
It's undocumented :)

[Dr Al (abudden)]

I would like there to be an easier way to do this as well. I often do:

    bzr init-repo --no-trees /path/to/new_repo
    bzr push /path/to/new_repo/trunk
    bzr bind /path/to/new_repo/trunk

I'd really like this to be:

    bzr init-repo --no-trees /path/to/new_repo
    bzr push --bind /path/to/new_repo/trunk

I guess I could use:

    bzr init-repo --no-trees /path/to/new_repo
    bzr push /path/to/new_repo/trunk
    bzr bind :push

BUT, I know that if I use this method, one day I'll do 'bzr bind :push' on a subsequent push and it'll bind to an old location (as I probably won't have remembered to do --remember).

[Jelmer Vernooij (jelmer)]

Related to bug 482347, perhaps a dupe?

[Sam Bull (dreamsorcerer)]

This also affects me when working on Launchpad hosted projects. If I create a feature branch, I will always want to do a push and bind step, to upload it to Launchpad and then have it as a checkout.

Would be nice to have this as a single step. If it were handled by a single bzr command, it would also mean there would be no delay for the bind step, as it can set it up as a checkout as it pushes it to the server.