Re: [lmi] Proposed workflow for proprietary repository

[Greg Chicares]

On 2016-03-10 20:41, Vadim Zeitlin wrote:
> On Thu, 10 Mar 2016 20:31:12 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> That didn't work. After trying and retrying the whole process from scratch
> GC> (including recreating a virgin repository) several times, Kim found a way
> GC> to make it work: use 'git config' to set her name and email address equal
> GC> to mine before applying my patches. That works: same sha1sums. Any other
> GC> identity fails: the patches apply correctly, but the sha1sums differ.
> 
>  Oh, yes, of course, sorry, I should have, once again, foreseen this in
> advance. To obtain the same SHA-1 sum, you need to also use the same
> committer information and while Git takes the authorship information from
> the patch, it is not the case for the committer

AARRGGHH

>  To obtain the same SHA-1 you do need to use the same committer as well,
> which can be achieved, in addition to globally modifying git configuration,
> by setting GIT_COMMITTER_{NAME,EMAIL} environment variables or using "-c
> user.{name,email}" command line options. I.e. the full command would become
> something like
> 
>       $ GIT_COMMITTER_NAME="Greg Chicares" address@hidden git am 
> --committer-date-is-author-date patch
                              ^^^^^^^^^^^^^ Gregory W. Chicares

Actually, the way Kim noticed the root cause was by retyping everything from
scratch and accidentally omitting her middle initial.

Alternatively:
  git -c "user.name=Gregory W. Chicares" -c"address@hidden" am ...
where the order of options is crucial ('git -c"xxx" am', not 'git am -c"xxx"').

If we do that...then how do we know whose patch it was? Answer: look at the
"author", which 'git log' normally prints; the committer doesn't matter to us.
So could we just set the "committer" to, say, "address@hidden"? Answer:
'git config' has 'user.name' and 'user.email' concepts that conflate "author"
and "committer", so there's no way to do
  git config commiter.name "address@hidden"
for this repository: we need to override it on a per-command basis.

Which command(s) in our workflow need this override? I suspect that only
'git am' does (though I'm not at all sure). Perhaps it would be better to
use a single "committer" for all commands at all times, so that no other
"committer" will appear in our logs going forward. But if we use it for all
commands, then '-c' is no good because there's no '-c "committer.name"'
option: to override only "committer", we must use the environment variables.

So how can we build that in?

 - A hook? 'git am' can run applypatch-msg, pre-applypatch, and post-applypatch,
and I guess 'pre-applypatch' sounds best. But if it actually runs a shell 
script,
then we have little chance of pushing GIT_COMMITTER_NAME into the calling
environment, and I'm not sure an alias can cleanly add a git-level '-c' option
(as opposed to a command-specific one that would mean (e.g.) '--scissors' for
'git am'.

 - An alias? I guess we could do something like this:
  git config alias.apply '-c "user.name=robot"' -c "address@hidden" am
Oops--no, "apply" is already a git command, so that would be ignored silently
(won't-fix: it's a feature). How about...
  git config alias.apply-email '-c "user.name=robot"' -c "address@hidden" am
Hmmm...can an alias supply a '-c' option that must come before the git command
'am'? Or do we need something like...
  git config alias.apply-email '!sh -c "git -c \"user.name=robot\" am \
    --committer-date-is-author-date \"$1\""'

I hope there's some tasteful way to do this, but it doesn't look like I'm
going to find it on my own. As a last resort, we can just write all these
options together as a specimen command in a "cheat sheet", and copy and
paste into the shell.