commit log accounts not linking to drupal users

Version Control API seems to be responsible for that: in versioncontrol.pages.inc, versioncontrol_account_edit_form_validate(), it restricts user name registrations to alphanumeric characters only. That makes a lot of sense for CVS and SVN, but might not be such a good idea when considering arbitrary (email-display-name-based) user names like in Git. I wonder how to best delegate that decision to the backends, hm...

Still not solved in 5.x-2.0, sorry.

I am currently working on a stand-alone Git read/write class. I have implemented a basic manager for git repos (much like ViewGit) in Drupal module, using email to cross-link users. It works really well, but I would like for it to be a part of the Version control API. Any help that anyone can provide would be much appreciated. What is needed to combine these efforts with the other Git/VCS stuff?

First step, I'd say, is looking at the git vcs project, since that's where such things would live. Write operations aren't much supported at the moment, though; it's something that I VERY much want to work on in the future, but there are steps between here and there.

Much of the git backend's code might be obsolete though when it's updated to the 5.x-2.x API, it doesn't need to be that complex anymore. Also, a git interface class might help implementing the git backend's repository browsing support (get_item(), get_directory_contents(), get_file_copy() & Co.). Repoview should even be able to display the basic repository contents without having the existing git log parser ported as a prerequisite.

This belongs in a separate issue though, I would think that the git backend's issue queue would be the best place to continue this discussion, it's just a bit off-topic in here.

Had the same problem with svn. Resolved by hacking versioncontrol.pages.inc

@neptunix: Aren't SVN usernames required to be lowercased and stuff? Anyways, seems like it's high time to split this check off into an optional backend function.

Moving to 6.x-1.x, won't be backported to 5.x-* (at least not by myself, and any patch should target the current version first).

I think this should be a backend-specific API function, like versioncontrol_is_valid_username($repository, $username) respectively versioncontrol_[backend]_is_valid_username($repository, $username). versioncontrol.pages.inc should then just use that function to check whether it should set an error or not.

...any takers?

it's me :)

here's a patch adding the usage of a new api call, is_invalid_username($repo, $username) for cheking if a username is ok for a specific backend.

patch was crap, another try...

Looks great! The only thing I forgot to mention in IRC (sorry) is that backend-implementable API functions should be documented in the FakeVCS backend by provding apidox for the function, and a short example implementation. (The ereg() version from versioncontrol.pages.inc would be totally sufficient... apart from PHP suggesting preg_match() instead, maybe we should switch to that one altogether?)

ok
i still have to practise with git-format-patch, now i offer you two patches...

I added a lot more to your patch (felt like solving the whole problem area surrounding this issue), fixed a bug in the patch and a bug that existed previously, and committed all of it in commit #192592. Thanks for getting involved, I'm glad this is fixed now :)

Note: Of course, other backends with different needs than CVS still need to implement stuff (versioncontrol_[vcs]_is_account_username_valid() and versioncontrol_[vcs]_account_username_suggestion()) if they want to improve the current situation. Both are documented in versioncontrol_fakevcs.module.

Automatically closed -- issue fixed for 2 weeks with no activity.