Bazaar

Push should create a README file in destination folder

Bug #45677 reported by John Dong
4
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Low
Unassigned

Bug Description

When bzr pushes a branch to a location, it just updates the .bzr/ folder, which is perfectly acceptable behavior by all means.

However, I find that when I tell people that "my bzr branch for foo is at http://foo/url", the most common response I get back is "Are you sure? It's empty."

I then have to explain how there's a .bzr, and use "bzr branch" to get the actual folder.

It'd be nice if push could create a simple README or (README.bzr) file that explains all of this (i.e. this is a bzr branch, a web browser cannot understand it. Use bzr branch URL to retrieve it; go to bazaar-vcs.org for more into)

Revision history for this message
Michael Ellerman (michael-ellerman) wrote :

I agree that it's a bit confusing. I wrote a plugin to generate a nice HTML page, which I stick in the root of my branches.

http://michael.ellerman.id.au/files/bzr/htmllog/

I haven't bothered, but I think you could call the plugin as a post-commit hook so as to always have it updated.

Making it part of the default push behaviour seems a little tricky, simply because you might have an index.html/README already in your tree. But we can probably work out something sane.

Changed in bzr:
status: Unconfirmed → Confirmed
Revision history for this message
David Allouche (ddaa) wrote :

I'm not sure this bug is the right place to comment on the htmllog behaviour, but I cannot thing of anything better.

Is it really necessary to show off the revision ids in the output of htmllog? Revision ids look messy, do not contain any human readable information that's not in the date or comitter, and are not normally needed to use bzr.

Making revision ids an implementation detail is a design goal of bzr, they should not be advertised this prominently.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.