Re: [lmi] Proposed workflow for proprietary repository

[Greg Chicares]

On 2016-03-11 01:49, Vadim Zeitlin wrote:
> On Fri, 11 Mar 2016 01:21:25 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> If we do that...then how do we know whose patch it was? Answer: look at 
> the
> GC> "author", which 'git log' normally prints; the committer doesn't matter 
> to us.
> 
>  But the committer will be the same as the author anyhow. I think there
> might have been some confusion, so just to be clear, and sorry if I'm just
> repeating something you're already well aware of: what matters here is that
> the committer is the same for both the original commit and the one being
> recreated from the patch. As the committer of the commit is always going to
> be the same as its author, the committer when applying the patch will need
> to be set depending on the original author, there is no way around it.
> 
> GC> So could we just set the "committer" to, say, "address@hidden"?
> 
>  Only if you always commit under robot identity as well.

That's exactly what I had in mind:
  I would commit my changes as author Greg and as committer Robot.
  Kim "      "  her   "       "   "   Kim   "   "     "       "  .
Then we'd both apply email patches as committer Robot, respecting the
author specified in the patch.

> GC> So how can we build that in?
> GC> 
> GC>  - A hook?
[...]
>  Unfortunately I don't think it can do what we need.
> 
> GC>  - An alias?
> 
>  This wouldn't be flexible enough to figure out the correct committer to
> use.
> 
> GC> I hope there's some tasteful way to do this, but it doesn't look like I'm
> GC> going to find it on my own. As a last resort, we can just write all these
> GC> options together as a specimen command in a "cheat sheet", and copy and
> GC> paste into the shell.
> 
>   Not to be awfully pessimistic, but I'm afraid it's going to be even worse
> than this because you seem to be only looking for a way to use a hardcoded
> committer value while we need to use a different value depending on the
> patch.
> 
>  The only way to make this work I see is to write a shell script doing
> this.

I was so focused on solving the problem inside git that I didn't think of
stepping outside and writing a shell script. That's much better.

> It could be called git-replay-patch and executed as a git command,

How would that be done? As an alias that invokes the external shell script?
Oh, wait...

http://stackoverflow.com/questions/1309430/how-to-embed-bash-script-directly-inside-a-git-alias
| I couldn't find in documentation, but if you create a script "git-<name>"
| in path, you can call it with "git name" in your repo.

> i.e. "git replay-patch /path/to/file.patch" and could take care of setting
> the committer correctly, calling "git am" with the correct option and even
> verifying that the patch is being applied to the correct SHA-1 sum (which
> was half of the checks that you wanted to do).
> 
>  It really seems like the best way to me, other than using bundles. Should
> I write such a script (tomorrow)?

It sounds simple enough that it's probably better for me to try to write it
and ask for your review. But you bring up the question I meant to ask but
forgot: if we just used git bundles, would these problems simply vanish?
I don't actually care who the committer is; I just want the sha1sums to
match. If we use git-format-patch and git-am, then faking the committer name
is just a means to that end. OTOH, if bundles do exactly what we want--so
that Kim's changes show her as both author and committer, and replaying her
bundle on my machine gives the same sha1sum--then that's perfectly okay.