openstack team mailing list archive

[andi abes <andi.abes@xxxxxxxxx>]

I'm not sure who wins in git vs. bzr ease of use... guess it depends on how
quickly I get over this error:

$ bzr pull lp:swift/1.3
bzr: ERROR: Cannot lock LockDir(
http://bazaar.launchpad.net/~swift/swift/omega-1.3.0-7/.bzr/branch/lock):
Transport oper
ation not possible: http does not support mkdir()


any idea ?

On Wed, Apr 27, 2011 at 1:37 PM, Soren Hansen <soren@xxxxxxxxxxx> wrote:

> 2011/4/27 Thomas Goirand <thomas@xxxxxxxxxx>:
> > On 04/27/2011 11:26 PM, Soren Hansen wrote:
> >> To get working, yes. To be an expert, no.
> >>
> >> bzr lp-login
> >> (bzr init-repo)
> >> bzr branch
> >> (bzr add)
> >> bzr commit
> >> bzr push
> >>
> >> ..are sufficient to just get started.
> > No, I don't agree, it's not enough. See below.
>
>
> >>> and that's most of the time the issues with "using bzr for git users"
> >>> tutorials: they tend to think that you're ok with the most basics
> >>> command, and that you wont ever need more. Truth is you do, and
> >>> finding the relevant information for the thing you need takes time (a
> >>> big cost, to use your own words...).  If you find a "learning quickly
> >>> advanced bzr commands for git users" type of tutorial, I might change
> >>> my mind! :)
> >>
> >> If you can explain what sort of stuff you've had a hard time finding, I
> >> can probably whip up something that will be helpful to others.
> > - git reset --hard <sha256>
>
> bzr uncommit -r <revisionspec>
>
> that leaves the changes in the working directory, though. You can use
> "bzr revert" to remove the changes from the working directory.
>
> > - git commit -a --amend (to correct the latest commit)
>
> bzr uncommit ; bzr commit
>
> > - git format-patch <sha256>
>
> bzr log -c <revisionspec> -p
>
> > - or maybe instead: git diff -u -r <sha256> -r <sha256>
>
> bzr diff -r <revisionspec>..<revisionspec>
>
> > - git push --force (you told me, but I forgot... is that bzr push
> > --overwrite?)
>
> "bzr push --overwrite", but please don't use it. It's the same for
> git, really. Once you've pushed it somewhere, don't remove stuff from
> it, or rebase it or whatever. If anyone has pulled from it and based
> work on it, it's extremely awkward if they want to sync up with you.
>
> > - git cherry-pick -x
>
> bzr merge -c <revisionspec>, but its use is discouraged.
>
> > - git -r branch (does listing branches on the remote side even make
> > sense with bzr?)
>
> No.
>
> > - git tag (to list tags, as bzr tag <tagname> seems working)
>
> bzr tags
>
> > There must be more than I can't recall just now, in 5 minutes of deep
> > thoughts.
>
> I still don't see how any of the above are *required* to start working,
> though.
>
> > Also, one thing I love with git, is that I can always do "man
> > git-command" if I want help with "command", and there's more than 100 of
> > them. Is this available somehow?
>
> "bzr <subcommand> -h" shows the help for the subcommand.
>
> "bzr help <foo>" is roughly the same, but it provides help for a bunch
> of things other than commands.
>
> "bzr help commands" shows you (almost) all the available commands (bzr
> help hidden-commands shows a few extra commands that most people will
> never need)
>
> "bzr help topics" shows a bunch of topics that has more extensive
> explanations.
>
>
> --
> Soren Hansen        | http://linux2go.dk/
> Ubuntu Developer    | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>