Re: git: "git stash" changes owners and permissions

Re: git: "git stash" changes owners and permissions

[Jonathan Nieder]

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

Re: git: "git stash" changes owners and permissions

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> ...
> 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
>...
> 	# deploy.
> 	rsync -a --exclude='.git' /root/tmp/interesting-subdir/ .
> 	git reset jrn/proposed
> 	git diff;	# should show no changes.


How does this "rsync" solve "the wrong order" and "creates windows"
problems?  It will update the paths in the order rsync happens to discover
and there is a wondow between the time the first path is updated and the
whole directory gets finally in sync.

If you truly want an atomicity, you can make /etc/interesting-subdir a
symbolic link that points to either interesting-subdir-{0,1}, do the above
procedure of yours against interesting-subdir-0 (or 1) that is currently
not pointed by the symbolic link, and when everything in that one is Ok,
atomically switch the symbolic link to point at it.

Re: git: "git stash" changes owners and permissions

[Jonathan Nieder]

Junio C Hamano wrote:

> How does this "rsync" solve "the wrong order" and "creates windows"
> problems?  It will update the paths in the order rsync happens to discover
> and there is a wondow between the time the first path is updated and the
> whole directory gets finally in sync.

All true.  It's a little better than "git checkout" because rsync
will stage files and then rename them into place rather than leaving
a window with files unlinked[1], but it is not much better.

In fact the rsync was a misleading placeholder.  What I really meant
to convey is that this is not something "git checkout" and "git reset
--hard" are designed to do, and that when this much control is needed,
it can be easier to update files out-of-band.

> If you truly want an atomicity, you can make /etc/interesting-subdir a
> symbolic link that points to either interesting-subdir-{0,1}, do the above
> procedure of yours against interesting-subdir-0 (or 1) that is currently
> not pointed by the symbolic link, and when everything in that one is Ok,
> atomically switch the symbolic link to point at it.

True.  Though in practice, a little race might be considered ok. :)

Thanks for clarifying.
Jonathan

[1] rsync with --files-from can update files in a specific order,
which might be appropriate in some cases.