[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: |
Mon, 7 Mar 2016 19:34:49 +0100 |
On Mon, 7 Mar 2016 18:15:33 +0000 Greg Chicares <address@hidden> wrote:
GC> [Ideally, we would like to have a command to apply patches safely.
I'm afraid patches are just not meant to be used like this, they're, by
design, supposed to be applicable to (slightly) different versions of the
original sources than the one they were originally made against. I hesitate
to say this after all the time you've already spent devising this workflow,
especially because I think it should work perfectly well in practice, but I
think git bundles fit your needs better.
GC> In the case of 'first.patch' above, it would (1) check the HEAD sha1sum,
E.g. "git bundle verify" subcommand already does (1).
GC> and (2) determine whether applying the patch would result in the sha1sum
GC> given on the first line of the patch; then apply the patch only if both
GC> match, otherwise printing a diagnostic but making no change to the
GC> working copy. Perhaps (1) is the only meaningful check: if it succeeds,
GC> then it should be impossible for (2) to fail, though (2) should then be
GC> so easy that there's no reason not to do it. But git-generated patches
GC> don't provide the pre-commit HEAD; we'd have to do that ourselves.
GC> Alternatively, if condition (2) holds, then (1) is (probabilistically)
GC> guaranteed; but 'git apply --check' doesn't give the sha1sum that would
GC> result from applying the patch. Vadim, what do you think?]
I don't see any way to do this with just the standard git commands. It
would, of course, be possible to write a shell script taking a git patch
file, applying it, checking that the HEAD matches the SHA-1 in the patch
and reverting the changes if it doesn't and I could do it if you'd like (as
you could easily do too, of course).
But perhaps using bundles would be a better idea. The main disadvantage I
see with them is that they're not widely used, unlike patches. But the
advantage is that they're meant to address exactly this use case, while
patches are much more flexible than that and, while this is a good thing in
general, it makes them less appropriate for your needs here.
Regards,
VZ