[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Proposed workflow for proprietary repository
From: |
Greg Chicares |
Subject: |
Re: [lmi] Proposed workflow for proprietary repository |
Date: |
Fri, 11 Mar 2016 01:21:25 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 |
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.
- Re: [lmi] Proposed workflow for proprietary repository, (continued)
- Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/07
- Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/08
- Re: [lmi] Proposed workflow for proprietary repository, Murphy, Kimberly, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository, Vadim Zeitlin, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository, Vadim Zeitlin, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository,
Greg Chicares <=
- Re: [lmi] Proposed workflow for proprietary repository, Vadim Zeitlin, 2016/03/10
- Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/11
- Re: [lmi] Proposed workflow for proprietary repository, Vadim Zeitlin, 2016/03/11
Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/20