git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-reset HEAD --permissions-only

From
Jeff King <peff@peff.net>
Date
Mar 17, 2011, 06:01 UTC
Message-ID
<20110317060129.GC11931@sigill.intra.peff.net>
In-Reply-To
<4D800D0B.2000307@gmail.com>
On Tue, Mar 15, 2011 at 08:06:19PM -0500, Neal Kreitzinger wrote:
Show 9 quoted lines
> 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
Previous: Neal Kreitzinger
Message 4 of 4 in “git-reset HEAD --permissions-only”
  1. Neal KreitzingerMar 14, 2011
  2. Jeff KingMar 15, 2011
  3. Neal KreitzingerMar 16, 2011
  4. Jeff KingMar 17, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.