I see another crux of the problem. There is currently no way to transfer/share repository configuration between clones. (Or is there? Could this be done with attributes? Probably not...) This is a bit awkward. Are there any plans to provide such functionality? Pros/cons? (It should be limited in scope of course, to provide adequate security for all parties involved.) Thanks for sharing your opinion, b. PS: For those that did not follow this small thread, here is an example use case to illustrate the problem: 1. I patch git to support custom filename for .gitignore 2. I reconfigure it in my repository clone (i.e. change it to look for .gitexclude files) 2a. This is configured in .git/config, for example as core.excludesDefaultFilename 3. I can commit changes to repository code, namely a change which renames .gitignore(s) to .gitexclude(s) (which restores correct exclusion pattern parsing) 4. When I push, only .gitignore rename to .gitexclude goes upstream. Info about required usage of .gitexclude instead of .gitignore stays in my repo clone. 5. When someone pulls, they have messed up "git status" output until they manually set the same setting in their repo clone (using .gitexclude instead of .gitignore) On 31 August 2014 03:55, Bostjan Skufca <bostjan@xxxxxx> wrote: > Hi Jonathan, > > nope, haven't seen zit before, it does partly what I would need, but > just for one file at a time (a "bit" awkward) and not really portable > (git clone will not clone .FILE.git/exclude, for example). > > Anyway, do you think that a patch which makes .gitignore filename > configurable would be appropriate for inclusion in future git > releases? > > b. > > > > On 30 August 2014 07:43, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Hi, >> >> Bostjan Skufca wrote: >> >>> Git is great for tracking code development, but when deploying >>> mentioned code by using git itself, various configuration files must >>> be created additionally, which are normally .gitignored, for various >>> reasons (code portability, sensitive data, etc). There is currently no >>> simple way of tracking changes to those critical configuration files >>> (at least none that I am aware of). >>> >>> One way to approach this would be tracking those changes in separate >>> git repository. >> >> Have you seen zit >> <https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Zit>? >> >> Curious, >> Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html