Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom repo names #382

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

michaelstorm
Copy link
Contributor

Patch contents

  • Introduces a Name field next to the Repo url field on the repo admin page. A script sets the text in the Name field to a default name based on the URL. The Name field is updated every time the URL field value changes.
  • Allows the "/" character in repo names. When the repo is cloned, the "/" characters are interpreted as directory separators on the target filesystem.
  • Introduces a base/test_git_repo submodule in order to test this functionality.

In other words, if REPOS_ROOT = "/home/michael/barkeep_repos" and I clone a repo named michaelstorm/barkeep, then it will be cloned into /home/michael/barkeep_repos/michaelstorm/barkeep.

Rationale

As mentioned in #377, the proper name of a repo from a Barkeep user's point of view is not always the same as what the administrator hosting the repo thought it should be.

Additionally, namespacing repos in this way seems to be common practice today. GitHub and GitLab both do it, as do we at my company. (I don't speak for them, etc.) While changing the repo name from its origin is useful, so is fully preserving it, namespace and all.

Notes

base/test_git_repo is a clone of michaelstorm/barkeep_compound_name_integration_tests. It's identical to ooyala/barkeep_integration_tests, but with the committer names and emails changed to refer to me. Therefore, the SHA commit hashes are different, and we get namespace collision testing for free.

The command-line client handles compound repo names if specified, but still uses the basename of whatever git repo the user is in if not. This could get confusing, but I decided to leave it for now.

/api/add_repo takes a new, optional name parameter. If it's not specified, name will default to the repo name that Barkeep would have chosen previously. If we're okay with breaking script compatibility, this parameter can become required.

when %r{^[^/]+/#{SHA_REGEX}$} # foo/abc123
commit_specification.split "/"
when %r{^(\S+)/(#{SHA_REGEX})$} # foo/abc123
[$1, $2]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These magic vars are hard to read. Use Regexp.last_match instead.

@philc
Copy link
Contributor

philc commented Feb 28, 2013

Thanks for working on this Michael. I think we still need to decide whether the benefits of being able to name one's repos is worth the added complexity: this patch introduces a new test repo dependency, a lot of changes to the test, and the structure of the API routes is now potentially more complicated.

@michaelstorm
Copy link
Contributor Author

It's not just the custom naming - it enables namespaced repos. We're using GitLab 4.0 internally, with integration hooks set up to automatically clone repos in Barkeep upon creation in GitLab. So this is a must-have for us. Hence why I wrote it.

I'll get to your inline comments when I have more time.

@jwhitcraft
Copy link

+1, this would be an awesome feature and is needed for the way my team works.

@irabinovitch
Copy link

I believe this would fix #461 as well. Will try to test locally.

@jcdrubay
Copy link

+1, we need this as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants