[09:40] <orsonmmz> hi
[09:40] <orsonmmz> any launchpad devs around?
[09:43] <cjwatson> orsonmmz: What's up?
[09:43] <orsonmmz> we switched from bzr to git (thanks for supporting git!)
[09:44] <orsonmmz> and we looked for a way to mark bug reports as resolved in a commit
[09:44] <orsonmmz> as we used to do with bzr
[09:44] <orsonmmz> so there is a git hook we use to handle this automatically
[09:44] <cjwatson> orsonmmz: In our git model, we only do bug scanning at the merge proposal level
[09:44] <orsonmmz> I know, we wanted something more:)
[09:45] <cjwatson> Well, all it would've done in bzr would be link the branch to the bug in the UI
[09:45] <orsonmmz> I just wanted to let you know that we wrote a hook that parses commit messages and marks bug reports as fixed whenever 'Fixed: number' line is found
[09:45] <cjwatson> It never closed bugs automatically
[09:45] <orsonmmz> right, that's true
[09:45] <cjwatson> OK, it's totally fine to do whatever project-specific workflow you want by way of hooks
[09:45] <orsonmmz> anyway, I just wanted to leave the hook here in case you find it useful https://git.launchpad.net/kicad-git-hook
[09:46] <orsonmmz> if it does not fit the plans, just ignore the message
[09:46] <orsonmmz> it is very convenient for us, so I decided to share it
[09:46] <cjwatson> orsonmmz: Mind if I link to it from https://help.launchpad.net/Code/Git ?
[09:46] <orsonmmz> cjwatson: no problem
[09:47] <orsonmmz> probably I should remove all 'kicad' references there, as it should work for any project
[09:49] <cjwatson> orsonmmz: linked, thanks!  If your project uses merge proposals, then things will work a bit more smoothly if you change your commit message conventions to match https://help.launchpad.net/Code/Git#Linking_to_bugs
[09:51] <cjwatson> (but if you don't use MPs, then whatever)
[09:51] <orsonmmz> it is rather up to contributors, but we rarely get merge proposals
[09:52] <orsonmmz> I am not sure why, it seems rather convenient
[09:56] <cjwatson> It would be very difficult to do bug linking at the branch level, partly because git branches are quite ephemeral, partly because it's hard to see how to do something coherent when pushing a new repository without having to (expensively) scan the entire commit graph, and partly because commits are typically reachable from multiple branches so we'd need to know information about the ...
[09:56] <cjwatson> ... repository's topology in terms of topic branches vs. trunks to work out where it would be best to attribute commits
[09:56] <cjwatson> So we went for merge proposals instead because that gives us a much better idea of the committer's intent, as well as being very much cheaper to compute
[10:08] <rbasak> "If pushing to the branch that HEAD points to, and it's a fast forward commit, then scan all old..new commits for bugs to autoclose"?
[10:09] <rbasak> In fact even when not fast forwarding that could hold true.
[10:24] <cjwatson> We thought about it, but it would have weirdly different behaviour for new repositories vs. existing ones.
[10:25] <cjwatson> Also, we generally don't want to auto-close bugs based on revision control, because that requires too much project policy.
[10:25] <cjwatson> For example, in Launchpad we don't want to close bugs until we've deployed.
=== maclin1 is now known as maclin
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== maclin1 is now known as maclin
=== chihchun is now known as chihchun_afk
=== maxb is now known as Guest16693