git based import for projects in addition to cvs and svn import

Increasing numbers of Debian-native projects are moving from svn to git (not universally, but enough to be significant), so this is going to become an increasing problem for us in Ubuntu as we lose imports of things we were previously able to manage in bzr. This recently happened to me with tasksel.

On Tue, Dec 16, 2008 at 10:40:30PM -0000, daly wrote:
> ** Description changed:
>
> Please add git based import functionality to the launchpad, so that we can directly import source code for projects and products for git repositories.
> So we can also use it for building for packages other than CVS and SVN.
> Most of the projects are switching to git, So I would like ask you to please develop a mechanism so we can import code into projects/products from git repositories
> +
> + In particular, you need closer integration with github.com
> + Launchpad apparently will let me build packages that Ubuntu users can download
> + which is a nice feature. However, while I already support arch, svn, cvs, and git (the
> + project is moving to all git eventually) I really don't want to create and learn bazaar
> + just to host on launchpad. So the URL
> + git://github.com/daly/axiom.git
> + should "just work"

In which way do you think accessing a git repository is anything special
only because it happens to be hosted on Github?

Its actually not a question of github, its a question of supporting the git:// protocol header.
All of my git repositories (and most others) use git:// as the protocol and your input
field will not allow me to enter it. Thus I cannot point users at my external repository.

Tim

This bug is not referring specifically to github.com integration. It is referring to importing projects from Git repositories.

A question for those interested in this bug: do we need to support imports from non-master branches?

I'd figure, it will happen eventually.

Michael: If it's straightforward, I'd like to be able to name the branch to import rather than it being hardcoded to "master".

If you mean imports of multiple branches from a single git repository, I don't think that's any more urgent than the same feature for other revision control systems supported by Launchpad's code import infrastructure. I'm sure we will eventually find a case where we need it, but for the meantime imports of just one branch will be a major benefit; I don't think we should block git imports on multiple-branch imports.

On Tue, 03 Mar 2009 09:32:19 -0000
Colin Watson <email address hidden> wrote:

> Michael: If it's straightforward, I'd like to be able to name the
> branch to import rather than it being hardcoded to "master".
>
> If you mean imports of multiple branches from a single git
> repository, I don't think that's any more urgent than the same
> feature for other revision control systems supported by Launchpad's
> code import infrastructure. I'm sure we will eventually find a case
> where we need it, but for the meantime imports of just one branch
> will be a major benefit; I don't think we should block git imports on
> multiple-branch imports.
>

I agree, importing from a chosen branch would be the ideal mechanism.
If supporting this on the Launchpad UI would be difficult, it could
maybe default to the master branch, and allow you to override this with
a suffix on the import URL, eg:

git://sean@remote/repo#mybranch

Having said that, right now I'd be happy even if it was hard-coded to
master, that would still be better than complete lack of support :)

I am happy this question has been asked. I am exploring use of this community on behalf of a client. They've fully committed to git. I like the all of the other features of launchpad.net and believe this is the right way to go. However, there will be no budging the team off of git. It's a religious thing, as SCM always seems to be. This is a very reasonable bug/RFE given many teams are moving towards git. Git has clearly emerged as the leading DRCS.

What I think would be useful for starters is a way to setup a sync import (1 way from a git repository, most likely to be github.com) into launchpad, a periodic process triggered on any change event to the specified branch on the remote origin. What this would accomplish from my perspective is a way for the git minions to continue working exclusively with git, but accomplish the goal of allowing the team to work with launchpad for all of the community benefits and unique features. For users who choose to use Bazaar and pull from the project, this can be considered to be a fully functional local branch of the git remote origin, but the user would not be able to push back to git from Bazaar. To accomplish this, one could possibly use one of the git import utilities to import from Bazaar back into a git branch, and then merge the changes back into the remote origin's git branch we pulled from originally. It sounds like a lot of effort, but it is exactly the kind of thing real git users revel in for their workflow. Ultimately, would be nice if people just used Bazaar, but as mentioned, this is not always possible.

The real problem with my workflow proposed is that I do not have any details on how one would handle conflicts during a sync from the remote git branch. You don't want to sync and break the working Bazaar branch, silently or otherwise, due to a merge conflict. An interactive merge would be a possible approach, requiring a manual intervention if there is a conflict. Any thoughts on what the scope of work to satisfy closing this bug? Seems that Subversion handles their mirror syncs by making the sync a read only tree, so that all syncs should in theory happen without merge conflicts.

I think we can call this fix committed now.