[00:19] foom: hmm, it'd be possible to do that, I think. [00:20] 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] 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] s/to your revision/to your revision on the private branch/ [00:22] There's no easy UI for that at the moment, but it's certainly technically possible. [00:22] The problem with that is that you have to take a lot of care to avoid ever letting those revs slip out. === bitmonk is now known as bitmonk|sharp [03:20] hi [03:21] i am merging with another branch [03:21] and for some reason, it is taking a bunch of files [03:21] -D them from my branch [03:21] and then +N from the inbound merge branch [03:21] why would this happen? [04:02] 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] when i do my initial import it says it ignored a bunch of files, are these dot files? [04:25] bagueros: the other branch deleted and added those files? [04:25] forsaken: probably - bzr ignored will tell you [04:26] ah, neat [04:26] bzr is kickass === AnMaster_ is now known as AnMaster [12:39] can i use qbzr on a mac? [12:39] or is there a bzr gui for macs? [12:40] qbzr is not really a bzr gui (yet) [12:40] it provides gui for some operations, but you will use it from the command line [12:40] well, it's more than the command line.. [12:40] i know, i don't mind [12:41] the hard part is compiling of pyqt4, I'm not aware of pre-compiled binaries for mac [12:41] hmm [12:41] and macports only has pyqt3 [12:41] damn macs [12:41] any other guis? [12:41] not sure if installing gtk is easier :) [12:42] hmm [12:42] osx comes with X11 installed, not sure which gui toolkit it has though [12:42] it's probably just the X server [12:42] but I think doesn't use X11 on mac now, does it? [12:43] er, gtk doesn't use [12:43] i think it does, e.g. the gimp does use it [12:43] isn't it gtk? [12:43] ah [12:43] yes [12:43] yeah [12:43] bah [12:44] i thought macs had as good support as linux, but it's apparently worse than windows [12:44] hm, http://phanatic.hu/archives/2007/11/building-qt-4-and-pyqt-on-mac-os-x-leopard/ [12:44] it has some leopard binaries [12:44] oh, great [12:44] let me try them out [12:46] hmm, would a linux binary run on the mac (bsd?) [12:47] I don't think so [12:47] 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] hmm, i'll try it and see, then [12:48] for some reason it won't compile on the mac [13:04] pastebin the errors you're getting? (though most likely I won't be able to help) [13:04] ah, it's not bzr-related, it's for an assignment [13:04] it's missing some library... [13:07] ah [13:10] hmm, now it needs sipdistutils [13:14] qbzr, i mean [13:54] Just got done making changes, but "bzr commit" gives "no changes to commit"? [13:54] do a bzr status? [13:55] stavros: the status gives "unknown" [13:55] why do some files and directories show up as unkown in 'bzr status' even after I do 'bzr add'? [13:56] dOb: you have to ignore them [13:56] ushimitsudoki: have you added the files you made changes to? [13:56] Stavros: just now :) I did "bzr add *" [13:57] 2 [13:57] err, sorry [13:57] ushimitsudoki: you need to add them and then commit [13:58] Stavros: I see...to be clear, anytime I create a new file, I need to add it manually? [13:58] ushimitsudoki: i think so, yes [13:58] Stavros: alright then, I will keep that in mind! Thanks much for the assist to the newbie! [13:58] no problem :) [14:00] 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] dOb: no, "bzr help ignore" :P [14:01] hmm... is the .bzr supposed to exist only in the top level dir? [14:02] yes [14:04] 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] ah, good :) [14:25] where can i find sipdistutils for qbzr? [14:43] Is there a way to check which format the repository currenly uses? [14:48] jaalto: bzr info [14:49] Thanks [15:17] -away [15:18] meh, I keep making mistakes on this layout [15:18] hey larstiq (-: [15:18] hey jelmer Ö= [15:18] * LarstiQ sighs [15:18] :) even [15:18] LarstiQ: happy 2008 (-: [15:18] jelmer: thanks, you too :) [15:18] and to dato [15:19] dato: Do you know why the bzr Debian package depends on graphviz? [15:19] jelmer: bzr or bzrtools/ [15:19] bzr [15:19] http://packages.debian.org/source/sid/bzr [15:19] well, it's a build-depends [15:21] jelmer: the changelog says: performance.png or however it's called [15:21] hi LarstiQ, happy new year to you too [15:22] dato: ah, thanks [15:25] dato: thanks, just went out to buy a dishwasher, that will be a happy change at least ;) [15:25] :) [15:32] LarstiQ: you lucky bastard :-P [15:33] jelmer: I'm afraid luck doesn't have much to do with it :-P [16:26] New bug: #180588 in bzr "bzr viz ERROR (bzr 1.0.0)" [Undecided,New] https://launchpad.net/bugs/180588 [17:52] hey all... is there a way for a command to store information somewhere that commit will pick up? [17:53] 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] not that I'm aware of [18:02] there's the -F option to commit, which allows you to specify the commit message in a file [18:02] but I guess you're looking for something that doesn't require additional arguments and would use other metadata as well? [18:10] sounds like a job for a plugin [18:12] jelmer: yes [18:12] jelmer: I can't populate the commit message with a pre-commit hook, can I? [18:15] mtaylor: I don't think you can. You can "wrap" the commit command though and modify its behaviour that way [18:16] 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] mtaylor: yes, you can [18:17] my bzr-nm plugin does that for commit as well [18:17] jelmer: great! I'll go look at that [18:17] it's a bit of a hack, but works quite well [18:17] hey - I'm not opposed to a hack [18:20] out of curiosity, what if you want to use both bzr-nm and mtaylor's plugin? [18:20] will you get both behaviors with 'bzr commit'? [18:20] radix: good question! [18:21] (assuming use of whatever wrapping mechanism you're talking about) [18:59] 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] that could get messy [19:19] is this an ubuntu or bzr bug? http://pastebin.ca/842927 [19:21] or is it a luser (aka me) error, even? [19:22] user error or bzr bug [19:23] try bzr ls | grep ".*~" [19:23] without those quotes *~ gets expanded to a list of all files ending in ~ in the current directory [19:24] so grep probably gets more than one argument and thus ignores stdin [19:24] jelmer: it's a user error... my bad, carry on :) [19:24] and that causes bzr to complain about a broken pipe [19:24] * ryanakca nods [19:26] ryanakca: this probably shouldn't be a backtrace imnsho [19:26] just "bzr: Broken pipe" would be more appropriate [19:27] hence why I said it could be considered a bzr bug :-) [19:28] :) [21:34] jelmer: you don't own bzr-email, do you? [21:36] jelmer: and related to that - where can I find bzr-nm... google isn't seeming to find it [21:40] mtaylor: lifeless owns it I think, I'm just the Debian maintainer [21:40] mtaylor: bzr-nm should be listed on the plugin registry [22:13] jelmer: k. thanks! === Verterok__ is now known as Verterok [22:32] hi [22:34] is there something like a "bzr-miniserver" that doesn't require any web or ftp server? [22:36] the bzr smart server sounds like something completely different [22:37] benny99: yeah, there's the smart server, or sftp [22:38] jelmer: ok, thanks [22:38] :) [23:21] 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] "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] hey guys, can anyone tell me what the current situation is with line-endings on different platforms in bzr? [23:41] 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] 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] anybody have any debs of bzr-gtk for gutsy anywhere? [23:45] bzr-gtk: Depends: bzr (< 0.91~) but 1.0-2~bazaar1~gutsy1 is to be installed [23:48] mtaylor: I don't think there are any outside of the regular gutsy repo [23:48] 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] jelmer: while I'm bugging you... do you know if commit messages for uncommitted revs are stored somewhere?