From: Jonathan Nieder <jrnieder@gmail.com>
To: Axel Beckert <abe@debian.org>
Cc: git@vger.kernel.org
Subject: Re: git: "git stash" changes owners and permissions
Date: Wed, 6 Apr 2011 15:52:12 -0500 [thread overview]
Message-ID: <20110406205212.GC1922@elie> (raw)
In-Reply-To: <20110406200640.GF12557@sym.noone.org>
(moving to the git list)
Axel Beckert wrote[0]:
> I should probably look again for plugins or hooks taking care of file
> meta-data, but the last time I looked for such a thing, the stuff I
> found wasn't very promising. Any tips and hints are appreciated.
Everything I know about metadata tracking is at [1]. Which is to say,
I don't know much. I believe the state of the art involves saving
scripts to store metadata along with the repository, as in Dan
Jacobson's git-cache-meta script and etckeeper's pre-commit.d
directory[2]. [3]
As mentioned before, I don't advise using git to deploy changed files.
It will change them in the wrong order and creates windows when they're
not present. Perhaps a procedure like the following can work?
cd /root; (umask 077 && mkdir tmp); cd tmp
git clone /etc/interesting-subdir
cd interesting-subdir
... hack hack hack ...
git commit
... is it really ok? check in whatever way I know ...
# yes, it's okay.
git push /etc/interesting-subdir/.git HEAD:refs/remotes/jrn/proposed
cd /etc/interesting-subdir
git diff jrn/proposed; # one final check
# deploy.
rsync -a --exclude='.git' /root/tmp/interesting-subdir/ .
git reset jrn/proposed
git diff; # should show no changes.
# clean up.
rm -r /root/tmp/interesting-subdir
rmdir /root/tmp
Please keep us posted --- it would be nice to put whatever workflow
you end up with in a howto for distribution with git.
Regards,
Jonathan
[0] http://bugs.debian.org/621090
[1] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Backups.2C_metadata.2C_and_large_files
[2] http://git.kitenet.net/?p=etckeeper.git;a=tree;f=pre-commit.d;hb=master
[3] It is as though we were in the days of shar as an archival format.
In the long term I will be happier if something pleasant based on
.gitattributes appears. ;-)
next parent reply other threads:[~2011-04-06 20:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <878vvnfp60.fsf@kiva6.ethz.ch>
[not found] ` <20110406184938.GE1220@elie>
[not found] ` <20110406200640.GF12557@sym.noone.org>
2011-04-06 20:52 ` Jonathan Nieder [this message]
2011-04-06 21:48 ` git: "git stash" changes owners and permissions Junio C Hamano
2011-04-06 22:12 ` Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110406205212.GC1922@elie \
--to=jrnieder@gmail.com \
--cc=abe@debian.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.