| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| rbasak | https://help.launchpad.net/Code/Git suggests setting lpme: to "git+ssh://USER@git.launchpad.net/~USER/+git/", which I have. | 12:25 |
|---|---|---|
| rbasak | But then I pushed to lpme:usd-importer, and the branch that appeared didn't have a "Propose merge" button. | 12:25 |
| rbasak | OTOH, if I drop the +git, it does have a "Propose merge" button. | 12:25 |
| rbasak | This feels inconsistent somewhere, but I don't know enough about the intentions behind the +git thing to say where. | 12:26 |
| rbasak | If I drop the +git from my alias, what would that break? | 12:27 |
| maxb | Check the wiki again, lpme: as expressed there is intended for personal, not project, repositories | 12:29 |
| rbasak | I was unaware of the distinction. This is ugly though. I have to push to something in my personal space to send a merge proposal. | 12:31 |
| rbasak | It would be nice to have an alias for that. And if there is one, then it's still ugly if I have to use a different alias depending on what I'm doing. | 12:31 |
| maxb | rbasak: I think you've just missed out on a distinction that LP makes | 12:40 |
| maxb | There are repositories scoped to your user and a project, and there are also ones scoped to your user and no project at all (intended for ad-hoc experiments) | 12:41 |
| maxb | only the first kind will offer the option of creating a merge request | 12:41 |
| === chihchun is now known as chihchun_afk | ||
| jarnos | How do you create a merge proposal for a git project https://launchpad.net/ppa-purge? | 13:07 |
| cjwatson | rbasak: Right, exactly what maxb said. Perhaps all the aliases are confusing you ... You want to push to git+ssh://USER@git.launchpad.net/~USER/usd-importer | 13:36 |
| cjwatson | rbasak: I don't like all this profusion of aliases that (notably) the server team tends to use. I just use lp: | 13:37 |
| cjwatson | jarnos: push to lp:~YOUR-USER-NAME/ppa-purge, navigate to https://launchpad.net/~/ppa-purge, pick branch, create merge proposal | 13:40 |
| rbasak | cjwatson: the problem is that we consider packages first, and then consider where they're going. Ourselves, to our staging area for experimentation, or to the final place where we intend to keep the repo. | 13:41 |
| rbasak | cjwatson: or in the case of usd-importer itself, I have only two places. The master repo, and places for our personal branches before merging. | 13:41 |
| rbasak | cjwatson: IMHO, the Launchpad scheme is extremely confusing for these use cases. | 13:42 |
| rbasak | Hence my desire for aliases so I don't have to remember the URLs. | 13:42 |
| rbasak | And if I do push to +git/usd-importer instead, why should Launchpad stop me from filing a merge proposal against usd-importer? They have common ancestory. git doesn't care. Why should Launchpad? | 13:43 |
| jarnos | cjwatson, the link https://launchpad.net/~/ppa-purge does not work | 13:43 |
| rbasak | It feels like a trap for me to fall into for no real reason. | 13:43 |
| cjwatson | jarnos: It will do once you've pushed something there | 13:43 |
| cjwatson | rbasak: The two places in question are, by default, lp:<thing> (or lp:~usd-importer/<thing> in your case I suppose) and lp:~<user>/<thing> - this is uniform | 13:44 |
| cjwatson | rbasak: There's an argument to be made that we should open up merge proposals in the personal namespace, but it still leaves open the question of how we'd know from the webapp which repositories are legitimate targets; that's quite an expensive thing to compute. At the moment we get to say "anything within the same namespace is likely a reasonable target", which is cheap | 13:46 |
| cjwatson | rbasak: (It's partly a holdover from Bazaar, but for similar reasons really) | 13:47 |
| rbasak | cjwatson: I don't mind having to specify. I realise that this means that project owners won't automatically be able to see personal branches based from them (at least easily), but that's not a feature I've ever used. | 13:49 |
| jarnos | cjwatson, are you sure? I doubt the /~/ part of the address at least. | 13:49 |
| cjwatson | jarnos: I am sure. | 13:50 |
| cjwatson | jarnos: The webapp automatically expands /~/ to /~YOUR-USER-NAME/ . | 13:50 |
| jarnos | cjwatson, I pushed by `git remote add jarnos-ppa-purge lp:~jarnos/ppa-purge; git push jarnos-ppa-purge HEAD` | 13:50 |
| cjwatson | jarnos: Should work as long as you're logged in, then. But you can always use https://launchpad.net/~jarnos/ppa-purge instead | 13:51 |
| jarnos | cjwatson, the page does not exist. | 13:52 |
| cjwatson | rbasak: There is another strong reason why we shouldn't do this right now: unless we add an explicit "fork" action, it would entirely break object sharing between repositories. | 13:52 |
| cjwatson | Oh, that's weird | 13:52 |
| cjwatson | jarnos: https://code.launchpad.net/~jarnos/ppa-purge does | 13:52 |
| cjwatson | I wonder why that only works on the code facet | 13:52 |
| cjwatson | rbasak: (which possibly doesn't work yet anyway for usd-importer stuff because there's probably no target default set, but in general ...) | 13:53 |
| rbasak | Fair enough for right now, but ultimately that's a (solvable) optimisation problem for Launchpad and should drive long term UX decisions. | 13:54 |
| rbasak | shouldn't drive | 13:54 |
| rbasak | I do appreciate all the Launchpad git support BTW. This just feels like a painful hangover from the bzr days. | 13:55 |
| rbasak | I'm looking forward to trying out the git->git mirror support. | 13:55 |
| cjwatson | I don't necessarily agree with you about UX. I think part of this is simply the wiki page explicitly guiding people in poor directions. | 13:57 |
| cjwatson | I would prefer to add an explicit fork action to a repository and then we could tell people exactly where to push. | 13:58 |
| rbasak | I don't think it makes sense to enforce different behaviour depending on "location" of a repository. The behaviour could be inferred solely from common ancestory, which can be detected (if difficult to implement given current library APIs) | 13:58 |
| cjwatson | It's not difficult to implement for a single pair. It's, I think, intrinsically very expensive to implement for the full set of repositories hosted by Launchpad. | 13:59 |
| cjwatson | Trying to do this is one of the basic reasons why Launchpad's Bazaar support is disastrously expensive. | 13:59 |
| rbasak | I don't think that holds true theoretically. It would be a lookup table of commit hash to location. Being hashes, that's quite easy (theoretically) to do in O(log n) time, and you're already using the space. But I accept that it's probably not supported by libraries and any current data structure in a way that makes it easy to implement. | 14:01 |
| cjwatson | This is a case where a bit of relatively cheap UX guidance relieves us from the need of an *awful* lot of database support. | 14:01 |
| cjwatson | And expensive scanning any time somebody pushes a new repository. | 14:02 |
| cjwatson | We don't want to have to insert (or even just scan) hundreds of thousands of rows any time somebody pushes a Linux fork. | 14:02 |
| cjwatson | Or, if we stopped at the first thing we'd seen before, then have to work out what to do if the commit is deleted from somewhere else. | 14:03 |
| rbasak | I don't think you'd need to. | 14:03 |
| rbasak | I'm not saying it's easy. | 14:03 |
| cjwatson | I'm saying it's probably possible but IMO not worth it. | 14:03 |
| rbasak | But I don't think it's as expensive algorithmically as you're saying. | 14:03 |
| rbasak | OK | 14:04 |
| cjwatson | And very easy to get wrong - the Bazaar support was done with good intentions | 14:04 |
| cjwatson | But has turned out to be a millstone around our necks | 14:04 |
| cjwatson | Anyway, I do think that adding explicit-fork will make it mostly not a problem | 14:05 |
| cjwatson | (I've also edited the wiki page a bit to try to be less misleading) | 14:06 |
| rbasak | Thanks. Yeah, explicit-fork will certainly help. | 14:06 |
| rbasak | I would still like something easy client-side though. | 14:06 |
| cjwatson | It's not clear how to make object sharing work well without guidance from the path provided by the client. It would be easy to construct something that appeared to "work" but was very inefficient, both in terms of storage and in terms of clients having to push far too much. | 14:08 |
| cjwatson | And of course people can always push to inefficient locations as it stands, but this is why I'm not a fan of an approach that encourages people to just push anywhere and we'll work it out | 14:09 |
| cjwatson | We can't deal with that by anything short of magical optimisation, because the first thing the git client does is ask which refs the server has, and then the client decides which objects to push based on that. | 14:10 |
| cjwatson | So we don't have any information about commit hashes at that point: we have to use the path. | 14:10 |
| rbasak | Oh, I see. I'm not so bothered by upload bandwidth. If Launchpad throws away some of that for deduping reasons after receipt, then I'm fine with that. By "easy client-side" I meant that it'd be nice if the client could send the path without me (as a developer) having to figure it out I think, which I think is separate (and that we might be more likely to agree on). | 14:21 |
| rbasak | For users who care about upload bandwidth, they can press a fork button first :) | 14:21 |
| rbasak | Or perhaps there should be an API inside git to request a remote fork. | 14:22 |
| === pavlushka is now known as SweetVenom | ||
| === SweetVenom is now known as pavlushka | ||
| iliv | is my understanding correct that code import is designed to work with "one app per git repository"? in my case I have snapcraft.yaml files for several major versions of the same app, all hosted in a single github repo. if I want to build snap packages automatically for various architectures I need one git repo per each major version, right? | 17:15 |
| cjwatson | That's not correct. | 17:16 |
| cjwatson | You attach a snap to a ref, not a repository, so you can perfectly well have more than one per repository (and indeed you can have more than one per ref if you like, which is occasionally useful if you have a reason to build the same snap from different .deb archives). | 17:17 |
| cjwatson | Also it doesn't matter for this whether it's an imported repository or one that you've pushed directly to Launchpad. | 17:18 |
| iliv | thanks cjwatson. just finished watching your demo of how to do this and still have plenty of questions. unfortunately, documentation on Launchpad isn't very helpful (or I'm looking in all the wrong places) | 17:22 |
| iliv | anyway | 17:22 |
| cjwatson | I agree we could use better docs here. | 17:24 |
| cjwatson | It should be clear enough how to create things if you go to the repository page in LP, pick a branch, and hit "Create a snap package". | 17:25 |
| iliv | no offense to you guys, but I find Launchpad's interface rather hard to work with overall | 17:31 |
| iliv | just saying | 17:32 |
| iliv | ;) | 17:32 |
| === pavlushka is now known as PocketBot-lushka | ||
| === PocketBot-lushka is now known as pavlushka | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!