=== chihchun_afk is now known as chihchun
=== rumble is now known as grumble
[08:10] <stub> Why do we have +git in urls like git+ssh://git.launchpad.net/project/+git/repo or git+ssh://git.launchpad.net/~uname/project/+git/repo ?
[08:11] <wgrant> stub: The former doesn't exist.
[08:11] <wgrant> The latter is usually shortened to git+ssh://git.launchpad.net/~USER/PROJECT, unless the user requires multiple repos for the same project.
[08:12] <stub> I keep ending up with multiple repos (software, charm, deb packaging, maybe snap packaging)
[08:13] <stub> Is the +git there to keep the paths the same with the https: url namespace? And +git needed there for disambiguation?
[08:15] <wgrant> stub: Seems like you might be able to get away with different branches for that.
[08:15] <wgrant> stub: But yes, we didn't want to have a path mismatch between git.launchpad.net and launchpad.net.
[08:15] <stub> yeah, but orphaned branches and multiple working trees is a solution that is worse than the problem
[08:16] <stub> multi-repos seems easier to work with
[08:17] <stub> So I could use teamname, project name and repo calculate the git url unambiguously, except for non-project repos or distro packaging branches
[08:18] <wgrant> stub: What are you trying to do?
[08:18] <wgrant> All Git repositories have a full path of the form ~OWNER/TARGET/+git/REPO
[08:18] <wgrant> Where TARGET is PROJECT or DISTRIBUTION/+source/PACKAGE
[08:18] <wgrant> There are additionally TARGET and ~OWNER/TARGET aliases which may point to one of the in-scope repositories.
[08:19] <wgrant> https://help.launchpad.net/Code/Git#Repository_URLs
[08:19] <stub> Thinking about 'go get launchpad.net/project', 'go get launchpad.net/~owner/project' and 'go get launchpad.net/~owner/project/repo'
[08:19] <wgrant> oh, and TARGET may be omitted for junk repos, of course.
[08:19] <stub> (and all the related go tooling, which is based on 'go get')
[08:20] <stub> Wondering if it is an LP problem, adding the magic headers so we can pull private branches and such, or a go tool problem, extending its support of launchpad.net for bzr branches to bzr + git
[08:22] <wgrant> stub: LP already gross language-specific HTML metadata.
[08:22] <wgrant> "go get launchpad.net/foo" should work for bzr or git.
[08:23] <wgrant> Project pages have a go-import meta tag
[08:24] <stub> Not for private branches, which I guess makes this a go tool problem
[08:24] <cjwatson> You can have multiple working trees for the same repository, of course
[08:25] <cjwatson> Especially with modern git and git-worktree, though you can always just have multiple clones
[08:25] <stub> cjwatson: yes. I do that to maintain a 'built' branch in some of my charms, but it gets tricky and I'm not sure it is worth it.
[08:26] <stub> (charm built to another branch/worktree of the same repo)
[08:26] <stub> c/built/build/
[08:26] <rbasak> Using separate repositories instead of multiple worktrees introduces a further problem of having to always push to the right place to get the repository itself updated correctly.
[08:26] <cjwatson> Usually I find that a profusion of repositories for basically the same project indicates that I'm doing something wrong :)
[08:27] <rbasak> Worktrees were invented to solve these problems :)
[08:27] <wgrant> We support multiple repositories per (user, target) mostly for cases where different permissions are required.
[08:27] <stub> My packaging branch has my software pulled in as a git submodule at the moment. I'm trying to work out the least worst solution.
[08:28] <cjwatson> git-dpm
[08:28] <cjwatson> (IMO)
[08:29] <stub> ta
[08:29] <rbasak> Why not merge the upstream in to the packaging branch? That's another way that is very common (gbp).
[08:29] <stub> Its particularly crappy with go, where stuff will only build if it is located in $GOPATH/src/package, yet other projects using the software as a library need things at the top level
[08:29] <cjwatson> (git-dpm also merges the upstream into the packaging branch; the main difference between the two is in the style of patch management)
[08:29] <rbasak> (IMHO, git-dpm is quite complicated to grasp, and gbp is much easier when big sets of patches upon upstream are not needed)
[08:30] <cjwatson> Yeah, as usual there are multiple different factions :-)  But either gbp or git-dpm is waaaaaaaaaaaaay saner than submodules.
[08:31] <stub> I tried to make a submodule of another branch in the same repo the other day. But that failed.
[08:31] <wgrant> Everything about submodules is awful.
[08:32] <rbasak> I've found that submodules don't work so well when you have branches with the submodules rooted at different places (or going from branches with a submodule to branches without, etc).
[08:32] <rbasak> It's workable but it seems to me that an understanding of the internals is needed in that case - which I do know, but the UX seems especially poor otherwise.
[08:32] <cjwatson> I've found that submodules don't work so well
[08:32] <rbasak> :-)
[08:33] <stub> least worse solution ;)
[08:33] <stub> (or is it least worst solution? )
[08:33] <wgrant> Submodules are worst worst.
[08:33] <stub> Some people prefer them to subtrees
[08:34] <cjwatson> I have one remaining place where I used submodules and I regret it.  Should've just merged.
[08:34] <cjwatson> (debian/grub-extras in the grub2 packaging)
[08:34] <rbasak> Is it possible to use a merge process instead of multiple submodules? I've never tried that.
[08:34] <cjwatson> Should be, subtree merge strategy or similar
=== chihchun is now known as chihchun_afk
=== tacocat` is now known as tacocat
=== JoseeAntonioR is now known as jose
=== hrybacki|trainin is now known as hrybacki
=== heber_ is now known as heber
=== shadeslayer_ is now known as shadeslayer
=== lan3y is now known as Laney
=== heber is now known as heber_lunch
=== nacc_ is now known as nacc
=== heber_lunch is now known as heber
=== wxl_ is now known as wxl