Launchpad itself

Bug #104564
Comment #9

Comment 9 for bug 104564

Revision history for this message

David J. Kordsmeier (dkords) wrote on 2009-04-30:

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 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.