[00:54] <AfC> I have no wish to stop using bzr, but it's becoming less and less optional to not be on github with my code.
[00:55] <AfC> I'm trying to understand what a workflow could be, but since dpush did a rewrite of all my history, am I supposed to throw my old bzr (only) branches away, or...
[00:55] <AfC> ?
[00:56] <jelmer> AfC: you shouldn't have to throw your old branches away - a new 'bzr dpush --no-rebase' from your old branches should be compatible with what's on github
[00:56] <AfC> Huh
[00:56] <AfC> jelmer: So you use `dpush` once and only once, then always `dpush --no-rebase` from then on?
[00:57] <jelmer> AfC: you should be able to always use --no-rebase I think
[00:57] <AfC> jelmer: oh, interesting
[00:57]  * AfC tries that
[00:58] <AfC> jelmer: so, er, why wouldn't that be the default command?
[00:58] <AfC> s/command/option setting/
[00:58] <jelmer> AfC: it's the default, because it's not useful for what dpush was meant for (contributing to upstream projects in git)
[00:59] <AfC> I see
[00:59] <jelmer> AfC: an option setting to disable rebasing would make sense, though you can also add a 'dpush = dpush --no-rebase' alias in ~/.bazaar/bazaar.conf
[00:59] <maxb> Presumably publishing to git via dpush --no-rebase works wonderfully until someone tries to submit changes to you via github....
[01:00] <jelmer> right, it works if you have a mirror but it makes it impossible to merge from git since the histories will be completely unrelated
[01:00] <AfC> maxb: that's the other thing I'm wondering about, though frankly that's secondary
[01:00] <AfC> maxb: I really just want to get my code up somewhere more visible than self-hosting
[01:01] <AfC> jelmer: right. So, if I `dpush` alone, then the branch gets rebased
[01:01] <AfC> that's fine.
[01:01] <jelmer> AfC: yep
[01:01] <AfC> I then continue developing locally
[01:01] <AfC> making [bzr] commits
[01:01] <AfC> then I ...
[01:01] <AfC> er
[01:01] <AfC> um
[01:01] <AfC> use dpush again, and accept that the branch keeps getting rebased?
[01:01] <AfC> I guess I'm trying to understand how that will work vs
[01:01] <AfC> bzr branch a b
[01:01] <jelmer> AfC: that's one way of working
[01:01] <AfC> cd b
[01:01] <AfC> comit, commit,
[01:02] <AfC> bzr missing --line ../a
[01:02] <jelmer> AfC: as long as you dpush before you push the changes anywhere else
[01:02] <AfC> jelmer: [Robert has told me I'm foolish for keeping trying to use Bazaar against a Git storage backend, but :(]
[01:02] <AfC> jelmer: ah
[01:02] <AfC> yes, that makes sense
[01:03] <AfC> so dpush to github [or even just a local throw-away?] and *then* push to my "official" public branches on our webserver
[01:04] <AfC> jelmer: [as always, thanks for your advice]
[01:05] <jelmer> AfC: FWIW I'm just using Git for projects that are in Git these days too
[01:06] <AfC> jelmer: so, I sorta said it before, but the critical need for me is to get my code onto github
[01:06] <AfC> jelmer: it's really just a PR thing
[01:06] <AfC> jelmer: but it's getting to the point where people judge your resume by your github account. I've been challenged for it in an interview once already.
[01:06] <AfC> jelmer: that, cross product
[01:07] <fullermd> Pfft, how hard can it be to hack github and setup bzr hosting on the server?   :p
[01:07] <AfC> jelmer: the language I'm working in these days is *extensively* active on github
[01:07] <AfC> fullermd: :)
[01:07] <AfC> fullermd: I wish
[01:07] <bob2> just using git means you also get to use magit
[01:07] <jelmer> AfC: ah :-( That's a pity, especially the fact that it's about a specific propietary service.
[01:07] <bob2> which is awesome
[01:07] <AfC> jelmer: I know. But the community is there.
[01:09] <fullermd> Well, it could be worse.
[01:09] <AfC> jelmer: [that would, essentially, be the same conversation if we were talking about Twitter vs Identica]
[01:09] <fullermd> Imagine if the important community coalesced around ClearCaseHub instead.
[01:10] <jelmer> AfC: only slightly; Git has the advantage of being distributed, but we then still stick all our repositories on Github
[01:11] <AfC> jelmer: yeah
[01:11] <AfC> jelmer: though, I'm less worried about that; *I* know how to host my code elsewhere :)
[01:11] <jelmer> AfC: :-)
[01:11] <AfC> jelmer: the fact that it's a single point of failure for everyone else who thinks DVCS are centralized is their problem :)
[01:12] <jelmer> AfC: So, I think I agree with lifeless here.. maintaining a copy of your work in two DVCSes is a lot more pain than in one, especially given the somewhat beta state of bzr-git's dpush support.
[01:13] <AfC> jelmer: don't be saying that. You're my last shred of hope that I can keep using bzr in the face of overwhelming numbers of employers/clients who otherwise have no idea what I'm talking about
[01:13] <fullermd> Funnily enough, I've got a bzr project somebody else put on github  ;p
[01:14] <fullermd> Though that went the other way; they used git-bzr to yank it in.
[01:15] <AfC> fullermd: hm
[01:15] <jelmer> AfC: if you don't care about pulling in contributions from github then bzr-fastexport+git-fastimport (which is basically what git-bzr is) is certainly also a good option
[01:17] <AfC> jelmer: well, I wouldn't want to be hostile to contributions from there
[01:17] <AfC> jelmer: reality is, that's where they're going to see the code
[01:18] <jelmer> AfC: dpush (with rebase) should indeed be quite suitable in that case
[01:21] <jelmer> AfC: without somebody actively maintaining bzr-git it's likely to break at some point though, as is happening with some repositories because of new git features
[01:22] <mgrandi> hey, does anyone have any experience with bzr serve? i'm messing around with it
[01:22] <AfC> mgrandi: sure. What's your question?
[01:23] <fullermd> You're not supposed to mess with it, it doesn't have any sense of humor at all.
[01:23] <mgrandi> im not sure how im supposed to use it, is the ssh server supposed to be listening on 4155 (the default port), but then bzr serve can't bind to that address
[01:24] <mgrandi> and if ssh isn't listening on 4155 and bzr serve is, then i get "bzr: ERROR: Unable to connect to SSH host mgrandi.no-ip.org:4155; Error reading SSH protocol banner"
[01:24] <jelmer> mgrandi: the plain bzr server listens on port 4155
[01:24] <AfC> Running bzr [serve] as a daemon is not SSH protected
[01:24] <jelmer> mgrandi: the ssh server is basically just 'bzr serve' executed over the ssh protocol, on the regular port
[01:25] <mgrandi> yeah i noticed that, is that basically waht its intended for?
[01:25] <jelmer> mgrandi: yep
[01:25] <mgrandi> that the client just runs bzr serve?
[01:25] <mgrandi> and then it exits?
[01:26] <mgrandi> seems like that would be slower
[01:27] <jelmer> mgrandi: there is some overhead involved, but starting up bzr isn't that slow, especially compared to the ssh handshake
[01:28] <mgrandi> but either way its faster then using sftp?
[01:28] <AfC> mgrandi: hugely so
[01:28] <AfC> SFTP is a disaster zone
[01:28] <fullermd> Again, could be worse; could be FTP...
[01:28] <mgrandi> well on my remote host i can't install stuff to root, is there a way to modify what path of bzr it asks for?
[01:29] <fullermd> (that's what's great about the internet; there's always a worse idea somebody's gonna force you to use sooner or later...)
[01:29] <jelmer> mgrandi: you can set the 'BZR_REMOTE_PATH' environment variable
[01:29] <fullermd> Or just put where it is in your remote $path.
[01:29] <mgrandi> oh thats true
[01:30] <mgrandi> there is just little documentation about serve, its mystical~
[01:32] <mgrandi> so after it calls bzr serve how does it tell tell the computer (running bzr serve) what it needs?
[02:24] <spiv> fullermd: updating your remote $PATH won't help, unless you mean via some system-wide mechanism (/etc/environment?)
[02:28] <fullermd> Sure it will, it just runs 'bzr'.
[02:52] <spiv> fullermd: right, and it doesn't run .bashrc (or whatever your shell of choice is)
[02:53] <spiv> So if you try to update your PATH for your account the way you usually do, it won't help.
[02:55] <mgrandi> doesn't ssh do that when it connects? i know putty does
[03:01] <fullermd> That's a shell specific thing.
[03:01] <fullermd> I don't know offhand what config file weird-ass shells like bash load on non-interactive sessions, but there is one.
[03:01] <fullermd> For me, it does work just fine, since I use a sensible shell  ;p
[03:05] <fullermd> e.g.: % bzr ping bzr+ssh://localhost/      [...]  Headers: {'Software version': '2.6.0dev3'}
[03:05] <fullermd> Unless'n you think I'm nuts enough to system-wide install bzr.dev...
[03:05] <fullermd> (and in fact, in this case, it's not even $path; 'bzr' is a shell alias getting invoked, pointing over to .dev)
[03:09] <spiv> fullermd: the point is that sshd *won't run your shell*, IIRC
[03:09] <spiv> Because the SSH client is not requesting a shell.
[03:09] <spiv> It's asking to run a command.
[03:09] <fullermd> Er.  Yes it does.  It has to; that's how the login process works.
[03:10] <fullermd> Otherwise setting your shell to /usr/sbin/nologin or similar artifacts would have no effect, as you could just 'ssh host /bin/sh' or the like to bypass them.
[03:10] <fullermd> The shell is what runs the command you ask for.
[03:13] <fullermd> It runs the shell in _non-interactive_ mode, which means if you're using a shell that reads different rc files based on that you'd need to know it and set things in the right place, but that's a separate matter.
[03:13] <spiv> I may be getting confused with subsystems...
[03:14] <fullermd> Possibly.  Subsystems are a whole different ball of mud.
[20:15] <Tolstoy> When my colleague does a bzr diff, we see a revid on the files that have changed. When I do it, I get a date. Is there some way I can change that?
[20:16] <Tolstoy> bzr 2.5.1
[20:54] <Tolstoy> bzr diff rebid plugin was the trick.
[20:54] <youlysses> Now obviously you guys may be a bit biased, but how comparable is bzr to git speed-wise?
[21:02] <fullermd> I'd say somewhere between "indistinguishable" and "terribly slower", depending on the cases you're comparing.
[21:02] <fullermd> It probably averages out to moderately slower, day to day.
[21:08] <youlysses> fullermd: But it's not a *huge* deal, assuming you aren't doing a ton at a time?
[21:10] <fullermd> Probably not, unless you hit degenerate cases.
[21:10] <fullermd> Seems the usual case we hear about is initial branching on giant projects.
[21:12] <youlysses> fullermd: Yeah for my current needs, I have nothing "massive" to really worry about... or alteast I hope-so. :-P
[21:36] <ZyX-I> Hello. How can I know what statuses may be shown in “bzr status” output? Except for reading “bzr help status” (it is incomplete) and bazaar source code (it is hard to find out the answer there).
[21:37] <lifeless> ZyX-I: its incomplete?
[21:38] <ZyX-I> lifeless: Yes.
[21:40] <lifeless> ZyX-I: a little more detail would be useful, or perhaps file a bug. I was not aware that it was incomplete.
[21:43] <ZyX-I> lifeless: There are at least three statuses that are not listed there: missing (don’t remember how to reproduce), ignored and unexistent (just supply bzr status ignored or unexistent paths). It looks like there are also two merge-related statuses.
[21:44] <lifeless> hmm - please do file a bug
[21:44] <lifeless> help status is where it is *meant* to be documented.
[21:46] <ZyX-I> lifeless: For missing: add a file using “bzr add” and then remove it using just “rm”.
[21:47] <lifeless> ZyX-I: yes
[21:48] <ZyX-I> It is for bzr-2.5.1.
[22:00] <ZyX-I> I like the idea of telling me about invalid password when it was meant that I have not activated my account.