[Question] Local `user.name` and `user.email` in subrepo?

[c-alpha]

Is it possible to have a local user.name and user.email for a subrepo?

The subrepos may come from different git hosting platforms, and I would want to use a different user.name and user.email for each git hosting platform.

[admorgan]

How do you expect this to work? subrepo doesn't get involved with individual commit messages.

[c-alpha]

Thanks for your swift response!

With a submodule, I can set user.name and user.email for the submodule only. When I cd to the submodule, and do a git config --get-regexp '^user\..+$', I get different results than in the main repo, and the submodule-specific values will be used by git as the commiter's name and email for commits from within the submodule.

Now subrepo does things differently, of course, and I am (not so proudly) showing off my lack of understanding how it does things. Ideally (for my use-case at least), the name and email of the committer could be set to a remote-specific value upon git subrepo push. This would have the downside, however, that the hash of the commit would be changed. This will all but certainly lead to very undesirable effects when git subrepo fetch, I presume.

It would thus seem to me, that my use-case is technically not possible?

Many thanks, and looking forward to your thoughts.

[admorgan]

The difference between submodules and subrepo is that submodule is an entirely different git repo that is closely associated with the parent. In subrepo there are two disconnected repos the parent contains the content of the other at snapshots. This can be observed in the fact that a commit in a submodule parent repo can't change both the content of a file in the submodule as well as a file not in the submodule at the same time. You can move the location of a submodule reference and update files not in the submodule, but not actually change the submodule itself.

When you do git subrepo push in the background we pull the history of the remote repo and then functionally replay the commits that happened to the subrepo directory onto it. As you pointed out these changes that are played onto the remote repo have a different SHA and since only the part that changed that directory kind of different content. As part of this "playback" there could be a setting that says remap user A to user B for just the commits that are replayed. Describing in such a way that it would be hard to get wrong could be difficult.

[c-alpha]

The difference between submodules and subrepo is that [...]

I see; thanks for pointing out the different approaches.

When you do git subrepo push in the background we pull the history of the remote repo and then functionally replay the commits that happened to the subrepo directory onto it. As you pointed out these changes that are played onto the remote repo have a different SHA and since only the part that changed that directory kind of different content. As part of this "playback" there could be a setting that says remap user A to user B for just the commits that are replayed.

That's interesting. So technically you generate a synthetic history of local changes, which then get replayed. As you state, the committer information could be set. Instead mapping A to B, for my case it would be sufficient to simply use committer B for all replayed commits, regardless of who the "local committer" was.

Describing in such a way that it would be hard to get wrong could be difficult.

Not sure what you're thinking of here?

Perhaps it could be documented similar to this?

=item C<< git subrepo config <subdir> <option> [<value>] [-f] >>

Read or update configuration values in the subdir/.gitrepo file.

Because most of the values stored in the .gitrepo file are generated you
will need to use C<--force> if you want to change anything else then the
C<method> option.

To use a different user name and email address for commits when pushing
from a subrepo to a remote via C<< git subrepo push >>, set the
C<user.name> and C<user.email> options for the subrepo with this
command using the C<--force> flag. 

Example to update the C<method> option for a subrepo:

    git subrepo config foo method rebase

Example to use a different user when pushing from a subrepo:

    git subrepo config foo user.name "John Doe" -f
    git subrepo config foo user.email jdoe@example.com -f

[teneko]

@c-alpha I just want to point to a superuser comment that mentions a valid approach I didn't come up by myself:

you have two distinct repos:

• /repos/a ¹
• /repos/b

¹ _{In Windows you just use DOS paths.}

and want something like:

• /repos/a/b
• /repos/b

where /repos/a/b has the following characteristics:

• it has all the content of /repos/b, but:
• it does not have the .git folder, so /repos/a/b/.git is nonexistent
• any content change contrbutes to the history of /repos/a
• to propagate any change to the history of /repos/b you must follow characterics of repo of /repos/b (see below)

and where /repos/b has the following characteristics:

• it has the .git folder, so /repos/b/.git is existent
• to contribute any content change of /repos/a/b to the history of /repos/b you must use git --work-tree="/repos/a/b" <command>
• (!) author and committer CAN differ from /repos/a, because of own .git folder, implicating own commit history with own authors and comitters

The workflow appears to be:

You work in the /repos/a directory, make changes, commit as usual. Whenever you feel the changes of /repos/a/b are significant to /repos/b, you go to /repos/b and treat /repos/a/b as /repos/b by using git --work-tree="/repos/a/b" <command>.

Downsides

In view of /repos/a /repos/a/b is just a directory with content without link to /repos/b; another contributor won't know about it.. so you should document it, I guess? You also have to commit twice, once for /repos/a and once for /repos/b, but that's okay and desired? And last but not least you should only consider it when you have to (1) contribute to /repos/b and that (2) with another "identity".

Reference: https://superuser.com/a/1072474/1138453 (see comments for reducing --work-tree= overhead)

[c-alpha]

Thanks for the pointer, and the great explanation, @teneko ! Interesting "shadow repo" approach that is.

I was however looking for a mechanism that would allow a subrepo with different user name & email within a single repo.

[admorgan]

From your example documentation it would be more difficult than than.

Example to update the C option for a subrepo:

git subrepo config foo method rebase

Example to use a different user when pushing from a subrepo:

git subrepo config foo user.name "John Doe" -f
git subrepo config foo user.email jdoe@example.com -f

git subrepo config stores the configuration in the .gitrepo file so it would apply to anyone that uses the subrepo in the future. if you set username in that file all changes from everyone would use the same values. This is unlikely to work on many forges as many restrict who you can submit code as. It can be stored in your local configuration though.

This is something not technically supper hard, I just haven't been excited enough to implement it yet.