Re: treating some directories atomically, and ignoring socket files
martin f krafft <[email protected]>
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <[email protected]> |
> The second is to treat VCS directories (such as .git or .svn)
> atomically; that is, all the changes under such a directory should
> be reconciled in the same direction, not merged.
I am not entirely sure this is a good solution. It's definitely
better than what currently happends when */.git/.. is encountered,
but I think it's a safe assumption that whenever there is a Git
repository, then Git will be the better tool to synchronise changes
between the two clones. In particular, if you "atomically" overwrite
one or the other, you are possibly destroying changes which Git
could have merged. And simply letting 'm' delegate to Git to do the
merging won't work either because (a) conflicts are hard to deal
with, and (b) it would only merge the checked-out branches.
So while I can envision other good uses for "atomic" (e.g. firefox
config directory), I don't think it's suitable for Git. I'd much
rather have the ability to instruct unison to ignore those
directories¹ and employ a tool such as myrepos to manage all Git
repos across my home directory.
¹) See https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11460,
although I've since reached the conclusion that having an implicit
and stringent "if .git then ignore" might not be what you want
either. Hence, I wrote
http://lists.seas.upenn.edu/pipermail/unison-hackers/2015-February/001806.html
and I think rsync-style filter files would be the most flexible
approach.
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
"zwei monologe, die sich gegenseitig
immer und immer wieder störend unterbrechen,
nennt man eine diskussion."
-- charles tschopp
spamtraps: [email protected]
_______________________________________________
Unison-hackers mailing list
[email protected]
http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
digital_signature_gpg.asc
(application/pgp-signature, 1.1 KB)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQLvBAEBCgDZBQJU0oVHwBEaaHR0cDovL21hcnRpbi1rcmFmZnQubmV0L2dwZy9z aWctcG9saWN5LzU1Yzk4ODJkOTk5YmJjYzQvMjAxMTAxMjQxMTI1P3NoYTUxMnN1 bT0xY2FkOTZmZDI3ZDMyMzNmNTNlMjI4NDk1MzM2NDgxMDdlNWVlOGQ1YmU2NTUy NTFkNzRjOGYxYzVjM2JjNDJmMjMwNGZhNTE1MTUwZjdiZDRkZDA1ZTk4MTk5MjRm MDQ5NTEzZWU5OTYyY2E3MTcwOWY4MWQ5NDUxNTg1MmJkOAAKCRBVyYgtmZu8xBlF D/0V22Vk7FZLodxQB/nSimnRU2p91Bh86/+CHnRMRmMgIBf1U1KWlINAttk3U/Ai cyisxdaG4OIkBwnw195XCK6ENrkzn8Bmz8K7TiJe7A/+Jcf4opnEl3vCtzHIoSWZ +5I3cnCQq2JxRBetTW7IHrNe4JvP/t32vZ00Oq0fZ6CKZD8i1TFwxAT89DdE45TE bqLRHluYvgEli3WzyBY7nDJcSQzHt6wi6QHEmoEVbxuIBJxHYTp1E4Yn8E6ujgom wS91spTly+SBBtbCNkXoS7qtRf645nka0VWlZaGBXX2/jhgU0VGQ1/LGZMuxijnD /JSvr0Jqaf1muC21HHDujJA4FJuva69AcFTLuCBj75lbaLiqjfi1IC88q8ucozi1 hYozlRm8as9/4A4xvQ/n0mRBRCTzaDb3l4kEJHHZvWZH4Scn7lRM1A0A/UD9VXIq 0LVFVol/bRtrdgeLU6TwYQwjnbU6CpgU/i95vhZw8we2JpseXNA5q1EuMm37WIZ+ rai07R7KPZ+OLB7/jiMAWdm6Uw9MBI3t2MvROTharwA/Q6ZM0MOQSZsrTnYAS5fs tBY2/duCo+80w0UkXoNruM49KJkZCESKhrmV0k4lHDGSAJEC2a2V15rrDJ5mhnk2 MbbNzj8Mg1oToW/ceam2yIYK6yVKFpu/51AzJDYrU26YEw== =5dC4 -----END PGP SIGNATURE-----