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: Greg Chicares
Subject: Re: [lmi] Proposed workflow for proprietary repository
Date: Thu, 10 Mar 2016 16:29:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 2016-03-10 14:17, Vadim Zeitlin wrote:
> On Thu, 10 Mar 2016 13:39:39 +0000 "Murphy, Kimberly" <address@hidden> wrote:
> 
> MK> Creating the first patched initially tripped me up; it failed:
> MK> 
> MK> /usr/bin[0]$cd /opt/lmi/proprietary
> MK> /opt/lmi/proprietary[0]$git rev-parse HEAD
> MK> b5f2b3d4cfd179bbe4ac433d5bbe86d922bec2dc
> MK> /opt/lmi/proprietary[0]$git am --committer-date-is-author-date \
> MK> >     /opt/lmi/proprietary-patches/in/first.patch
> MK> Patch format detection failed.
> 
>  The error message above is definitely unexpected. I initially thought that
> this file ("first.patch") got corrupted somehow, but checking its MD5 sum
> (thanks for providing it), it's the same here and the file looks fine

I wonder if this is the same problem I had when I tried to copy and paste
this patch from email: whitespace was mangled, so that neither git nor
/usr/bin/patch would recognize it (and this bad patch's md5sum wouldn't
match the one given below).

> MK> No issues on later tries, only different sha1sums:
> 
>  This is to be expected because the first patch hasn't been applied, but
> the second one was, so the history is now different and it will never
> converge to the original one again.
> 
>  You should run "git reset --hard b5f2b3d4cfd179bbe4ac433d5bbe86d922bec2dc"
> to return to the latest common revision and somehow convince "git am" to
> apply the first patch.
[...]
>  Notice that you will now have to use "git push origin +HEAD" the next time
> to force overwriting the (wrong) revisions in the bare repository with the
> correct ones.

Once we go into production with git, we'll use steps like those to
recover from problems that we hope won't occur anyway, and that we
further hope to forestall with hooks. It's useful to take those steps
now in this case, for practice.

Since this isn't in production yet, we can also resort to brute force
(and if this way doesn't work, then git must be seriously broken):

# Wipe the slate clean:
  rm -rf /opt/lmi/proprietary/
  rm -rf /opt/lmi/blessed/proprietary
  rm -rf /opt/lmi/proprietary-patches/in
  rm -rf /opt/lmi/proprietary-patches/out

# Initial setup:
  mkdir --parents /opt/lmi/proprietary-patches/in
  mkdir --parents /opt/lmi/proprietary-patches/out
  cd /opt/lmi
  tar -xjvf proprietary-blessed-repository.tar.bz2
  git clone file:///opt/lmi/blessed/proprietary

# Verify "b5f2b3d4cfd179bbe4ac433d5bbe86d922bec2dc" for both:
  cd /opt/lmi/blessed/proprietary; git rev-parse HEAD
  cd /opt/lmi/proprietary; git rev-parse HEAD

# Verify md5sums of patches--expect:
# 282eda2fc967af5ee5907445f5993129 *first.patch
# 08b126da53041705da07055894f39435 *0002-Replace-svn-with-git.patch

  cd /opt/lmi
  md5sum first.patch 0002-Replace-svn-with-git.patch

# Copy verified patches to incoming patch directory:

  cp -a first.patch 0002-Replace-svn-with-git.patch \
    /opt/lmi/proprietary-patches/in

# Apply both patches, expecting the sha1sums shown:

  cd /opt/lmi/proprietary
  git rev-parse HEAD
b5f2b3d4cfd179bbe4ac433d5bbe86d922bec2dc
  git am --committer-date-is-author-date \
    /opt/lmi/proprietary-patches/in/first.patch
  git rev-parse HEAD
5f876b0a61554fe59979ad7620ab61cc7dc0dd27
  git am --committer-date-is-author-date \
    /opt/lmi/proprietary-patches/in/0002-Replace-svn-with-git.patch
  git rev-parse HEAD
5e4e7fd8ab35a196cd1f5cc3c5b981c960664226




reply via email to

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