[00:19] <spiv> foom: hmm, it'd be possible to do that, I think.
[00:20] <spiv> foom: roughly, by merging your changes onto a copy of the branch you want to submit to and making a revision of that (i.e. so you'd have a revision with your changes in it, and two parents: the tip of the target branch, and the tip of your private branch).
[00:21] <spiv> foom: and then by sending just that one new revision to be merged, so that the reference to your revision would be a ghost.
[00:22] <spiv> s/to your revision/to your revision on the private branch/
[00:22] <spiv> There's no easy UI for that at the moment, but it's certainly technically possible.
[00:22] <fullermd> The problem with that is that you have to take a lot of care to avoid ever letting those revs slip out.
[03:20] <bagueros> hi
[03:21] <bagueros> i am merging with another branch
[03:21] <bagueros> and for some reason, it is taking a bunch of files
[03:21] <bagueros> -D them from my branch
[03:21] <bagueros> and then +N from the inbound merge branch
[03:21] <bagueros> why would this happen?
[04:02] <dlee> Belated entry into the discussion of how to have hidden subcommits "collapsed" into one big one:  I thought the following scenario caused subcommits:  bzr bind remoteBranch, bzr commit --local ... (x how many subcommits you want), bzr update, bzr commit ... (to send them all at once as one).  I think the subcommit revnos end up dotted and the big final one is a normal integer revno.  Maybe not "hidden," but at least logically distinct (an
[04:08] <forsaken> when i do my initial import it says it ignored a bunch of files, are these dot files?
[04:25] <lifeless> bagueros: the other branch deleted and added those files?
[04:25] <lifeless> forsaken: probably - bzr ignored will tell you
[04:26] <forsaken> ah, neat
[04:26] <forsaken> bzr is kickass
[12:39] <Stavros> can i use qbzr on a mac?
[12:39] <Stavros> or is there a bzr gui for macs?
[12:40] <luks> qbzr is not really a bzr gui (yet)
[12:40] <luks> it provides gui for some operations, but you will use it from the command line
[12:40] <Stavros> well, it's more than the command line..
[12:40] <Stavros> i know, i don't mind
[12:41] <luks> the hard part is compiling of pyqt4, I'm not aware of pre-compiled binaries for mac
[12:41] <Stavros> hmm
[12:41] <Stavros> and macports only has pyqt3
[12:41] <Stavros> damn macs
[12:41] <Stavros> any other guis?
[12:41] <luks> not sure if installing gtk is easier :)
[12:42] <Stavros> hmm
[12:42] <Stavros> osx comes with X11 installed, not sure which gui toolkit it has though
[12:42] <luks> it's probably just the X server
[12:42] <luks> but I think doesn't use X11 on mac now, does it?
[12:43] <luks> er, gtk doesn't use
[12:43] <Stavros> i think it does, e.g. the gimp does use it
[12:43] <Stavros> isn't it gtk?
[12:43] <luks> ah
[12:43] <luks> yes
[12:43] <Stavros> yeah
[12:43] <Stavros> bah
[12:44] <Stavros> i thought macs had as good support as linux, but it's apparently worse than windows
[12:44] <luks> hm, http://phanatic.hu/archives/2007/11/building-qt-4-and-pyqt-on-mac-os-x-leopard/
[12:44] <luks> it has some leopard binaries
[12:44] <Stavros> oh, great
[12:44] <Stavros> let me try them out
[12:46] <Stavros> hmm, would a linux binary run on the mac (bsd?)
[12:47] <luks> I don't think so
[12:47] <Stavros> ah
[12:47]  * TFKyle sort of doubts it, as MacOSX uses MachO not ELF (though it might be able to load ELF's, dunno)
[12:48] <Stavros> hmm, i'll try it and see, then
[12:48] <Stavros> for some reason it won't compile on the mac
[13:04] <TFKyle> pastebin the errors you're getting? (though most likely I won't be able to help)
[13:04] <Stavros> ah, it's not bzr-related, it's for an assignment
[13:04] <Stavros> it's missing some library...
[13:07] <TFKyle> ah
[13:10] <Stavros> hmm, now it needs sipdistutils
[13:14] <Stavros> qbzr, i mean
[13:54] <ushimitsudoki> Just got done making changes, but "bzr commit" gives "no changes to commit"?
[13:54] <Stavros> do a bzr status?
[13:55] <ushimitsudoki> stavros: the status gives "unknown"
[13:55] <dOb> why do some files and directories show up as unkown in 'bzr status' even after I do 'bzr add'?
[13:56] <Stavros> dOb: you have to ignore them
[13:56] <Stavros> ushimitsudoki: have you added the files you made changes to?
[13:56] <ushimitsudoki> Stavros: just now :) I did "bzr add *"
[13:57] <Stavros> 2
[13:57] <Stavros> err, sorry
[13:57] <Stavros> ushimitsudoki: you need to add them and then commit
[13:58] <ushimitsudoki> Stavros: I see...to be clear, anytime I create a new file, I need to add it manually?
[13:58] <Stavros> ushimitsudoki: i think so, yes
[13:58] <ushimitsudoki> Stavros: alright then, I will keep that in mind! Thanks much for the assist to the newbie!
[13:58] <Stavros> no problem :)
[14:00] <dOb> Stavros: you mean ignore them as in it's a bug or as in I don't want them in my repo? Because I _do_ want them in my repo :)
[14:01] <Stavros> dOb: no, "bzr help ignore" :P
[14:01] <dOb> hmm... is the .bzr supposed to exist only in the top level dir?
[14:02] <Stavros> yes
[14:04] <dOb> ok I had a .bzr in the subdir that was showing some files as unknowns in 'bzr status', I renamed it and now everything is working as expected :)
[14:04] <Stavros> ah, good :)
[14:25] <Stavros> where can i find sipdistutils for qbzr?
[14:43] <jaalto> Is there a way to check which format the repository currenly uses?
[14:48] <dato> jaalto: bzr info
[14:49] <jaalto> Thanks
[15:17] <LarstiQ> -away
[15:18] <LarstiQ> meh, I keep making mistakes on this layout
[15:18] <jelmer> hey larstiq (-:
[15:18] <LarstiQ> hey jelmer Ö=
[15:18]  * LarstiQ sighs
[15:18] <LarstiQ> :) even
[15:18] <jelmer> LarstiQ: happy 2008 (-:
[15:18] <LarstiQ> jelmer: thanks, you too :)
[15:18] <LarstiQ> and to dato
[15:19] <jelmer> dato: Do you know why the bzr Debian package depends on graphviz?
[15:19] <LarstiQ> jelmer: bzr or bzrtools/
[15:19] <jelmer> bzr
[15:19] <jelmer> http://packages.debian.org/source/sid/bzr
[15:19] <jelmer> well, it's a build-depends
[15:21] <dato> jelmer: the changelog says: performance.png or however it's called
[15:21] <dato> hi LarstiQ, happy new year to you too
[15:22] <jelmer> dato: ah, thanks
[15:25] <LarstiQ> dato: thanks, just went out to buy a dishwasher, that will be a happy change at least ;)
[15:25] <dato> :)
[15:32] <jelmer> LarstiQ: you lucky bastard :-P
[15:33] <LarstiQ> jelmer: I'm afraid luck doesn't have much to do with it :-P
[16:26] <ubotu> New bug: #180588 in bzr "bzr viz ERROR (bzr 1.0.0)" [Undecided,New] https://launchpad.net/bugs/180588
[17:52] <mtaylor> hey all... is there a way for a command to store information somewhere that commit will pick up?
[17:53] <mtaylor> like, if I was writing something similar to uncommit that wanted to preserve the commit message and prepopulate the commit message when the changes are recommitted?
[18:02] <jelmer> not that I'm aware of
[18:02] <jelmer> there's the -F option to commit, which allows you to specify the commit message in a file
[18:02] <jelmer> but I guess you're looking for something that doesn't require additional arguments and would use other metadata as well?
[18:10] <mwhudson> sounds like a job for a plugin
[18:12] <mtaylor> jelmer: yes
[18:12] <mtaylor> jelmer: I can't populate the commit message with a pre-commit hook, can I?
[18:15] <jelmer> mtaylor: I don't think you can. You can "wrap" the commit command though and modify its behaviour that way
[18:16] <mtaylor> jelmer: can I "wrap" it with a plugin in such a way that bzr commit calls my wrapping command? Or would need to make a special_commit command or somehting?
[18:17] <jelmer> mtaylor: yes, you can
[18:17] <jelmer> my bzr-nm plugin does that for commit as well
[18:17] <mtaylor> jelmer: great! I'll go look at that
[18:17] <jelmer> it's a bit of a hack, but works quite well
[18:17] <mtaylor> hey - I'm not opposed to a hack
[18:20] <radix> out of curiosity, what if you want to use both bzr-nm and mtaylor's plugin?
[18:20] <radix> will you get both behaviors with 'bzr commit'?
[18:20] <mtaylor> radix: good question!
[18:21] <radix> (assuming use of whatever wrapping mechanism you're talking about)
[18:59] <jelmer> radix: Yes, although I'm not sure what happens if you have two plugins where one depends on the behaviour of the other
[19:00] <jelmer> that could get messy
[19:19] <ryanakca> is this an ubuntu or bzr bug? http://pastebin.ca/842927
[19:21] <ryanakca> or is it a luser (aka me) error, even?
[19:22] <jelmer> user error or bzr bug
[19:23] <jelmer> try bzr ls | grep ".*~"
[19:23] <jelmer> without those quotes *~ gets expanded to a list of all files ending in ~ in the current directory
[19:24] <jelmer> so grep probably gets more than one argument and thus ignores stdin
[19:24] <ryanakca> jelmer: it's a user error... my bad, carry on :)
[19:24] <jelmer> and that causes bzr to complain about a broken pipe
[19:24]  * ryanakca nods
[19:26] <jelmer> ryanakca: this probably shouldn't be a backtrace imnsho
[19:26] <jelmer> just "bzr: Broken pipe" would be more appropriate
[19:27] <jelmer> hence why I said it could  be considered a bzr bug :-)
[19:28] <ryanakca> :)
[21:34] <mtaylor> jelmer: you don't own bzr-email, do you?
[21:36] <mtaylor> jelmer: and related to that - where can I find bzr-nm... google isn't seeming to find it
[21:40] <jelmer> mtaylor: lifeless owns it I think, I'm just the Debian maintainer
[21:40] <jelmer> mtaylor: bzr-nm should be listed on the plugin registry
[22:13] <mtaylor> jelmer: k. thanks!
[22:32] <benny99> hi
[22:34] <benny99> is there something like a "bzr-miniserver" that doesn't require any web or ftp server?
[22:36] <benny99> the bzr smart server sounds like something completely different
[22:37] <jelmer> benny99: yeah, there's the smart server, or sftp
[22:38] <benny99> jelmer: ok, thanks
[22:38] <benny99> :)
[23:21] <dlee> Ok this will probably embarrass me, but... What's the proper way to see what's different between revisions in two branches--for example, diff of r48 in one branch against the tip of the other?
[23:22] <dlee> "bzr diff .:48 ../dgl" (issued in the first branch's dir) complains that the revisions are on two different branches.  But I know that. :-)
[23:37] <stefanv> hey guys, can anyone tell me what the current situation is with line-endings on different platforms in bzr?
[23:41] <dlee> Others can surely answer better than I can, but I believe at this point, the line endings on a file remain as they are when you check the file in, no matter from which OS/platform.  In other words, I am not aware of any conversion of line endings in Bazaar at all.
[23:42] <stefanv> OK, thanks.  I saw that the roadmap includes a blueprint to change this, so I was just wondering whether that had been implemented yet.
[23:44] <mtaylor> anybody have any debs of bzr-gtk for gutsy anywhere?
[23:45] <mtaylor> bzr-gtk: Depends: bzr (< 0.91~) but 1.0-2~bazaar1~gutsy1 is to be installed
[23:48] <jelmer> mtaylor: I don't think there are any outside of the regular gutsy repo
[23:48] <mtaylor> jelmer: aw. darnit
[23:49]  * dlee is surprised there's no answer to his diff-of-branches question; I figured I was missing something obvious.
[23:49]  * mtaylor makes the requsite complaint about the need for a bzr apt repos with up-to-date stuff...
[23:56] <mtaylor> jelmer: while I'm bugging you... do you know if commit messages for uncommitted revs are stored somewhere?