[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 15:38:59 +0100 |
On Fri, 11 Mar 2016 13:05:02 +0000 Greg Chicares <address@hidden> wrote:
GC> On 2016-03-11 01:49, Vadim Zeitlin wrote:
GC> > On Fri, 11 Mar 2016 01:21:25 +0000 Greg Chicares <address@hidden> wrote:
...
GC> > GC> So could we just set the "committer" to, say, "address@hidden"?
GC> >
GC> > Only if you always commit under robot identity as well.
GC>
GC> That's exactly what I had in mind:
GC> I would commit my changes as author Greg and as committer Robot.
GC> Kim " " her " " " Kim " " " " .
GC> Then we'd both apply email patches as committer Robot, respecting the
GC> author specified in the patch.
Ah, I see. This should indeed work too and might even make more sense in
this very special use case.
GC> But you bring up the question I meant to ask but forgot: if we just
GC> used git bundles, would these problems simply vanish?
Yes. As I wrote, bundles are just an alternative transport mechanism for
git commits replacing the usual pull (or fetch) and push commands. I've
never used git bundles in anger, but my understanding is that they are
exactly the solution to the precise problem of having multiple clones of
the same repository not accessible via network provided by Git.
GC> I don't actually care who the committer is; I just want the sha1sums to
GC> match.
FWIW I did think about what else could make them diverge and, to the best
of my knowledge, there is nothing else, i.e. to compute SHA-1 sums Git
uses:
0. The parent commit(s) SHA-1 hashes.
1. The previous tree SHA-1 hash.
2. The name, email and timestamp of the author.
3. The name, email and timestamp of the committer.
4. The commit message.
and nothing else. So if we can ensure that all of the above match, we will
get the same SHA-1, and so the patch-based workflow should work. But it
will remain more fragile.
GC> If we use git-format-patch and git-am, then faking the committer name
GC> is just a means to that end. OTOH, if bundles do exactly what we want--so
GC> that Kim's changes show her as both author and committer, and replaying her
GC> bundle on my machine gives the same sha1sum--then that's perfectly okay.
Yes, this should definitely work. As I already wrote, the main problem
with bundles from my point of view is that they're not used often and
people are much less familiar with them than with patches which are, at
least to me, more intuitive. But if you're writing out the commands to
copy-and-paste anyhow, I don't think it's that big of a disadvantage and
the bundles are a much better fit for the problem at hand.
Regards,
VZ
- Re: [lmi] Proposed workflow for proprietary repository, (continued)
- 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, 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/11
- Re: [lmi] Proposed workflow for proprietary repository,
Vadim Zeitlin <=
Re: [lmi] Proposed workflow for proprietary repository, Greg Chicares, 2016/03/20