lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Proposed workflow for proprietary repository


From: Vadim Zeitlin
Subject: Re: [lmi] Proposed workflow for proprietary repository
Date: Fri, 11 Mar 2016 02:49:39 +0100

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.

GC> Which command(s) in our workflow need this override? I suspect that only
GC> 'git am' does

 Yes.

GC> So how can we build that in?
GC> 
GC>  - A hook? 'git am' can run applypatch-msg, pre-applypatch, and
GC> post-applypatch, and I guess 'pre-applypatch' sounds best.

 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. It could be called git-replay-patch and executed as a git command,
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)?

 Please let me know,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]