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