IRCloggy #git 2006-10-30

Logs Search ←Prev date Next date→ Channels Documentation

Provider of IRC logs since 2005.
WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

2006-10-30

→ DrNick joined01:12
→ dst_ joined01:44
→ benlau joined02:30
← afrayedknot left04:03
→ lyakh joined06:09
→ GyrosGeier joined06:15
→ sgrimm joined06:37
→ sgrimm_ joined06:48
→ pdmef joined06:57
→ matled joined07:06
→ nud joined07:20
→ ShadeHawk joined07:50
→ ferdy joined09:10
→ Insount_away joined10:13
→ chris2 joined10:19
dwmw2_gone → dwmw2_HKG10:37
dwmw2_HKG → dwmw2_gone10:59
→ kanru joined11:11
→ robin joined11:58
tokkee A couple of people proposed to create a generic libgit with a well defined API which could be used by external programs.12:34
Is there any work done on that topic?12:34
ShadeHawk first the API has to stabilize I think12:36
besides, for example there is no good abstraction of the concept of repository, and there are still too many remains from the times of standalone commands12:37
tokkee Sure... but work can be done in parallel ;-)12:37
→ AdamRichter joined12:37
tokkee ShadeHawk: Are there any plans to solve those issues? Is any work done already?12:42
ShadeHawk there are commands converted from shell or C version to builtin12:44
but I don't think that libification of git is main concern12:44
there are more important issues (Mozilla CVS import, partial pack mmapping, making git even faster)12:46
→ robfitz joined12:47
→ spuk- joined12:47
tokkee ShadeHawk: Alright - thx for the information :-)12:47
robin there have been argued that the internals are stable enough that a libgit is not really necessary12:47
(bad english..)12:48
tokkee robin: Using libgit in an external program would be much easier, faster and nicer than using exec to call the git binary.12:48
ShadeHawk robin: but for example during Git.xs development it have been realized that git lacks proper repository abstraction12:49
robin or just access the storage directly which may be even faster12:49
tokkee ... which should be done by means of a defined API imho.12:49
Else code would be rewritten over and over again.12:50
ShadeHawk tokkee: check out egit which is access to git from Java, to be used in Eclipse plugin12:50
Linux kernel also desn't have defined API/ABI IIRC ;-)12:50
robin yepp12:50
tokkee ShadeHawk: Thx... I12:50
ll have a look at it.12:50
*grr*12:50
tokkee has to leave now...12:51
ShadeHawk http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#Eclipse12:51
robin well, the kernel has a user-space ABI12:51
in the Documentation directory there is documentation on the storage format GIT uses12:52
you should probably read that rather than an implementation12:52
pasky ShadeHawk: turns out that I've fixed that just before I've left for the weekend but forgot to update the working copy on repo.or.cz13:21
:)13:21
(the alternates)13:21
→ timlarson_ joined13:42
→ boto joined13:46
→ matled joined13:48
ShadeHawk Ah. Thanks for an info pasky. I understand that is now corrected?13:59
→ coywolf joined14:00
← boto left14:04
pasky yes14:07
→ robin joined14:19
→ krh joined14:26
dwmw2_gone → dwmw2_TPE14:36
Insount_away → Insount15:06
→ Oejet joined15:40
→ Tv joined16:04
→ anholt joined16:20
→ sgrimm joined16:26
Qball → qb16:26
qb → Qball16:27
→ Yaco2 joined16:34
→ segher joined16:47
→ tchan joined16:55
sgrimm If changes have been pushed (using cg-push) into a repository, what's the best way to merge those changes into the target's working copy, which might have changes of its own?17:31
(Yes, undoubtedly a really dumb question!)17:31
→ kanru joined17:34
ShadeHawk In the target: git pull . <branch>, or git pull <source repo>17:43
sgrimm Ah, ok, so I need to explicitly specify the branch. Thanks!17:45
→ trekol joined17:50
← trekol left17:50
kampasky and I hope you don't push to the same branch you have checked out18:10
maro if you've committed something (well, actually reverted...) and decide to undo, is it possible?18:11
I'm pushing to a central server but haven't pushed the broken change yet18:11
→ beu joined18:13
→ beu joined18:14
kampasky maro: cg admin-uncommit18:15
if you didn't push it out yet18:15
maro isn't it possible with native tools? :/18:15
→ robtaylor joined18:17
moh maro: you've committed a changeset and you want to undo it?18:18
git reset HEAD^18:18
ShadeHawk git commit --amend18:18
(to amend)18:18
maro moh: thanks!18:18
moh hmm...never used --amend18:19
ShadeHawk git reset HEAD^ or git reset --hard HEAD^ if you want to rewert working are too18:19
→ anholt joined18:21
maro thanks guys :)18:21
→ lyakh joined18:49
→ nud_ joined18:55
→ Eludias joined19:02
→ ruskie joined19:07
→ chris2 joined19:13
Insount I'm working in a branch forked from 2.6.18, and need to merge in someone else's work. His git branch is based on Linus's tree, so I want to merge only the commits in "hisbranch ^linus"; and I want to keep tracking ("pulling") that truncated branch later on. What do I do, other than manual cherrypicking?19:31
→ spearce joined19:32
kampasky cherrypicking in a loop :)19:34
Insount frawns.19:34
robin maybe merge his branch, revert all changed between his branch and yours (before the merge) and then continue pulling19:35
Insount robin: Linus keeps introducing new commits, that damn bastard...19:36
robin but those won't get into your buddys branch do they?19:36
Insount robin: He's merging occasionally.19:37
robin and you don't want those changes?19:37
tough19:37
Insount robin: No, it's a topic branch and I want to see just the topic...19:37
robin then cherry picking is what you want19:38
Insount Something like this, modulo error checking?19:40
for C in git-rev-list --topo-order hisbranch ^HEAD ^linus; do git-cherry-pick $C; done19:40
robin --no-merges?19:43
but ofcourse you may want *some* merges..19:45
Insount Does --no-merges mean "Do not print commits with more than one parent." like the manpages says, or does it actually prune traversal and doesn't print merge's ancestors either?19:47
spearce it does what the manpage says. :)19:47
kampasky (which isn't all that obvious in git ;)19:47
Insount Then it won't help here... But ^linus is good enough for me.19:47
Hurray to pipes!19:48
robin maybe rebaseing back and forth could help...19:48
kampasky Insount: I think you do want --no-merges19:48
Insount Oh, right. Thanks.19:49
kampasky Insount: if you cherrypicking the merges (I think it won't even let you), you'll get content of all the commits you skipped with ^linus anyway19:49
Insount Ack19:49
→ spearce joined20:21
spearce grrr. dang --unpacked= option.20:26
sgrimm How do I make git-update-index --refresh actually update the index for changed files? As far as I can tell it just gives me a list of files that need to be updated, and I then have to pass those names back to another invocation of git-update-index. Don't see anything in the manpage, but it seems weird to have to run the same command twice in a row.20:49
spearce typically you only want to update the files you want to commit, and usually you use an option to git commit to specify those files; git commit will then update the index for you.20:50
sgrimm Cool, thanks, will go look at that.20:51
spearce e.g. "git commit -a" will update-index every modified file then perform the commit.20:51
sgrimm Great, that's just what I want!20:51
spearce there's a lot of those types of "just what I want!" in Git. :-)20:54
Gitzilla The trick it to find them!20:56
spearce Yea, that's a good point. :)20:57
sgrimm In this case I was going by the warning message from git commit (without the -a) telling me I needed to run git-update-index to mark files for commit.20:57
So I started poring over the git-update-index manpage trying to figure out how to make it do what I wanted.20:58
Oejet "...but I stiiiill haven't found, what I'm looking for...", laliailailai. :-)20:58
→ Insount` joined20:58
spearce Oddly enough I think it does what you want if you pass it no options at all. :)20:58
no, actually you need to do something like a diff pipeline: git-diff-files --name-only -z | git update-index -z --stdin20:59
neuralis what's the easiest way to extract the first line of a commit message for a given commit id?21:02
spearce git log -n 1 --pretty=oneline commitid21:03
then cut off the first 41 characters of that line. :)21:03
neuralis that's what i was doing, but i was surprised that git-show --pretty=oneline isn't actually producing a oneliner.21:03
spearce it is here: git show --pretty=oneline HEAD21:04
neuralis krstic@aeryn:~/source/olpc/tmp> git-show --pretty=oneline HEAD|wc -l21:04
1421:04
spearce what eversion of Git?21:05
neuralis 1.4.3.221:05
spearce I'm using 'next' which is currently 556 commits ahead of that.. I wonder if there's a fix in there somewhere for that bug.21:06
neuralis eh, no worries. git-log will do what i want for now. thanks, though.21:07
pasky it's really interesting to see how few people actually are sure about what git-commit exactly does and how it interacts with the index with various parameters :)21:16
spearce definately. we claim to try to hide the index from the user but then git status and git commit slap that "git-update-index" nonsense in their face. very unfortunate.21:17
pasky oh, we really claim that?21:19
where?21:19
I didn't know core git aims for that21:19
spearce well why would we create 'git add' as a wrapper around 'git update-index --add' if we weren't trying to hide the index from new users?21:19
you may be right that we don't try to hide it but most users don't need to worry about it thanks to git add/rm/commit -a.21:20
I recently moved about 15 developers off pg and onto core git. they had issues with the concept of the index... *sigh*21:20
pasky but then it comes back to them and sooner or later they need to know about it anyway21:20
I'd say it's backfiring the same way we say the revno/revid duality in bzr is backfiring21:21
you should've moved them to cogito :)21:21
spearce I was just thinking that after I sent that message. :)21:21
I haven't used cogito in almost a year, i've moved completely to core git. since i'm their primary support (apparently they can't read a f'ing webpage) i wanted them on an interface i know well.21:22
loops We should just fix Git so that people don't need to move to Cogito :oP21:22
pasky ideally, yes21:22
but fixing ui is hard21:22
it'll take time21:23
loops we should do the hard work.. and pushing people to Cogito just reduces the incentive21:23
spearce #1 issue i had with training these 15 folks on core git's ui is "pull = fetch + merge, fetch is just a fetch".21:23
loops spearce, yeah.. people should learn fetch first...21:24
would be nice to have a usable "merge" feature too.. one that isn't meant to be just used as plumbing21:24
spearce these guys had a hard time grasping the idea that fetch just copies objects to your repository but doesn't affect your working directory.21:24
loops yeah...21:25
spearce yea - i had an email thread a few weeks ago on git@vger talking about how fetch/merge/pull/push are all incorrectly named. everyone agreed but saw no way to change it. :)21:25
pasky that's the hard-to-fix ui problems I'm talking about21:25
current state sucks and changing it means breaking compatibility, which sucks21:25
loops pasky, yes..21:26
spearce we almost just need to redo the ui and create git 2.0.0.21:26
loops spearce, yes again21:26
spearce a good chunk of the ui can survive; e.g. git log isn't *that* bad as it stands now. :)21:26
loops no.. it's great ... but would be nice if it could get Cogito's... follow rename logic21:27
at least as an option21:27
Maybe, git 2.0 should just be a merge of cogito ;o) ?21:27
spearce the rename following i thought was planned to go into git log, as soon as someone coded it? :-)21:29
loops Ahh.. wondered..21:29
pasky actually, I _REALLY_ look forward to the point when I declare Cogito feature-complete and my further work will be directed on reducing all the Cogito's logic and moving it to Git, so that Cogito stays just a thin wrapper :)21:29
loops It would be really nice to push a lot of Cogito features down into Git.. and leave Cogito just as a thin UI fix layer21:29
pasky and it's not even that far away21:29
loops lol.. agreed21:30
pasky :)21:30
mugwump I use git core, but I support my colleagues using cogito21:30
actually I'm using cogito more and more, it's usually more handy21:30
pasky literally one big thing is missing in cogito: remotes support (and cg-clone -a, which comes with it)21:30
then there are few details and I can tag 1.021:31
mugwump I still reckon21:31
whoops21:31
pasky actually, I'd say two things, merge strategies being the other one21:31
it's officially planned post-1.0, but since when I planned it my lookout for post-1.0 development changed and I don't really want to do too much of it21:32
mugwump I still reckon that it could do with a rebase-on-push option... it's what, eg, svn users are used to, and keeps the history simpler when multiple people are working on the same branch21:32
otherwise you just end up with N extra merge nodes per developer working on the branch per push21:32
pasky and that's wrong why?21:33
mugwump it's confusing21:33
pasky it's how you _did_ things21:33
what if something goes wrong in the rebase and it misapplies the commit21:33
loops yeah.. i'm sure Linus would argue rebasing loses real history information.. but it doesn't sound like a bad option for those that want it21:34
pasky those that want it are not aware of the implications21:34
(generally, at least)21:34
spearce agrees with pasky21:34
pasky mugwump: what's confusing on merge commits, anyway?21:34
mugwump: the log commands don't even show it (by default) anymore21:34
spearce rebase as a merge strategy so you can do "git pull -s rebase . other" makes some sense, but that's about it.21:35
mugwump well, gitk shows them, and it's confusing explaining them to people21:35
when most of the time it's useless information21:35
loops gitk of the git repo is a bloody mess21:35
mugwump rebase as a merge strategy could work, especially if it works with `cg-update' easily21:36
ShadeHawk by the way, was rebase (formerly subordinate) merge strategy accepted?21:36
spearce i have a worse repo than git. :-)21:36
mugwump I don't know where the 'losing information' comment comes from, if the rebase fails you can abort21:36
spearce ShadeHawk: no, its not in 'next'. 21:37
i think it was just dropped on the floor; a resubmit might get it in.21:37
loops mugwump, the commits were created based on earlier commits.. rebasing them is in a sense lying about the development history...21:37
pasky mugwump: a patch can "misapply cleanly"21:37
ShadeHawk without index is hard to think about resolving more convoluted merge conflicts (like add/add, rename/rename, ...)21:38
mugwump you can also "mis-merge cleanly"21:38
loops true that..21:39
ShadeHawk perhaps they are used to linearized history, because they used SCM with poor or non-existent merge resolving?21:39
pasky yes but you have a record of that21:39
you can trust that the _commit_ corresponds to what you've actually committed21:39
and you can say "aha, it was right but the merge was wrong" to the horde of angry developers when the subtle mismerge caused PDP-11 builds to fail mysteriously and bisecting took two months21:40
ShadeHawk and if you blow commit after rebase (and you usually do)... the commit is correct, the error was in mis-clean rebase, and you have noticed this a week later... and you are screwed21:40
pasky and you can actually do a much more sensible recovery from the error21:40
spearce all of which is why i avoid rebase and cherry-pick. :)21:41
i actually hate the fact that i email my patches to junio who then applies them as a totally different commit so he's essentially cherry-picking my repository. :-(21:41
loops spearce, maybe those cogito bundles would be nice after all21:42
so the full commit info is sent through email.. instead of just patches21:42
ShadeHawk spearce: send him "please pull" requests with shortlog and diffstat ;-))))21:42
loops heh yeah, or that..21:42
spearce even if we send full commit info the problem is Junio also signs the stuff he is applying, which changes the ID. :-)21:42
loops right21:43
but that doesn't really have to be done21:43
spearce pull requests are counter to the mailing list development model; having the patch series there lets others read the series and comment on it.21:43
pasky modified cogito bundles that actually show the patch, not include encoded packs21:43
ShadeHawk: (git-request-pull :)21:44
ShadeHawk or read the series and _not_ comment on it ;-)21:44
loops Although the bzr bundles sound list-unfriendly because they make a single aggregate diff out of all the commits.. somehow you want to show individual diffs..21:45
spearce continue to send each commit as its own email (threaded) but follow up with a final message with the machine readable bundle in it.21:46
loops or bundle in initial message with diffstat etc21:46
spearce stick the id of the bundle in every message as part of that message's diffstat, and display the id of the bundle when processing it == relatively easy to verify the bundle is the series.21:46
pasky loops: it's total implementation detail21:49
loops pasky, yeah21:49
pasky that the last patch is a huge diff is totally arbitrary and has no technical reason21:49
and if the code is sane I guess it's just one line change + commenting out few other lines to make it send sane diffs instead21:50
ShadeHawk pasky: not really. You can't have sane (i.e. GNU patch applicable) _multiple_ separate diffs in the same message21:51
fullermd If you were using bzr bundles in such a way, you'd make multiple bundles, one for each 'step'.21:51
pasky spearce: still you can't avoid possible and even likely cherrypicking since one of the patches you're sending in the series is bound to be broken or someone'll be nitpicking and you'll need to fix+resend21:51
loops fullermd, yes.. but we want to be able to send a patch series _easily_ with a single bundle21:52
pasky ShadeHawk: I understood that they were in separate messages but my memory is hazy; anyway, this isn't meant for GNU patch ;-))21:52
fullermd The problem with just showing each diff is that the granularity of what you want to present as "steps", and what your individual commits were, are often not the same.21:52
spearce pasky: my patches either get accepted as-is or get rewritten from scratch to address the problem. :) 21:52
ShadeHawk IIRC bzr bundles solves it that it has for a->b->c->d bundle a..d diff as body of message, and a..b, b..c diffs MIME encoded21:52
pasky spearce: ... :)21:52
ShadeHawk: aah21:52
fullermd (so you'd have to manually intervene to define what each 'wrap-up point' is anyway)21:52
loops All you want is a switch to git-send-email to include a bundle21:53
ShadeHawk fullermd: one should in perfect world rewrite history for each commit to match individual step in problem solving before sending it as patch series21:53
fullermd ShadeHawk: Ah, well, that becomes another cultural difference ;)21:54
pasky it's the homework problem21:54
see the Al Viro's mail ;)21:54
loops heh.. yeah21:54
ShadeHawk by the way, two things I lack in git-send-email is option to save initial commit, or take initial message from a file (or even pre-generate shortlog and diffstat), and protection from not providing any patches21:55
I think the second was addressed, but I'm not sure21:55
and of course the way to use git-send-email with GMail21:55
pasky spearce: did pg use the series file?21:56
I have this problem: I have a vanilla tree X and RPM distribution package which consists of tarball with X and a set of patches, recorded in specfile21:56
spearce pasky: no, no series file. patches were stored as refs within the refs directory, the directory contents provided the series. :-) 21:56
pasky and I want to use Git to manage not only the distribution package directory, but also the tree with the patches21:57
spearce: ok so that sucks the same way as stgit...21:57
I'll have to have a look how mq does things21:57
spearce yup, same suckage, different name.21:57
pasky I knew it once, but forgot happily again21:57
:-))21:57
ShadeHawk Hmmm... it would be a nice system, to have RPM patches recorded as StGit/pg patches, to allow for resolution if patch applying fails (for example patch was accepted into mainline)22:00
pasky I'm using quilt now, but it sucks22:00
mugwump yeah, same thing for dpatch patches on debian22:00
loops pasky, I use stgit to manage rpm patches... what are you trying to do that doesn't work ?22:01
ShadeHawk even better for deb because as far as I know they need mega-patch (which can be composed by StGit/Git from series/stack)22:01
pasky loops: I'm not trying yet, just thinking about it :)22:02
I should move to the trying phase, yes22:02
loops it works pretty well22:02
pasky one thing is that the rpm package and patches stack history is not connected22:02
loops yes.. you have to hand edit the spec file after figuring out if a patch has been merged upstream etc..22:03
ShadeHawk in short, you need a tool which would change [parts of] spec file22:04
actualizing version, adding/removing patches, etc...22:04
if the program in question is managed using git, and releases are from tags... well, that's I think perfect situation22:05
pasky yes but then I need to switch to another branch or seek to an earlier version of the specfile22:05
and then I'll need to basically wipe out my stgit-tracked tree and rebuild it from scratch22:06
or do something smarter, which is of course possible22:06
but throwing away the stack is inevitable anyway22:06
with the current state of things22:06
loops hmm... why?22:06
ShadeHawk why? you can always put it into some kind of Attic22:06
pasky so I'll have attic full of stacks for all the revisions of the specfile22:07
doesn't sound that good22:07
and all of them have to be readonly22:07
ShadeHawk I'm not sure if storing patches in a tree is a good idea...22:07
not a problem, just don't use refs/heads/22:07
robin what if the stack be be generated from the spec file?22:07
pasky it's a problem when the history gets any bigger22:07
ShadeHawk but for example refs/history/ or refs/Attic/, or...22:07
pasky and stack any larger22:08
packed refs can alleviate it for a while, but it still doesn't scale22:08
ShadeHawk well, you can always connect stacks as additional parents for commit for spec file22:08
→ cworth joined22:08
pasky but then the history browsers will go totally mad22:09
read as be completely useless22:09
ShadeHawk doing by hand octopus merge with faked parents22:09
then graft-it away22:09
pasky and I actually do merges on the history of the specfiles fairly commonly22:09
ShadeHawk or graft-in octopi22:09
pasky I don't even want to think about what would happen if I'd like to merge _this_22:09
ShadeHawk oh, well...22:10
pasky ShadeHawk: then I'm back at the scaling problem, I'll get huge amount of grafts, which I'll have flip/flop turn on/off22:10
but most importantly22:10
all those suggestions are huge ugly dirty hacks :)22:10
loops you guys are thinking much deeper than i have about this.. all i do is --clone my stg branch when i'm ready to make a new rpm22:10
pasky well I'm doing this for SUSE's glibc RPM package22:11
loops and i don't manage the spec file in the same repo.. (because most of what i track is in CVS upstream (yuck))22:11
pasky which has very large tree and a lot of patches, a lot of releases and several branches I have to maintain concurrently22:11
so it's all fun22:11
ShadeHawk well, yet another (probably equally unworkable, ;-) idea is to have "patch-history" branch, which 1st parent would be previous commit in this branch, and other parents would be the branches which make the steack/the patches22:12
pasky please, no unrelated parents22:13
→ DrNick joined22:13
pasky it just won't work and it's ugly :)22:13
ShadeHawk but if it is only for saving patches history... you actually work using StGit on patches22:13
or just unrelated branch which would have patches as files...22:14
not very efficient wrt packing, but...22:14
pasky well, I'll have to look deeper into how stgit versions patches, and if it can be sanely used for versioning whole stacks and between several branches etc.22:14
loops It doesn't sound like you really want stgit22:14
it sounds like you want topic branches for each rpm-patch22:15
pasky I wouldn't have a big problem if the patches wouldn't be saved in plaintext and that would be generated every time I submitted a new glibc to our build system22:15
loops but i'm not really following any of this conversation ;o)22:15
pasky huh... no, topic branches aren't really relevant in this specific problem :)22:15
ShadeHawk http://wiki.procode.org/cgi-bin/wiki.cgi/StGITtheory22:16
loops pasky, are you sure topic branches couldn't be used to track each rpm-patch.. and use a release branch that merges upstream + all topics .22:18
a script could then pull off each diff to create the topic-branches into a patch series for the rpm22:19
ShadeHawk e.g. for rpm n.m-r you use short branch n.m-r which is on top of n.m sources; then convert it to tag and/or send to attic22:19
loops but of course.. that doesn't do much to track the spec file.. it'd have to be separate...22:20
okay.. i'll shup...22:20
ShadeHawk or add option to git to _not_ delete reflog, and to not prune reflog marked commits.22:20
spearce i think i proposed that to Caitlin but he went off and did something else to save patch history in stgit.22:21
robin the stgit theory page doesn't include the patch log (fairly recent)22:22
loops what did you propose shawn ?22:22
spearce make every patch a ref and just update the ref on every refresh/push operation. the patch log would automatically go into the reflog.22:22
loops ahh22:23
that sounds like it more or less boils down to having a topic branch for each patch22:24
spearce yes, except that each topic branch is merged into the one applied after it in the stack.22:25
loops right22:25
pasky loops: I still don't get that about the topic branches22:26
how would that help me?22:26
and it still would substitute just for the stgit stack, right?22:26
loops pasky, i'm not sure i know what problem you're trying to solve.. it sounded like you wanted to maintain a rpm patch series inside git, and have a usable history22:26
pasky hmmmm22:27
actually what you are suggesting does not sound all that bad22:28
loops well it sounded like a natural way to use git22:28
pasky even though I'm not sure if you mean what occured to me ;)22:28
loops i do.. :o)22:28
pasky okay :)22:28
loops unless it's a crap idea.. in which case it's all yours22:28
;o)22:29
pasky I'm taking the risk ;)22:29
Insount` → Insount22:30
loops well my idea was basically... branches like so: upstream, rpm-patch1, rpm-patch2, rpm-patch3.. etc...22:30
robin sound like what stgit does (if I understand what it does...)22:30
→ dc3aes joined22:31
loops you should be able to script the automatic creation of a spec file from that, and use git tools naturally, and get good history viewing of everything.22:32
pasky sticks "pkgit" to his TODO list, along "bugit"22:32
spearce heh. bugit. :)22:32
pasky distributed bug tracking system22:33
spearce i figured as much.22:33
loops does trac or any other bug tracking have a git back end yet?22:33
spearce trac, no. someone started one but gave up.22:33
pasky I thought it did?22:33
pasky shrugs22:34
spearce i tried to find the backend about 3 weeks ago but its missing from the trac repository where it claimed to be.22:34
pasky any bug tracking system that can't answer a query like "does version X contain bug like 'Y'?" is inherently sucky22:34
AFAIK none can now22:34
flz someone wrote the bugs everywhere backend for git i think22:36
robin We track that the other way around. Looking at the commits answers the question.22:36
flz (if you're looking for dBTS)22:36
spearce just wants a git-send-mail that works. :-(22:37
spearce manually sending 4 patches sucks.22:37
robin stg mail works nicely22:37
pasky yep, stg mail works fine ;-)22:38
pasky hides22:38
spearce no cogito mail? :)22:38
loops lol22:38
pasky it's been on TODO list for cg mkpatch, but I don't know if I'll ever implement it22:38
since in every case you'd want to mail the patch, you should be using stgit from cogito's POV22:38
flz: thanks, will have a look22:39
ShadeHawk spearce: what doesn't work for you in git-send-mail?22:41
spearce i don't know. it sends just fine back to myself but it won't send to the list.22:41
ShadeHawk and you send with which method?22:43
spearce now i send by loading each patch into mutt one at a time. :-)22:44
ShadeHawk (vger is a bit ant-SPAM picky about accepting mail from hists which have no proper DNS, or doesn't respond well to greylisting)22:44
I do the same, only with KMail, not mutt22:44
s/hists/hosts/22:45
→ robin joined22:49
spearce the funny thing is i configured git-send-mail to go through the same SMTP server mutt is going through... so i'm a bit confused about why the messages are going through the same server yet one gets to the list and the other doesn't.22:49
loops can you send somewhere else? for example to a hotmail or gmail addy?22:50
spearce yup. :)22:50
robin dump the traffic with ethereal and compare the messages22:50
loops must be the vger spam shite22:50
robin maybe some header line is messed up by git-send-mail and "fixed" by mutt22:51
spearce probably22:52
robin any dump the traffic, smtp is all plain text anyway so it's easy to read22:52
Qball → coz_22:52
robin s/^//22:53
s/^any// :)22:53
coz_ → qball22:53
qball → qb22:54
qb → qball22:55
spearce time to get out of here. maybe i'll get around to looking at my git-send-mail problem but it has been low priority for me.22:55
qball → qba1122:55
qba11 → jbong22:56
jbong → qball22:57
→ robfitz joined23:19
ShadeHawk Is there any way to check in Perl if the argument passed to subroutine is filehandle (of fileglob), or string?23:45
robin yes; not sure how though.. :(23:51
→ Gitzilla joined23:51

Logs Search ←Prev date Next date→ Channels Documentation