=== kiko is now known as kiko-afk [00:15] Does the WebDAV plugin actually work? I thought it rotted a bit... [00:16] some yes [00:18] How much is "some"? [00:18] Or more contextually; does it still work well enough that we should be talking about it in the User Guide? [00:19] AIUI the only ting it doesn't do is list_dir [00:19] of course, packs need that to write :> [00:19] vila intends to fix that [00:20] I was sorta under the impression that at its best, it was still unpolished enough to really be "experimental", which makes having it in the Guide we're pointing novices at kinda questionable. [00:26] lifeless: is there a way I can get the loom without having to patch bzr? [00:27] jml: bzr isn't the problem, bzr-loom is, because I haven't pushed the last-loom, because of that bug [00:28] lifeless: is there a way I can get the loom without having to patch bzr-loom? [00:29] jml: you could use heads() to find the loom tip revision, fetch that, and usethe loom revert api call to do a local loom revert [00:29] to that specific revision [00:29] ok [00:30] but [00:30] as I don't know if I've recorded recently [00:30] and there is a bug here to fix for looms - its marked critical [00:31] if this is to give me my test [00:31] just pull the branch, use log to find the last commit on the thread you want to edit, and uncommit to that [00:35] lifeless: and pull will get me all of the latest changes, right? [00:35] it will get me the top thread? [00:36] yes [00:37] ok. that's probably the most important thing for now. [00:38] lifeless: hmm, PQM seems to have received and then not merged a change from me (it was visible in the web interface, and now it's not there), but I haven't received any email about it. Are you the right person to ask about what's happened? [00:39] lifeless: (or should I be asking IS?) [00:40] I get cc'd on cron mail from pqm [00:40] and the answer is [00:40] don't submit from a loom [00:41] Ah, d'oh. [00:41] I didn't realise this branch was a loom. [00:41] Thanks. [00:42] lifeless, maybe "partially fused with infinity" would be a good release codename? :) === kiko-afk is now known as kiko-zzz [00:43] night kiko-zzz [00:44] nite poolie -- take care of the sun for me [00:44] poolie, btw, https://staging.launchpad.net/bzr -- do you like the latest downloads bit bac just added this release? [00:50] kiko-zzz: I wonder about having everything split out; it makes the page quite long [00:50] lifeless, split out? [00:50] spiv: care to review my revision graph patch ? [00:50] everything? :) [00:51] kiko-zzz: have you seen trac's timeline, where everything gets interleaved by time rather than grouped by type [00:51] lifeless: is that the "More deprecations..." one? [00:51] lifeless, yeah, I think you're thinking what I want to do with that, which is merge those sections and have the timeline include actual stuff that happened and dates [00:52] spiv: yes [01:08] igc: ping [01:08] lifeless: removing get_revision_graph() would be awesome [01:13] hi fullermd [01:13] igc: Hey there. Got a minute or two to yack about the Guide? [01:13] fire away [01:14] I was looking at the example commands etc, and the conventions used therein. [01:15] I wondered about the reasoning behind using parenthesized asides to describe things you're doing that aren't directly typing commands, rather than representing them as #'d comments, as is a somewhat standard idiom in such things. [01:15] Also, the presence (or lack thereof) of prompts before the lines, which is inconsistent; mostly there aren't any, but in some places there are. [01:15] New bug: #207493 in bzr "bzr crashes during update" [Undecided,New] https://launchpad.net/bugs/207493 [01:16] fullermd: the lack of prompts is to make the docs less Unix-centric, more friendly to Windows readers [01:16] the inconsistency is just slackness [01:17] (blah) vs # blah is easy to change and I don't mind either way [01:18] Hm. I guess the # convention is a little *nix-y too... === mw is now known as mw|out [01:18] I find the lack of prompt a bit disconcerting to read; it's harder to distinguish "I'm supposed to type this" from "bzr will output this". [01:18] fullermd: I don't disagree [01:20] Well, shucks. You're supposed to provide an "Oh, this is obviously the Right Answer and will solve everything" here. [01:20] fullermd: Hmm - hand on while I switch my personality ... [01:21] fullermd: I'll solve everything ... [01:21] we'll make the tool so obvious that doc isn't required at all :-) [01:21] or ... [01:22] I can just put prompts in everywhere (and Windows users can feel better by occasionally seeing a Windows one instead of $) [01:22] how's that? [01:23] Well, as a tcsh user, I felt good seeing one '%' prompt in there ;) [01:24] see - it's easier to not have prompts than argue about which one to use :-) [01:24] Maybe a '>'; it would be more familiarish to Windows users, and *nix people could figure it out. [01:25] except that > is continuation in *nix so that does confuse unfortunately [01:25] Anyway. Main reason I started thinking about it was on 3.8.9 (correcting a tag), it's not obvious that you're making more revisions before you [re]tag the rev. [01:26] Maybe we should rewrite that example to use 'tag -r' in both cases, to make it clear that you're changing the rev the tag points at? [01:28] or I could add another comment like ... (make more commits to include more fixes) [01:29] fullermd: would that do? ^^^ [01:29] adding -r adds more complexity than needed I feel [01:29] Hm. Would be better, I'd say. [01:30] It still feels a little like it might be unclear unless you already know what it does. But neither of us is in a very good position to evaluate that, I guess. [01:31] fullermd: were there other places where lack of prompts are an issue? [01:31] in 99% of cases, having bzr at the start of line is enough clue I think [01:32] Well, a lot of the earlier stuff which has a lot of output (diff/stat frex) has the prompts. [01:32] I don't think there was anywhere it really threw me; just that I was already thrown by the tag example seeming to move the tag to where it already was, that I noticed the lack. [01:33] Should find some Windows people and pin them down in a corner with "Is this confusing? What would be better" maybe. [01:34] yes I should. I just checked some books here on my bookshelf and struggled to find one with a prompt :-) [01:34] Most of my books don't have very good interpreters anyway ;) === cprov is now known as cprov-zZz [01:50] New bug: #207507 in bzr ""bzr commit" empty message error comes too late" [Undecided,New] https://launchpad.net/bugs/207507 [01:55] lifeless: I'm reviewing your branch btw, but I'll finish it after lunch. [01:58] ok [02:00] spiv: I'm 2 ahead now :> [02:00] New bug: #207512 in bzr "bzr merge --preview fails when uncommitted changes" [Undecided,New] https://launchpad.net/bugs/207512 [02:33] poolie: what's the state of the PPA? [02:34] abentley: still on 1.2 i believe [02:36] I'm concerned about the delay getting 1.3 up there. I wish I knew enough about debian packaging to help out. [02:37] i'll ask if someone else will help [02:38] Good idea. === i386__ is now known as i386 [04:54] k, done [04:57] lifeless: cool! with bzr? It's finished? ;-) [04:59] * TFKyle would hope not, a project being finished is like a death sentence [05:02] lol I was just joking. It's just that was a really out-of-context "k, done" :) [05:04] true [05:36] can someone try 'bzr branch http://bazaar.launchpad.net/~rmurri/vc-bzr/trunk/ b' with head? [05:45] bob2: Yeah, I seem to have broken it. [05:46] bob2: I'm looking at the problem right now. [05:47] bob2: a temporary workaround is to delete the get_shared_method method from bzrlib/transport/http/__init__.py (e.g. by renaming it to XXXget_shared_medium). [05:47] hello guys [06:40] New bug: #207557 in bzr "Print versions of manuals requested" [Wishlist,Triaged] https://launchpad.net/bugs/207557 [06:45] New bug: #207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558 [06:59] Oh, good, I'm on r3308. [07:03] Ooh, bzr+http auto-detecting? [07:03] Huh. [07:04] It takes bzr+http like 500 requests to find out there's nothing new to pull, vs. about 6 for http. [07:09] Ok, 9 for http vs. 25 for bzr+http. [08:13] it's amazing how infected the choice of version control system has become. [08:13] it's like mac vs pc vs amiga vs atari all over again. [08:14] night all [08:18] jrydberg__: referring to the OS or hardware? [08:19] hardware-wise I wonder what bzr would be equiv to, isn't too minimal so not really a RISC, x86 is probably subversion or cvs though [08:21] hmm, ruling out all of RISC might not be fair [09:03] Morning [10:54] Hi, I'm committing a large file (500MB or so) and bzr is taking up plenty of memory but is using minimal CPU. It's been doing this for 8 hours or so. Should I kill it? === _mathrick is now known as mathrick [10:59] fbond: Why did you do that? [10:59] fbond: You do have 10 or 15 GB of RAM, right? Otherwise... :P [11:24] Gods, pulling the last three weeks of bzr.dev using http is slow. [11:25] I can't believe that the developers use this same method, or this would be fixed by now. [11:28] chadmiller: I suspect the majority of the developers don't leave three weeks between their bzr.dev updates. :p [11:30] Agreed. This is a common case for casual developers, though. /Somebody/ should. [11:36] hi, I have a bzr local branch. I want to make it not a branch so I can start the commit history again. is that done by rm -r .bzr ? [11:37] chadmiller: 1m 39s here, and I'm on the other side of the planet to the HTTP server. Only 51s if I use bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk instead of http://bazaar-vcs.org/bzr/bzr.dev/. That's fetching 309 revisions. [11:38] mr-russ: yes, that will remove all of the bzr metadata from the branch. Be sure that is what you want to do first thoug [11:38] for instance that will mean that you can no longer merge any other branches of that code that exist [11:39] james_w: that's fine. [11:39] I have a CVS checkout from another project. I want a local bzr branch on top for my own development. [11:39] I messed up the import by building for and having binaries and stuff I didn't want. [11:39] s/for/first/ [11:40] so thanks for the information. [11:40] chadmiller: are you pulling from launchpad or bazaar-vcs.org? [11:41] mr-russ: no problem [11:41] spiv: That was, according to my .bzr.log, 21 minutes . [11:41] chadmiller: that's not normal, then. [11:41] chadmiller: is your local branch in pack-0.92 format? [11:41] james_w: Is that question documented somewhere? [11:42] james_w: [u'pull', u'http://bazaar-vcs.org/bzr/bzr.dev/'] [11:44] yeah, that's probably re-annotating isn't it? [11:44] spiv: My local branch is in whatever format you get when you follow the directions on the web site. [11:45] chadmiller: When did you follow those instructions? :) [11:45] chadmiller: "bzr info" should tell you [11:45] It's dirstate [11:45] chadmiller: ah, yep, that's the problem [11:45] Odd_Bloke: ~3 months ago, I think. [11:45] chadmiller: you need to bzr upgrade your local branch. [11:45] should we print a warning to users when this happens? [11:46] perhaps there should be a message on autopack as well? [11:46] chadmiller: it's taking so long because bzr is converting revisions between formats, and converting from packs to knits is particularly slow as it has to calculate annotations for every line changed in every revision. [11:46] chadmiller: bzr upgrade --pack-0.92 in your local branch [11:46] james_w: yeah, I think a message when using a particularly expensive InterRepo is probably a good idea. [11:47] chadmiller: so you're right, the developers don't put up with this :) [11:48] spiv: I'll mail the list [11:48] Yeah, I don't really need help, personally. I'm acting as the average user gadfly, and pointing out problems, as most people who are interested in trying Bazaar aren't going to come to the IRC channel. [11:50] chadmiller: makes sense. Thanks for the report. [11:50] in bzr status, what does the @ symbol at the end of the filename mean? [11:50] symlink [11:50] ah [11:51] Hmm, neither "bzr help status" nor "bzr help status-flags" mentions that. [11:52] There's * for executable as well I think [11:52] that is why I'm asking :) [11:52] spiv: shall I file a bug, or are you already writing the patch? :-) [11:52] Well, it doesn't mention / for dirs either. I figured it was just assumed. [11:53] / is normal for dirs, is it modelled from bash, does it use @ and *? [11:53] james_w: it's late here, please file a bug for me :) [11:53] It's been SOP in ls since, like... I don't know. The 70's, maybe? [11:54] spiv: sure [11:54] well, ubuntu uses colors by default, so I understand those, not @ and *. [11:55] I still need to add -F here [11:56] that implies you know bash fugu and how it applies to bzr to understand it :) [11:57] mr-russ: technically, it's nothing to do with bash, just /bin/ls [11:57] * fullermd doesn't use bash at all :p [11:57] I can't say I would have ever made the link. [11:57] I can file a bug in launchpad if nobody else is able. [11:59] mr-russ: I'm on it, thanks [12:00] * mr-russ can't believe an annoying question resulted in a bug. [12:01] spiv: hmm, thought bash could optionally builtin ls, doesn't look like it from man bash here though [12:02] (think busybox does though) [12:07] james_w: thanks for being my bug filing machine for the evening :) [12:07] * spiv -> bed [12:07] night spiv [12:10] New bug: #207687 in bzr "bzr help status-flags should list * @ and / as well" [Undecided,New] https://launchpad.net/bugs/207687 === thekorn_ is now known as thekorn === bigdo1 is now known as bigdog === mw|out is now known as mw [13:10] how do I list all the changes (like missing does) since some tag or between 2 tags instead of 2 branches [13:11] bzr diff -r tag:tag1..tag:tag2 ? [13:11] or bzr st if you only want a list of changed files [13:11] "bzr help revisionspec" lists all the ways to specify revisions [13:12] luks: i htink missing only gives me "log like" summary [13:12] as in - commit messages [13:12] bzr log then [13:13] oh [13:13] cool [13:13] thanks [13:24] l'question [13:25] I have a repository, and I worked on it in another computer but without the .bzr, so I created a new repository there using files from some revision of the first repo. === mrevell is now known as mrevell-lunch [13:26] how can I merge these two (the second repo is really a continuation of the first, and only has 2 revisions in it) [13:28] bzr merge? bzr pull? [13:28] well I could have guessed it involves one of those....but i want to be sure i'm not messing up [13:29] if you created a new branch without using bzr (i.e. re-bzr-add'd the files), then they' [13:29] 're not related and merge/pull won't work [13:31] what's worse, i've opened the .tar.gz of the new repo (and cd'd into it) and bzr info says that there is no repo in the current directory. [13:31] even though there IS a .bzr directory [13:31] nvm, i'll try upgrading bzr, i think it's an old version. [13:32] It's possible the .bzr directory doesn't include a repo. [13:32] did you reimport the files into a freshly created branch? [13:32] Um, tar is not really the correct way to transfer bzr data around.. [13:32] and does bzr say only that, or does it think the dir is a checkout? [13:32] bzr: ERROR: No repository present: [13:32] ... [13:33] (... = path) [13:33] Peng so how should I do that? [13:33] unenough: you are confusing the terms branch and repository [13:34] uh, right! that's the problem [13:34] I forgot that in the other computer it's under a shared repository [13:34] it's hard to tell what's actually repository and what is a branch from your question [13:35] ok, thanks. it's not such a big deal in this case (i knew it wouldn't really matter that's why i messed around so much) [13:35] unenough: Use pushing and pulling. [13:35] unenough: You have ssh on the machines, right? [13:35] Peng: It's the same computer, it has linux-windows schizophernia [13:35] Oh. [13:36] i'm creating now a FAT32 (oh dear) partition so I can share data safely [13:39] I was shocked recently to discover that the best filesystem to use on a USB key for my linux and OSX machines was NTFS. [13:39] wtf?! [13:39] the ntfs fuse stuff is pretty good [13:39] That reminds me, I've been meaning to ask someone what file system to use on a (Linux-only) USB stick. [13:40] (Hint hint? :P ) [13:40] ext2 [13:41] Linux doesn't grok OSX ufs, and OSX doesn't grok EXT2. I don't trust FAT. Neither claims to support NTFS, but it worked. [13:43] it is just plain stupid not to support ext file systems, since they are freely available to impliment by anyone =/ [13:44] but hey, that's apple for you [13:44] they don't support vorbis on the ipod either x.x [13:45] New bug: #207730 in bzr "SFTP access fails on MacPorts/Leopard installation (SSHSubprocess object has no attribute get_name)" [Undecided,New] https://launchpad.net/bugs/207730 [13:48] yeah, i don't think i'll ever buy a mac. [13:56] New bug: #207734 in bzr "push on bzr+http, pycurl fails with: necessary data rewind wasn't possible" [Undecided,New] https://launchpad.net/bugs/207734 === kiko-zzz is now known as kiko [14:03] Yeah, but aren't there file systems better designed for how USB sticks work? [14:03] Wear-levelling, the lack of seek latency, whatever. [14:03] Eh. USB flash sticks are like CF; they implement wear-levelling internally. [14:07] I have been using bzr on windows and very much impressed with the bzr serve and bzr pull options. any thing latest happening with bzr serve ? [14:08] like plain text password login something like bzr pull bzr:://remotehost:4155:/myhome/mybranch [14:10] I am also trying to find a linux32 runnable version without all the python etc, etc install process like an .exe on windows. Is it out there somewhere? [14:11] Pengwn: sorry, I don't quite get what you are after. [14:11] Actually Two things. [14:11] Pengwn: If you have Paramiko and whatnot installed, all you have to do is download the tarball. [14:12] is the first question whether there are plans to add authentication to the bzr:// server? [14:12] yep. [14:12] it's been discussed, but there's no work on it yet. [14:12] I had a discussion before with some one but I am not looking into ssh and other setup methods. [14:12] some people aren't too keen, but as it is requested a lot it may well happen eventually [14:12] some the simple. [14:13] something simple. [14:13] and as Peng says you just need the tarball if you already have python installed. [14:13] fdisk says my USB stick is formatted as FAT16. Nice. [14:13] just so that some second person cannot just pull from by bzr serve. [14:13] I have python 2.4 on the server installed and I cannot mess that up. [14:13] I'm starting to think that merge sort may not be harder than topo sort: [14:13] bzr mlog 0.89s user 0.04s system 100% cpu 0.924 total [14:14] Pengwn: you won't mess it up, you can run bzr from the directory the tarball unpacks to [14:14] that's the time to display the first merge sorted revision [14:14] oh really. cool. [14:15] In what tree? === mrevell-lunch is now known as mrevell [14:16] bzr.dev [14:17] it can probably be speeded up, but it doesn't do revision numbers yet [14:17] and the indentation is slightly different, as I can't work out the exact rule the original uses. [14:17] it doesn't indent merged revisions on some occasions [14:18] is this the tar ball : bzr-1.2.tar.gz from bazaar-vcs.org ? [14:18] there's 1.3 now, you should use that. [14:18] http://bazaar-vcs.org/releases/src/bzr-1.3.tar.gz [14:19] but by windows is on 1.2 is that ok ? [14:21] $ pwd [14:21] /home/duper/bzr-1.2 [14:21] bash-3.00$ find . -name python [14:21] bash-3.00$ [14:21] no python in that tar ball ? [14:21] python installed on server is 2.3.4 [14:21] no, it does not include python [14:22] you said you had "python 2.4" installed, above [14:22] yep sorry my mistake. [14:22] Pengwn: do you have /usr/bin/python2.4? [14:22] I actually need a tar ball with everthing in it then :) [14:22] nope. [14:23] 2.3 is ooooold [14:23] I don't think one of those tarballs exists for linux [14:24] any links on how to install bzr as user then ? [14:24] that's not your problem [14:24] you need to install /python/ [14:24] that's the problem I cannot mess up the server . [14:25] I have only user access on the linux box. [14:25] hmm git got setup well. so something like that for bzr ? [14:26] ask whoever installed or compiled git to install python2.4 [14:27] me compiled git and install to ~/bin :-) [14:28] why don't you do that with python? [14:29] yep have to I guess. just thought I might get the procedure layed out here for :) [14:29] me. [14:33] FWIW, compling Python in your homedir is pretty easy. [14:33] compiling* [14:34] Really? [14:34] I just checking it out. [14:34] Except, it often wound up without support for things like bzip2 and readline, thanks to the system not having the proper headers installed. [14:34] But it still mostly worked. [14:36] http://docs.python.org/inst/search-path.html [14:36] looks like ti. [14:38] bzr "-d path_to_branch", "path_to_branch" and "you must cd to path_to_branch" inconsistency is bugging me [14:39] bzr missing and bzr nick want you to be in the directory, a lot of commands want -d before directory you want the operation to be performed on (tags, push, tag) [14:40] and some commands can handle the path given as a plain parameter [14:40] Peng did you install it or just set you path to the the untarred location ? [14:40] Pengwn: Installed it. [14:40] oh ok. [14:40] ignas: it used to be that nothing had -d, and so all but a few commands required you to be in the directory. [14:40] like co and ci for example [14:40] have you tried with settting just the path ? [14:40] Pengwn: If you've compiled Python in your homedir and use that version of Python to run setup.py, it'll go in the right place automagically. [14:41] Pengwn: Yes. [14:41] ignas: if there are commands that don't have it and you want it then please file bugs [14:42] james_w: filing a good bug report is a lot more difficult than ranting :/ i don't have a bzr checkout of both bzr tools and bzr to check if the bug is still there in the newest version, and don't have the time now to checkout and build them [14:43] oh ok. where are the .c file for python ? [14:43] and makefile dist? [14:43] ok I will check it out. [14:44] ignas: if you list the commands I can check for you [14:45] missing and nick [14:45] but if you just want to rant, go ahead :-p [14:45] Peng: will the module search path get updated or is there an option during make of the python binary? [14:46] there was a bug filed on nick the other day asking for setting remotely, so that will probably cover it [14:46] Pengwn: What? [14:46] missing still doesn't have it [14:46] Pengwn: Just install Python and then use "python setup.py install" (assuming "python" is your installation). [14:46] for the import command usually there's predefined paths like /usr/local/bin or /usr/local/lib/python2.3.4. etc ? [14:46] ignas: so add a comment to https://bugs.launchpad.net/bzr/+bug/180297 for nick [14:46] Launchpad bug 180297 in bzr "no way to read the nick of a remote branch" [Low,Confirmed] [14:47] import keyword i.e. [14:47] Pengwn: Yes, they're relative to the installation. If you install it in ~/local, they'll be ~/local/lib/python2.5 etc. [14:47] james_w: cool, thanks [14:47] oh cool. [14:48] ignas: I can't find one for missing, so go ahead and file one [15:00] are there plans to make versioned properties? We need some way how to edit commit messages [15:01] james_w: ok, reported [15:01] thanks [15:01] hsn_: I think it's been discussed, but I don't know what was decided === LeoNerd_ is now known as LeoNerd [15:06] New bug: #207762 in bzr "missing does not accept "-d" parameter" [Undecided,New] https://launchpad.net/bugs/207762 [15:40] hmm, bzr log -r tag:some_tag gives me a list of changes including the change that added the tag [15:40] how do i list only changes that happened after it [15:40] thus would be missing if i would checkout the tag [15:41] ignas: try -r tag:foo.. [15:41] it includes the revision foo was added [15:42] try -r after:tag:foo.. [15:42] bzr: ERROR: No namespace registered for string: u'after:tag:0.0.1' [15:43] bah [15:43] I thought that existed [15:43] i thought so too, it works in my tests [15:43] when executed from python [15:44] ok, it does not [15:44] just that i was ignoring errors [15:44] right [15:44] ignas: so [15:44] ignas: what's so bad about -r tag:foo.. ? [15:45] it works but it includes the tag:foo revision [15:46] the point is listing all the new things since the last release [15:46] it always shows at least one change with tag:foo [15:46] and that change is included in the release that was made from that tag [15:50] I don't think after: has ever existed; it's ill-definable... [15:50] I think there is a case for excluding the lower bound though [15:50] then if you wanted it you could use before: [15:51] i kind of understand the technical issues with after: [15:52] otoh - i still have to think of how to list all the changes made to a branch the way missing does [15:52] Mmm. This is where git's XOR-ish syntax is handier than bzr's range syntax.... [15:52] without checking out the tag [15:52] and doing bzr missing [15:55] Hmm. [15:56] I don't think there's a technical reason why missing can't support -r specifiers. But no one's done it yet. [15:56] Syntax gets sticky. [15:57] Seems to be a recurring burr... [15:57] abentley: with bzr log i can do that without a checkout even i think [15:59] I'm pretty sure log just requires a branch, not a checkout. [15:59] And similarly with missing. [15:59] you have to have a checkout to do missing [15:59] you do missing on a branch [15:59] but to use missing you have to cd into a checkout you are comparing the branch with [16:00] so to do what i need i had to - bzr co -r tag:foo some_branch some_dir && cd some_dir && bzr missing some_branch [16:01] becauze bzr log -r tag:foo.. gives me the foo revision while missing tells me that nothing has changed, or just lists all the new things that have been commited after the release [16:02] Well, the simplest thing is a way to differentiate inclusive and exclusive bounds. [16:02] (conceptually simplest, that is) [16:02] yep [16:03] i kind of expected some manual about ".." things [16:03] that would include other kinds of dots ;) [16:03] like :. and .: ;) [16:06] ignas: No, you don't. You need a local branch. It doesn't have to be a checkout. [16:07] abentley: something you can "chdir" to from what I understand [16:08] and even so: if i want to check versus a tag - i have to checkout that tag [16:08] ignas: Right. Local, but not necessarily a checkout. [16:08] You don't have to checkout that tag. You can make a branch of that tag. [16:10] abentley: is there a big difference ? like in time/space as i am deleting it immediatelly after i do the missing thing [16:10] Yes. Creating a treeless branch in a shared repository is virtually instant. [16:11] Creating a checkout necessarily requires building a working tree. [16:11] abentley: i wouldn [16:11] i wouldn [16:11] i wouldn't want to create stuff in the repository [16:11] when running the release scripts [16:12] abentley: hi [16:12] and especially when I am not running them [16:12] ignas: Well, that's your own lookout. [16:12] jelmer: Hi. [16:12] and just querying for "something has changed?" [16:12] abentley: I'm trying to get merge_sort() to work with multiple branch tips - is there some easy workaround for that? [16:13]