'push' should default to 'pull' URL

Hi,

Thanks for taking the time to report this bug.

I've marked this bug as "Won't Fix", please allow me to explain why.

When you make a new branch of a project there are two things you would
normally be doing. The first is the one that you are talking about, where
you are getting a local copy of the branch so that you can work on it, and
when you have done that you want to push your changes back, so the behaviour
you request would be correct.

The second reason why you may be getting a branch is to actually branch, i.e.
start a new line of development, for a new feature or similar. In these cases you
may still want to publish your work before it is ready for integration in to the
original branch. If we implemented the behaviour that you ask for then a simple
"bzr push" would push to the original branch, which you would not want in that
case.

There is no way for bzr to tell these two situations apart, so it asks for you to
be explicit by providing a URL.

Recently Aaron wrote the code to allow you to use shorthand for various known
URLs for a branch, which would mean that you could run

   bzr push :parent

the first time, which is less typing.

If there are any other things that you think would improve this situation
then please don't hesitate to suggest them.

Thanks,

James

In the second case, an actual branch, 'push' is probably the wrong command to use; 'send' or 'merge' would be appropriate instead. Bzr may not know the difference between a real branch and a mere copy of trunk, but the user does.

I suppose, in theory, the worst case is that someone could break the trunk until an 'uncommit' is performed. However, giving trunk write access to a sloppy or inexperienced developer seems more like a people problem.

In practice, I doubt a default push URL would cause problems, because hg, git, darcs, bitkeeper, and svk behave this way and nobody seems to complain about it.

So, should bzr assume the user meant what they said (and facilitate the process), or should it assume the user made a mistake?

On Fri, 2008-07-25 at 17:24 +0000, Scott Scriven wrote:
> In the second case, an actual branch, 'push' is probably the wrong
> command to use; 'send' or 'merge' would be appropriate instead. Bzr may
> not know the difference between a real branch and a mere copy of trunk,
> but the user does.

No, neither send or merge allow me to publish my feature branch
to a public server to allow someone else to look at it.

>
> I suppose, in theory, the worst case is that someone could break the
> trunk until an 'uncommit' is performed.

That's true. However, the feature branch may be very immature
and really break things, or cause data corruption for anyone that
used it or similar, so while having a version control system
allows you to clean it up the intervening period when the feature
branch is claiming to be trunk.

There is another, smaller, issue, that anyone that pulls in the
intervening period must pull --overwrite or similar to get back
to what they had before. This gets more complicated if they have
based work on top of it, or merged in trunk and then continued.

These problems obviously exist now, without the change that you
propose, but my argument is that your change would make them
more likely.

> However, giving trunk write
> access to a sloppy or inexperienced developer seems more like a people
> problem.

That is true. However, I don't think that you necessarily have to
be sloppy to trip over this. "hack; commit; push" can be your
routine, whether you are working on trunk or a feature branch.
The difference comes with the first push, which could be a long
while after creating the branch. I think the safety catch is
a good thing to have here.

> In practice, I doubt a default push URL would cause problems, because
> hg, git, darcs, bitkeeper, and svk behave this way and nobody seems to
> complain about it.

I haven't heard complaints, though I haven't been looking. What
we don't know is how many people have tripped over this though.

> So, should bzr assume the user meant what they said (and facilitate the
> process), or should it assume the user made a mistake?

We're not assuming they made a mistake as such, just that they
haven't provided the information about what they intend yet.

> ** Changed in: bzr
> Status: Won't Fix => New

You haven't yet convinced me, but I won't change this back. If
another developer feels the same way then they can do so. If someone
agrees with you they can confirm the bug and work on the patch.

This should be an easy patch to create, so if you really want this
change then you could send a merge request to the list. At the review
stage is where we would find out if this is really "Won't Fix".

Thanks,

James

Patch sent. I'll update this again after the mailing list makes a decision.

It seems I don't have access to mark this "Won't Fix". At least, it's not in the list of states I can assign.

Anyway, after a few dozen messages the mailing list seems to have more or less decided. The conclusion is that the reduced risk of accidental pushes to the mainline is worth the cost of reduced convenience for a semi-common operation, and reduced consistency with other SCM tools. So, this patch is very unlikely to be included.

There are two suggested workarounds:

  - Use "bzr push :parent" the first time, in bzr 1.6 or later. (or, in earlier versions, get the parent URL from "bzr info" and copy/paste it into "bzr push SOMEURL")

  - Use "bzr checkout foo" instead of "bzr branch foo" when you intend to push back to the parent. Also use "bzr update" instead of "bzr pull", use "bzr commit" instead of "bzr push", and use "bzr commit --local" instead of "bzr commit".

Could someone change this back to "Won't Fix"?

Hi,

I wouldn't necessarily give up yet, the patch hasn't been voted on.

However, if you've been convinced that it's not a good idea, then
it may be good to state that on the list, as it will make it easier for
reviewers to make their vote.

Thanks,

James

Oh, I still think it's a good idea, but it looks very unlikely to happen. One or two people seemed to like the idea, but not the core devs. And though it would be nice for some people, it's really a minor detail.

Mostly, this just seemed like an obvious and bite-sized fix.

I can see why it would be rejected, though. The change provides tiny but real benefits for some users, while the drawbacks are large and (so far) theoretical.