[00:01] sinzui: just got back from vet, haven't looked at log yet. does the above scrollback mean your ppc64 tools issue is solved? [00:02] wallyworld, almost. The tools not found issue was because juju was swallowing a 403 [00:02] well that sucks, the error needs to be propagated [00:03] wallyworld, I need to get creative with /etc/hosts to get access to download the actual tool. the lab shouldn't need access to the tools [00:04] wallyworld, This is a cases where streams.canonical.com is the correct site to get tools., but ubuntu didn't build tools to put there [00:05] ok [01:32] axw: morning. standup? [01:32] wallyworld: morning, otp with waigani [01:33] ok, ping me when you're free [01:42] wallyworld: free now [01:43] wallyworld: sorry, for stealing axw, didn't realise it was your standup [01:57] wallyworld: I need to get a proper webcam... I get that weird crackly feedback, but only on G+ for some reason [01:58] G+ maxes out my cpu also [01:58] so it's not my favourite [02:08] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1317197/comments/14 [02:08] <_mup_> Bug #1317197: juju deployed services to lxc containers stuck in pending

[02:08] I hope that's clear enough [02:09] yeah, looks good, thank you [02:10] we do the the status stuff at some point cause if things take a while to complete that's useful [02:10] yes absolutely [02:11] just didn't want ryan to think we were doing something that we weren't [02:26] wallyworld: in order to speed up downloading of cloud images is there a way to specify a root image tarball to lxc-create via juju? [02:26] its only 175M so not a huge deal but times like tonight its slow for some reason [02:26] not that i am aware of directly. maybe you could put the tarball in the lxc cache dir [02:27] wallyworld: ahh good idea [02:27] the same place where lxc would put it [02:27] can use juju scp or something [02:27] not sure of exact details [02:27] wallyworld: ill mess around with it and let you know [02:27] ok [02:29] wallyworld: it is so much faster already btw [02:29] great :-) [02:29] demos going well? [02:30] yea there is a contest going on in getting an openstack cloud deployed in under 30 minutes [02:30] i think i can make that happen with this cloning [02:30] all in kvm's/lxcs [02:30] the quickest install is 33 minutes i think [02:31] are you deploying stuff to the kvm instance? [02:31] of just to the lxc containers? [02:31] yea ive got like 8 kvm's running [02:31] 1 kvm with nested lxcs for cloud controller and other bits [02:31] 1 for compute [02:31] 3 for swift, and 3 for swift-proxy [02:32] so all charms are deployed to lxc [02:32] so 8 kvms and 7 lxcs [02:32] swift, swift-proxy, nova-compute are on separate kvms [02:32] but everything else is on lxcs nested within 1 kvm [02:33] there's a bug whereby if you deploy charms to kvm *and* start lxc containers within that kvm host it could fail [02:33] but sounds like you are not affected [02:33] i manually bind the lxc bridge to eth0 in the kvm [02:33] with some juju scp magic [02:34] and restart the kvm node before deploying the lxcs [02:34] ok [02:34] wallyworld: otherwise https://bugs.launchpad.net/juju-core/+bug/1304530 [02:34] <_mup_> Bug #1304530: nested lxc's within a kvm machine are not accessible

[02:35] that issue happens [02:35] yeah, that's being worked on this cycle [02:35] ok cool [02:35] not a blocker since i can work around it [02:35] good :-) [02:35] yea i think if the nested lxc's would honor the network-bridge option in the environments file [02:35] that could work [02:36] but im sure there is a better approach [02:37] i'm not sure tbh, but at this point any approach that works is good i reckon [02:37] davecheney: do you have a list of the tests that currently fail on power? [02:38] thumper: two secs [02:38] didn't I include that in my mail ? [02:38] wallyworld: im sure people will want vlan support within those lxc's maybe [02:38] understandable [02:39] though it probably only matters with local provider [02:39] since maas does vlan now [02:42] davecheney: no, there was a link to the ppc64el bugs in juju-core, but no list of currently failing tests [02:42] davecheney: what does SGTM mean in a review comment? Sounds Good To Me or Silently Giggling To Myself? :) [02:42] menn0: the frist [02:43] davecheney: thumper: I figured. Next question, does the landing bot treat SGTM the same as LGTM? [02:43] I don't think so [02:43] ok thanks for clarifying [02:44] menn0: sounds good to me [02:44] I saw davecheney use it and wasn't sure if it has special meaning to the landing bot [02:44] davecheney: also, any idea why juju/errors tests fail with gccgo? [02:44] davecheney: I can't see it myself [02:45] davecheney: given that I had the ones in arrar passing with gccgo [02:47] on da phnoe [02:48] kk [02:49] menn0: the sgtnm/lgtm thing comes from code review [02:49] lgtm (case insensitive) trigger the green success line in code review [02:49] thumper: we want to introduce a universally used base test suite to kill outgoing http egress, protect the user's home real dir, encapsulate loggingsuite etc - do you like the name "BaseSuite"? [02:49] even if you say [02:49] there is no way in hell i would lgtm this in a millino years [02:49] wallyworld: sounds fine [02:49] it's still a thimbs up [02:49] so, sgtm is a way of saying i like it, but i'm not prepared to put my name to it [02:50] thumper: i'll take a look a tthe errors tests now [02:50] i have trusty and gccgo [02:50] davecheney: to avoid the juju/errors package [02:50] you could just start with juju/errgo [02:50] davecheney: makes sense. thanks. [02:50] which also fails with gccgo [02:50] get the foundations right first I guess [02:52] thumper: got time for a hangout [02:52] yup [02:53] i think i'm confused about which error packge is broken [02:53] :) [02:53] this being able to hangout with your boss thing is sorta neat [02:53] ... only taken 2 years [02:54] davecheney: https://plus.google.com/hangouts/_/g36ayyi6golhypoflszins4leia?hl=en [03:03] wallyworld: if you haven't thought about this already: the thread on signature wrapping reminds me that we should create a git pre-push hook, a la lbox.check [03:04] wallyworld: also, would be nice to run the checks in the lander bot, if we don't already [03:04] agree with lander bot checks, hadn't thought of a pre push hook [03:04] sounds like a good idea [03:06] i was deferring thinking about it till next week when hopefully there'll be some progress on the jenkins side of things [03:08] wallyworld: we do that https://github.com/juju/juju-gui/blob/develop/HACKING.rst#hooks and then in our CI lander side http://ci.jujugui.org:8080/job/juju-gui-merge/ [03:09] rick_h_: awesome, thanks, we'll look to do something similar [03:09] wallyworld: yea, let me know if you want a run through the lander stuff we setup when you get that far https://github.com/juju/jenkins-github-lander [03:10] rick_h_: will do. curtis was going to start looking at setting up juju-core's jenkins next week [03:10] wallyworld: cool [03:10] i already have a migrated repo to test with [03:10] very nice [03:10] github/wallyworld/core [03:11] when you get the migration script let me know. We want to move more stuff over but we didn't have it collapse commits so our history is messy [03:11] has a pending pull request to merge and everything :-) [03:11] :) [03:11] i have the migration steps which i follow, and i think i collapsed history [03:11] cool maybe I can see if sinzui's team has the bandwidth to subordinate the lander code for jenkins [03:11] wallyworld: cool, yea when I use bzr fast import it didn't collapse so lots of old commits of "fix lint" [03:12] rick_h_: i used these steps http://flexion.org/posts/2012-10-migrating-bzr-to-git.html [03:13] rick_h_: as a rule, i hate how git workflow seems to be to rebase out history [03:13] throws away information [03:13] bzr's model is much nicer [03:13] yea, but it's usually useless information ime [03:13] hide it by default, but show it if needed [03:13] but I can appreciate both sides [03:13] wallyworld: can you please update gomaasapi on the bot? [03:13] sure [03:14] rick_h_: is there a way to see old comments in GH after you rebase? [03:14] line comments [03:14] wallyworld: can you see https://bazaar.launchpad.net/~rharding/juju-gui-lander/trunk/files [03:14] axw: it leaves the comments, but marks them as "xxx commented on an outdated branch" [03:15] hmm, when I have done PRs the comments always disappear after I rebase and push -f [03:15] rick_h_: yep [03:16] wallyworld: so might be useful to sinzui as well I don't know. That's the scripted setup we used to migrate [03:16] wallyworld: the git upload, the jenkins deploy/initial install/etc [03:16] rick_h_: ok, ta. i've sent curtis the link previously [03:16] wallyworld: there's some api creds and such in there which is why it's private [03:16] ah ok [03:16] well, i think so [03:17] that doesn't look right [03:17] bzr-git and git-bzr can preserve commit histoyr [03:17] I symlink my .bazaar/ignore to .gitignore [03:18] axw: https://github.com/juju/juju-gui/pull/303 (hatched commented on an outdated diff 2 days ago) [03:18] sinzui: i think the issue is we need to rebase to get a single revision for merging? [03:18] axw: and click on the '2 days ago' to get the comment in with a snippet [03:18] rick_h_: cool, thanks [03:19] aaaaaaaaaaand, that's lunch [03:19] axw: gomaasapi on rev 50 now [03:19] wallyworld: thanks [03:20] wallyworld, Yeah, git is like multi-inheritance diamond parents. Just fucked. bazaar was smart in that respect. the left-hand ancestry is special and we can traverse that to learn the direct commits and choose to go deeper later [03:20] wallyworld, rebase is essentially a hack to fix a logging problem [03:20] heh, every commit is in teh reflog, just how easy can you get at it ;P [03:20] * wallyworld will miss bzr :-( [03:22] wallyworld, since juju likes informative commit messages with links, it is essentially at odds with most projects that use git. They want all the details squashed to a single line [03:23] yeah, i hate that :-( [03:24] huh? I disagree with that [03:25] wallyworld, We might have a policy to never delete the branches from our public repos. They have all the commits. The merge bot will create a squashed commit using the pull request subject and description [03:26] might be all we can do [03:26] the merge bot would include the link to the source branch with preserved history [03:26] No one needs to rebase [03:26] maybe auto push to a second remote to track all commits? [03:27] it'll be a bit nuts to have all branches ever in github [03:27] and we force users to fork so they can keep their branches in their own fork if they want [03:27] so that the main repo looks clean [03:28] https://github.com/juju/juju-gui vs https://github.com/mitechie/juju-gui [03:30] rick_h_, I assumed that developers would be using the triangle trade arrangement. The juju/juju just has stables a devels with the squashed revs. The commit message will have a link to the developer's repo with the squashed revs [03:31] But we could have juju/juju-deep which is where the merge bot puts a copy of the unsquaded branch [03:33] juju/juju? [03:33] are we not having juju/core? [03:34] not, it's juju/core [03:34] s/not/no [03:34] sgtm [03:34] juju/sgtm [03:34] lol [03:34] otherwise we'd have "github.com/juju/juju/juju" [03:34] yeah, no [03:34] we decided at the sprint it would be core [03:34] \o/ [03:45] hmm... [03:45] I notice that the .jenv file has a user and password entry at the top of it [03:45] but both are empty strings [03:45] why? [03:46] * thumper steps away for a bit as heaps of calls later tonight [03:46] * thumper needs to put on dinner === axw is now known as axw-lunch [04:59] can anyone confirm whether it's possible to use API and state port numbers other than the defaults? [05:01] I know they can't be changed once an env is bootstrap but could someone use a different value at bootstrap time [05:06] menn0: yes I have done this in the past [05:06] it's necessary when using the local provider with multiple users on the same host [05:06] ok cool. [05:07] I was reviewing a change to "juju restore" and noticed it generates bash scripts with hardcoded port numbers. [05:07] I guess my review comments are valid concerns then :) [05:07] cool [05:07] thanks [05:08] was just about to review that. now I have to stop procrastinating... :) [05:10] perrito666: the journal thing is a parameter we have to pass on the Session/Write request. [05:10] fwereade: ^^ [05:12] wallyworld: fwereade: IIRC the specifics of why we fallback was because we had the "released" vs "daily" streams, and it was searching the "daily" and not finding any "released" items and then stopping. And when we discussed it, it seemed better to keep searching. [05:13] jam: and also, people adding their own images etc as overrides [05:14] i'm ok with it, william seems twitchy about it [05:16] wallyworld: pre-checks ala lbox propose, we *can* but if it is things like "go fmt is sad" I'd rather just have the box run go fmt and clean things up than stall someone to tell them to go run a command and propose again. [05:17] i don't mind either way tbh [05:17] wallyworld: you don't have to rebase, and I'd rather we didn't have single commit for review [05:18] git does have "git log --follow-first-parent" [05:19] my git foo is poor, i'm just going by what curtis etc said at the sprint. curtis will be doing the landing side of things pretty much so we can liaise with hin to et the model right [05:19] I certainly don't have final say in any of this, but while I don't think we need all branches on master, I'd really rather we didn't rebase to land [05:20] i think it was being canvased to allow a single rev to be easily cherry picked etc [05:20] like we do with bzr with backports etc [05:20] wallyworld: for cherrypicking you can do "merge ABCD ~ ABCD^" IIIRC [05:20] wallyworld: which is the same meaning as "bzr merge -c" [05:20] just different syntax [05:20] $REV^ is the parent of REV [05:21] aka, before:REV or REV-1 to bzr users [05:21] i'm totally ok with whatever folks who know git recommend [05:21] wallyworld: well in the git world you can still do things in different ways, I'd like to push back on how the gui guys decide [05:21] decided [05:21] because I think you can use git in a form that allows easier exposure of specific detail [05:22] i don't like how git rebase discards history [05:22] Though, TBH, if rebase still refers to the old commits in a sensible fashion, that might be ok, but I don't quite see how it works [05:22] if we can work aornd it, great [05:22] vs giving you the detail only if you have the magic revs that aren't pulled in by default [05:22] i just want to it work like bzr :-) [05:23] so for dev workflow, i hope we just push up the raw branch, and let the landing bot sort out how to deal with the final merge [05:24] so we need to talk to curtis et al about the rules for that [05:24] wallyworld: interestingly you can "git rebase --exec $RUNMYTESTSUITE" which is nice [05:25] what does that do? rebase and then run the tests? [05:28] wallyworld: I believe it runs the test after each rebased commit [05:29] ok [05:31] wallyworld: conceptually I'm hesitant about throwing away history. Though having someone actually spend time to make sure there is logical meaning to commits is nice, having a policy of "throw away all the stuff you were thinking about at the time and only give me a summary" isn't great either. [05:32] Often when spelunking I'd really like to understand why someone changed *this exact line* rather that "this was changed as part of doing foo" [05:32] jam: i'm +1 on that, hence i dislike rebase [05:35] wallyworld: jam: I get what you guys are saying. There are definite downsides to overuse of rebase but that's more a policy/process thing IMHO. [05:35] menn0: gui's policy is that every commit gets squashed when merging to master [05:35] which I disagree with [05:36] i guess they view commit history as noise? [05:36] wallyworld: jam: one thing I'm finding with bzr is that I'm committing less often because I know it's much harder to go back and tidy things up. [05:36] wallyworld: by default "git log" shows everything in time-sorted order [05:36] it doesn't have the indented logging that bzr has [05:37] which is poor :-( [05:37] so you don't have "here is a summary commit, and here are the commits that made up that summary commit" [05:37] exactly [05:37] git log output has tons of configuration options [05:37] wallyworld: yes, but we paid *a fuckton* of CPU for it that lots us a lot of hearts and we weren't quite good enough at explaining why [05:37] it is actually quite expensive to compute [05:37] menn0: but not that one [05:37] it does have --follow-first-parent [05:37] brb [05:37] which will get you "bzr log -n1" [05:37] and it does have topological sorting [05:38] but topo doesn't help when 2 people are doing concurrent work [05:38] neither one is "before" the other [05:38] the sort bzr uses is "include a commit after the last commit that didn't have it, and before the one that does" [05:39] but doing the "what commit doesn't have this" is expensive to compute [05:39] O(n) ? or O(what?) [05:39] fwereade: https://codereview.appspot.com/98260043 [05:39] * menn0 is back from dealing with vomiting child... [05:41] wallyworld: so to be able to compute lots of them fast, the algorithm isn't bad if you just walk the whole history, as you can push on a stack everything you've seen so far. So the one we use is O(N=all_history) [05:41] to do it by walking just a bit of the graph [05:41] it easily gets into N^2 or N^3 or thereabouts because of needing to do backtracking [05:41] so N is smaller, but the order is higher [05:42] ok [05:42] wallyworld: so I still love it, and for histories the size of Juju it is actually still a wonderful view of the world (IMO) [05:42] but for things like the kernel/mozilla/etc it made things slow [05:43] and, of course, it is off by default in bzr, too with "bzr log -n1" being the default [05:43] fwereade, bodie_ I made some changes after the discussion today and put in a new MR. I didn't implement the Unit cleanup yet. Some prerequisites still arent in. [05:44] jam, wallyworld: would it help if we followed a different policy than the GUI team in terms of squashing commits. it's not a given that we do that is it? [05:44] wallyworld: "time bzr log -n1 -r -10..-1" vs "time bzr log -n0 -r -10..-1" is 85ms vs 250ms on juju today, which is noticeable [05:44] menn0: no it isn't a given, but that's why I'm bringing it up [05:44] we can decide how *we* want to do it [05:44] menn0: we *are* switching to git, that has been enforced on us [05:45] :-( [05:45] in my experience that's not at all standard practice [05:45] menn0: but the details are what we are hashing out, and I'm just participating in the discusison [05:45] with git projects [05:46] jam: i was going to experiment a bit once the test landing bot on my test repo got set up next week [05:46] on projects that use git that i've worked on, people might do some tidying up with rebase before pushing but rarely down to just one commit. [05:47] menn0: so I think some cleaning up can be nice, but often I've wished people would have committed *more* detail because they aren't explaining the actual steps, just the global chunks [05:47] it's usually about making things more coherent and easier to follow for other developers (and yourself in 2 weeks) [05:47] jam: I get that. [05:48] different people use different approaches when committing and rebase makes it easier for people to hide detail [05:49] perhaps the best we can do is educate each other as part of the review process [05:50] if you feel like someone didn't break up their commits into small enough pieces then call them on it [05:50] menn0: there seem to be projects in git that review your merge by the commits you did, so you have to clean it up into logical steps. Which can be good, but you can also lose some of the "why is it this way". [05:50] menn0: I really like the default of looking at the global thing rather than the individual bits , we can have multiple branches for landing something that needs evolution [05:50] I'm not sure the github default view, though. [05:51] Does it default to the global commit change or the individual commits? [05:52] menn0: so if merge --squash or rebase had a way to still reference the old commits and just not show them by default in log, that would be ideal for me, but I haven't seen a tool that really separates the two [05:52] jam: yeah I've never heard of such a thing [05:53] menn0: so looms was bzr's evolution towards that, and bzr-pipelines is a good approximation of it. Where you have several branches and you are iterating among them. [05:53] with git once you squash revs those old revs are effectively gone [05:53] And the tips of each branch are the "patch for review" while the individual commits are still there. [05:53] jam: yeah i've read a little about looms [05:53] and then in bzr when you merge a commit, by default you only see the merge commit, rather than the details, but the details are all there. [05:54] menn0: and certainly things like stacked-git, or quilt, etc are also similar approaches. [05:55] though again, most of those are explicitly squashing the intermediates down to the final patch [05:57] menn0: like I think stacked git is actually a great workflow, but I wish it actually kept the intermediates as an alternate view. [05:58] i've just been looking at the stacked git site and yeah it doesn't look it helps with keeping the intermediate commits [05:58] menn0: looms/stacked-git/etc have lots of nice process built in for managing multiple branches that you want to eventually apply all together, but still keep things in logical chunks [05:58] like what I'm working on now for the API Versioning has about 4 logical steps [05:59] start doing the internals, start exposing it on the server, start consuming it in the client, etc. [05:59] it is great to separate those out and still sync between them [05:59] jam: yep that makes sense [05:59] bzr pipelines lets you create a "pipeline" aka stack of branches, and then switch to the first one, and "pump" the changes through the pipeline. [06:00] jam: in the past I've done that kind of thing manually but it gets tricky when you get beyond a handful of concurrent branches. [06:00] jam: a tool to help would sometimes be nice [06:01] menn0: yeah, I don't know state-of-the-art with git here. I bzr-pipelines are used the most on our team, and got the most love and attention. Looms had a potentially better data model, but were a bit bigger picture (you could merge looms at the conceptual loom level), and didn't actually get as much polish [06:01] the idea being that you could collaborate on the set of patches that are being tacked on [06:02] which is stuff that OS people do [06:02] because they track UPSTREAM and have their local (deb) patches applied, and need to sync from what Debian is doing to how Ubuntu is doing, etc. [06:02] wallyworld: are you fixing the TestConstraintsValidator network isolation? if not I will [06:02] jam: yeah I've maintained a linux kernel fork for a product before. I know the problem space [06:03] axw: not explicitly but it will be done as part of the overall network isolation work [06:03] so yeah, i'll do it [06:04] wallyworld: ok. it is calling out to cloud-images.ubuntu.com [06:04] wallyworld: seems to be only provider/maas [06:04] axw: i was leaving it till i go the framework in place to see that it failed :-) [06:05] wallyworld: I just ran the tests with "unshare", as described in #1233601 [06:05] <_mup_> Bug #1233601: juju test suite should be isolated and do 0 outbound network requests

[06:05] that was the only test that failed [06:05] wallyworld, jam: potentually useful for the basics: http://agateau.com/talks/2010/git-for-bzr-users_uds-natty/git-for-bzr-users.pdf [06:05] wallyworld: eh sorry, only package. 3 tests failed in maas [06:05] menn0: mercurial had "mq" or mercurial queues to work in the same process space, but it seems stacked-git is the only similar one for git [06:06] ok, i thought there was one for store also [06:06] wallyworld: *shrug*, did not fail in my run [06:07] axw: you know the one i mean? it shows up in failure logs but i haven't looked in detail yet [06:08] anyway I've got to go... see you'll tomorrow [06:09] you all even [06:09] wallyworld: I forget. I've seen store fail in the past, but not atm [06:09] later menn0 [06:10] axw: i can't recall the specifics right atm. it's in the logs somewhere [06:11] wallyworld: how did you end up doing the conversion? [06:11] jam: http://flexion.org/posts/2012-10-migrating-bzr-to-git.html [06:11] seemed to work fine [06:12] htp://github/wallyworld/core [06:13] i didn't rename any authors though [06:18] wallyworld: sounds about like how I'd do it [06:19] jam: good :-) must be right then :-) [06:19] it did work nicely [06:19] An interesting alias: ll = !git --no-pager log --first-parent HEAD~10..HEAD --reverse --pretty=short [06:20] matches pretty close to my default bzr output, though doesn't have *any* datestamp [06:20] a good start i guess [06:21] I personally find dates like: Mon May 12 09:28:05 2014 +1000 to be a bit too complete [06:21] vs just ISO dates [06:21] yep [06:21] wallyworld: git log --date=iso [06:21] :) [06:26] once small hurdle solved [06:26] so many more to go [06:49] git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit [06:49] is quite pretty [06:50] niiiiiiiiice [06:53] I still like --first-parent logs, but having a terminal graph is fun [06:55] git --no-pager log --first-parent --reverse --pretty=tformat:"%C(yellow)%h%Creset%<|(25) %an %ai%n %B" -10 [06:55] is the closest I could get to my "bzr log --short --forward -r-10..-1" alias [06:55] I couldn't find a way to indent all lines of the body, though *maybe* %w() [07:07] wallyworld: ll = !git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(25) %an %ai%n%w(72,8,8)%s%+b%n\" -10 [07:08] that looks really close to "bzr log --short" though the date is full instead of just YYMMDD, and it doesn't have [merge] markers [07:11] found it, instead of "%ai" for iso date, use "%ad" and --date=short [07:12] [alias] [07:12] ll = !git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(30) %an %ad%n%w(72,8,8)%s%+b%n\" -10 --date=short [07:15] wallyworld: so the reason people like squashing commits is because 'git log' and 'giggle' and 'gitk' look nowhere near as nice as "bzr qlog" on the same data. [07:16] well that's not a goof excuse :-( [07:16] you can tell what commits are "mainline" because tarmac puts "[r=" in the header, but it only takes a few commits before all of those are lost [07:16] fix the tool, don't throw away data [07:16] wallyworld: if you're tool can't show you good history, you clean up your history first [07:16] that's arse about [07:17] wallyworld: well, your preaching to the choir here, but if you try to look at the juju-core history with anything I've found it is a bit hard to figure out what is going on [07:17] outside of about 3 steps [07:18] and if you do "gitk --first-parent" it shows you just the mainline [07:18] but for some reason, it wants half of the merges to be from the right, and half from the left [07:18] jam i get a syntax error with git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(30) %an %ad%n%w(72,8,8)%s%+b%n\" -10 --date=short [07:18] wallyworld: if you are pasting it into shell, you need to remove the "\" [07:18] sigh [07:18] that is the escape for putting it in ~/.gitconfig [07:18] yes [07:19] wallyworld: it took me a while to find the right escape point for gitconfig [07:19] i didn't look too closely clearly [07:19] because without escaping " it treats the | as a shel lchar [07:19] well the < [07:19] hey i like that latest log output [07:20] i just wish the revs nums were monotonically increasing [07:20] ah, ffs, I figured out how log decides which commit comes first [07:20] alphabetical sort of the hash... [07:20] i can't fathom the hashes [07:20] why not date? [07:20] wallyworld: consider hashes arbitrary handles that you just have to copy & paste [07:20] sure [07:20]