Re: git-reset HEAD --permissions-only

[Jeff King <peff@peff.net>]

On Tue, Mar 15, 2011 at 08:06:19PM -0500, Neal Kreitzinger wrote:

> You are right about git checkout -p because there are alot of code
> changes to alot of files.  I haven't used git patches and I don't
> know perl.  However, your reasoning about the last example seems the
> most straight-forward so I used it.  I symptomatically validated my
> re-keying of the syntax as follows since TTBOMK I couldn't copy+paste
> your example due to whitespace:
> 
> git ls-files -sz | perl -0ne '/100(\d+).*?\t(.*)/
>  or next; -e $2 or next; chmod(oct($1), $2) or die "chmod failed: $!";'

The whitespace in what I sent was fine, though it's possible your MUA
mangled it.

It sounds like the solution worked for you, so cool. But I did have one
more thought to mention: since you are working with a vendor branch, you
should be able to have a "pristine" vendor branch complete with their
wrong permissions, and then build your permissions fixes on top of that.
And then when you merge the pristine branch up to your branch, git will
automatically resolve the permissions in favor of yours (because its
built on top).

So something like:

  # import initial vendor branch
  git init
  # untar or whatever happens to get the files
  tar xzf /path/to/vendor-1.0.tar.gz
  git add .
  git commit -m 'import vendor 1.0'

  # now move it to vendor branch and make our munged-vendor branch
  git branch vendor
  git checkout -b vendor-fixed vendor

  # now tweak permissions
  .. chmod or however you did it originally ...
  git add -u
  git commit -m 'fix broken vendor permissions'

  # and then built your real work on top of vendor-fixed
  git branch -f master vendor-fixed
  git checkout master

  # weeks pass; vendor releases 1.1
  git checkout vendor
  # untar or whatever we do to get the files
  tar xzf /path/to/vendor-1.1.tar.gz
  git add -A
  git commit -m 'import vendor 1.1'

  # now we merge it in, but our permissions fixes will be retained
  git checkout vendor-fixed
  git merge vendor
  # however we may still have to deal with new files
  ... chmod or whatever on new files ...
  git add -u
  git commit -m 'fix more broken vendor permissions'

...and repeat for each new version the vendor releases.

That gives you three branches: vendor with the pristine vendor source,
vendor-fixed with any baseline fixes (permissions changes in this case),
and then your real work goes on master (or on topic branches that get
merged to master).

You could also omit the vendor-fixed branch and just put your fixes on
the master branch. Doing it with the third branch, though, means you
will have a less noisy diff doing "git diff master vendor-fixed", since
it will not include all the permissions mucking.

-Peff