Re: [lmi] Proposed workflow for proprietary repository

[Greg Chicares]

On 2016-03-07 18:34, Vadim Zeitlin wrote:
> 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.

We need something soon, and the best is enemy of the good, so I'd like to
follow through and see how well patches work. Maybe the volume of work is
so low that patches will meet our needs well. Or maybe we'll find patches
so cumbersome that we'll be itching to use bundles instead.

Emailing git patches is still better than emailing svn patches (especially
because of the sha1sums), and emailing svn patches would have been a lot
better than what we were doing.

> 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).

Would you mind showing me how you'd do it? I'm still trying to learn git,
one command at a time, and I haven't really studied the commands that might
be used here. I'm not even sure which to use:
  git-revert (does it return us to the original sha1sum?)
or one of these--but I see many warnings that they're dangerous:
  git-checkout (but we don't want to create a branch--we want one trunk)
  git-reset --hard (and then git-push)
I guess we'd want git-reset in this case: we want to reload our last saved
game, as though we had never tried to "attack dragon with cursed spoon -9".

>  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.

Let me see if I can quickly figure out how to use bundles. But I'm going
to be hors de combat most of next week, and there's much that I need to
get done before then.