On Sat, 2019-08-17 at 17:29 -0400, Michael Orlitzky wrote: > On 8/17/19 4:43 PM, Michał Górny wrote: > > > I realize we'd have to tell people how to rename the account to support > > > upgrades -- but is there some other reason to keep the shared "git" name? > > > > The argument I've been told is that users expect 'git@...' to work > > as remote URI on their boxes. They don't want users to bind the URI to > > specific implementation. > > > > It's not really a URI... it's a username on a remote machine. And these > "users" are programmers =P > > But, I can understand not wanting to tell a bunch of strangers to edit > all of their ~/.git/config files at this point. > > Instead of configuring both packages to use different users, could we > configure them to share a working directory? If we give the "git" user a > home directory of /var/lib/git [0], then as far as I can tell, both > gitolite and gitea will be happy with that. They use different > configuration file names and repository locations, and wouldn't need to > block each other.
It is an interesting concept. However, it assumes that all existing installations need to be migrated to the new directory, and I don't think it's safe to try to do it automatically. So it really sounds like we're a. adding extra work on sysadmins, and b. breaking stuff on upgrade, on the vast majority of production systems that only care about having one of them installed. > > > [0] This doesn't violate the guidelines that I posted since real humans > log in as this account to clone repos out of $HOME. Moreover, I don't > think that either gitolite or gitea references this path itself -- it > really belongs to the user. > > -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
