[06:16] Hi, commits in git can be annotated with one-line descriptions and with multi-line comments, e.g. https://git.ipxe.org/ipxe.git/commit/fcc35bf48776fff9ebfd8db537679583221a9cd4. [06:16] Is there a similar concept in bzr, where I would be able to only see the one-line descriptions e.g. with bzr log, but I would also have the ability to see the analytical comments about each commit with bzr detailed-log or something? [06:25] Hmm it seems that git follows a convention similar to .deb package descriptions, i.e. leaving an empty line between the one-line description and the detailed commit message. [06:25] Does bzr have something similar? [06:26] bzr log --line ? [06:31] * alkisg just found "git log --oneline", try ing "bzr log --line" now... [06:31] Yup, thank you SamB === yofel_ is now known as yofel [11:45] SamB: hi === Quintasan_ is now known as Quintasan [14:50] in a colo, how do I fetch & switch to a remote branch? [17:02] * SamB wants to joke "over SSH"" [17:37] jml: hi [17:37] jelmer: hello [17:37] jml: 'bzr branch --switch lp:foobar file:,branch=bar' [17:37] or manually branch and then 'bzr switch bar' [17:38] 'manually branch'? [17:38] 'bzr branch lp:foobar file:,branch=bar; bzr switch bar' [17:40] ahh. [17:40] the syntax isn't ideal, we're still working on that [17:40] it's hard to get to something that's not ambiguous [17:40] jelmer: so there's 'switch -b' _and_ 'branch --switch' [17:42] jml: yes, 'switch -b' bases the new branch on the current branch [17:44] jelmer: that's a bit confusing. [17:46] jml: in what way? [17:48] jelmer: I guess in my head, 'switch -b' expands to 'switch --branch' (I know it expands to --create-branch) [17:49] jelmer: and looking at 'branch --switch' vs 'switch --branch', I can't figure out which is for which purpose, or why the two would be any different [17:49] I guess it's obvious when you try to implement it [17:49] jml: I don't really like the -b alias for --create-branch [17:49] jml: I think it's there for consistency with 'git checkout -b' [17:49] jelmer: what would you propose instead [18:31] jelmer: pretty sure, yeah [18:31] I'm not sure I didn't suggest that? [19:05] interesting thing i found: http://thread.gmane.org/gmane.comp.version-control.git/189776 [20:59] AuroraBorealis: that was quite interesting [21:00] yeah [21:00] git not having great annotate performance is pretty well known [21:00] its kinda related to that long standing bug where bzr was trying to import a huge repo [21:00] but the giant cold cache penalty seems... surprising [21:00] its interesting to see how any vcs would handle freaking [21:00] 1.3 million files [21:01] I guess it's very filesystem dependant for any operation that peeks at every file in a huge tree [21:01] yeah. one of the suggestions was just [21:01] "get some SSD's " [21:01] I think ext4 also doesn't have seperate metadata blocks? [21:02] so probably ends up needing to read from much more areas of the disk [21:02] does it clump all the metadata together? [21:02] so it doesn't have to skip around? [21:03] I think it doesn't, but some filesystems do, or do to some measure [21:04] i have no idea about filesystems but i was just wondering if any VCS would handle such extreme repo sizes [21:05] some of the comercial ones are certainly more tuned for it. [21:08] but there's also a fair bit of cheating with big beefy central servers and partial checkouts I think [21:08] people were suggesting just splitting it into different repos which just seems like a cop out to the real problem [21:09] which, in the dvcs world, the advice of having more smaller repos is sensible analogue [21:09] heh, you typed faster [21:09] but it's really the same kind of cheat [21:09] yeah, i have no idea what facebook is keeping in there [21:10] i hardly think that just the sourcecode to facebook is 1.3 million indepenent files [21:10] php *is* pretty bad :) [21:12] haha [21:12] i hear you there [23:30] hey jelmer === GRiD_ is now known as GRiD