How to ignore a tracked file in git without deleting it?












1















My team uses sourcetree as our git client. There is a third-party plugin in our project. It needs several configuration files. These files cannot be generated automatically. They store account name, login tokens and some temporary options, which shouldn't be shared. But everyone still needs this file, otherwise it will report error. So now they always stay in our "uncommitted changes" section which is annoying.



I have 2 options:




  1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.


  2. See if there are tricks like "ignoring a tracked file without deleting it".



(Basically I feel if option 2 was possible, git should have some logic like "If local doesn't have this file, use remote version. If local has this file, ignore". The logic feels bad, easy to generate bugs.)










share|improve this question



























    1















    My team uses sourcetree as our git client. There is a third-party plugin in our project. It needs several configuration files. These files cannot be generated automatically. They store account name, login tokens and some temporary options, which shouldn't be shared. But everyone still needs this file, otherwise it will report error. So now they always stay in our "uncommitted changes" section which is annoying.



    I have 2 options:




    1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.


    2. See if there are tricks like "ignoring a tracked file without deleting it".



    (Basically I feel if option 2 was possible, git should have some logic like "If local doesn't have this file, use remote version. If local has this file, ignore". The logic feels bad, easy to generate bugs.)










    share|improve this question

























      1












      1








      1


      1






      My team uses sourcetree as our git client. There is a third-party plugin in our project. It needs several configuration files. These files cannot be generated automatically. They store account name, login tokens and some temporary options, which shouldn't be shared. But everyone still needs this file, otherwise it will report error. So now they always stay in our "uncommitted changes" section which is annoying.



      I have 2 options:




      1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.


      2. See if there are tricks like "ignoring a tracked file without deleting it".



      (Basically I feel if option 2 was possible, git should have some logic like "If local doesn't have this file, use remote version. If local has this file, ignore". The logic feels bad, easy to generate bugs.)










      share|improve this question














      My team uses sourcetree as our git client. There is a third-party plugin in our project. It needs several configuration files. These files cannot be generated automatically. They store account name, login tokens and some temporary options, which shouldn't be shared. But everyone still needs this file, otherwise it will report error. So now they always stay in our "uncommitted changes" section which is annoying.



      I have 2 options:




      1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.


      2. See if there are tricks like "ignoring a tracked file without deleting it".



      (Basically I feel if option 2 was possible, git should have some logic like "If local doesn't have this file, use remote version. If local has this file, ignore". The logic feels bad, easy to generate bugs.)







      git ignore sourcetree






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 22 at 22:28









      LizLiz

      62




      62






















          2 Answers
          2






          active

          oldest

          votes


















          1














          tl;dr




          • Technically your requirement is contradictory.


          • At a more philosophical level it (seems) to be a clash between open source and corporate philosophy.


          • Anyhow… I'll suggest some things that come to my mind



          Technically



          git either tracks or ignores a file.




          • Tracking is easi(est). Just do nothing…other than using git! And any file is tracked.

          • Ignoring is nearly as easy — just make sure it matches something in your gitignore file.

          • But you cant do both!!

          • Main caveat: Moving a file from tracked to ignored is somewhat non-trivial — simply adding the suitable pattern to gitignore wont cut it once tracked. The relevant


          Best Practice



          Dont start a git project without creating a proper




          • gitignore

            Also related

          • gitattributes


          So the first (and somewhat unrealistic)



          Suggestion 1




          • Start a new git project

          • Make proper gitignore and gitattribute files

          • Debug if necessary with git-check-ignore

          • Copy,add,commit your normal files

          • Copy, add, status the not-to-be-tracked files. Status should be clean


          But as I said this seems to be not quite what you want because you do want some kind of shared but untracked files.
          So you need to



          Untrack tracked files





          • Clean tip (simple but likely inadequate solution

          • filter branch

          • filter-branch

          • Better alternative to filter branch


          You actually want a git



          Post-Clone hook



          This is attempted here



          But is a bad idea as explained here



          Which brings me to the



          Philosophical difference




          • A corporate-enployer justifiably wants to control what/how its employee-programmers function. Which entails various kinds of machine control

          • A random open source software sitting on github that takes control of some other random person's machine is unethical and illegal.


          Therefore if you were a big fortune-500 player the natural option would be to fork git itself and add a post-clone hook feature in your fork



          A more reasonable and only slightly more inconvenient



          Solution 2




          • Write your own post-clone but manually callable script

          • … which does the requirement of copy if absent leave alone if present

          • And add a (manual) step to your team: (1) clone (2) call script

          • And dont forget the gitignore!!




          If this solution makes sense you may actually prefer



          Solution 3



          Invert the script-inside-git to git-inside-script



          ie ask your team to only download/copy and run a script that




          • Runs git clone

          • Checks for these other files' existence/propriety

          • Creates/downloads them if necessary (maybe from a source independent of your main repo)






          share|improve this answer

































            0
















            1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.




            If I'm reading your question correctly, and the files in question contain such things as authentication credentials and site- or developer-specific configuration settings, then this is the way to go.




            • If there is any chance that your git repo will ever be made accessible to outside or untrusted entities, then your authentication details should not be in it because they will be disclosed to anyone who clones the project. Even if the credentials have been removed at some future point, they'll still be available in the history.


            • Site-/developer-specific settings don't raise the security issues that authentication information does, but they will still cause issues if multiple sites or developers are involved because, even if you have a policy against committing/pushing changes to those files, it's just a matter of time before someone commits them and causes everyone else's settings to be changed (or spurious conflicts to be generated) the next time they pull. I have personal experience with this one, and it's a major, ongoing nuisance to deal with. In our case, some of the differences were development vs. production settings, as well as site-specific settings, and this caused repeated adverse effects for our production systems.



            One hacky workaround which I've seen several projects use is to make a sanitized copy of foo.cfg named foo.cfg.default, track foo.cfg.default in git, gitignore foo.cfg, and rely on the user to copy foo.cfg.default to foo.cfg after cloning and customize it (adding authentication credentials, personalized settings, etc.). In your case, since the config files are for a third-party plugin, this could work, since they're probably pretty stable. It's less effective in scenarios where foo.cfg.default will be frequently changing, since it then falls on the user to notice any changes and manually merge them into the local foo.cfg.






            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "3"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397199%2fhow-to-ignore-a-tracked-file-in-git-without-deleting-it%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              1














              tl;dr




              • Technically your requirement is contradictory.


              • At a more philosophical level it (seems) to be a clash between open source and corporate philosophy.


              • Anyhow… I'll suggest some things that come to my mind



              Technically



              git either tracks or ignores a file.




              • Tracking is easi(est). Just do nothing…other than using git! And any file is tracked.

              • Ignoring is nearly as easy — just make sure it matches something in your gitignore file.

              • But you cant do both!!

              • Main caveat: Moving a file from tracked to ignored is somewhat non-trivial — simply adding the suitable pattern to gitignore wont cut it once tracked. The relevant


              Best Practice



              Dont start a git project without creating a proper




              • gitignore

                Also related

              • gitattributes


              So the first (and somewhat unrealistic)



              Suggestion 1




              • Start a new git project

              • Make proper gitignore and gitattribute files

              • Debug if necessary with git-check-ignore

              • Copy,add,commit your normal files

              • Copy, add, status the not-to-be-tracked files. Status should be clean


              But as I said this seems to be not quite what you want because you do want some kind of shared but untracked files.
              So you need to



              Untrack tracked files





              • Clean tip (simple but likely inadequate solution

              • filter branch

              • filter-branch

              • Better alternative to filter branch


              You actually want a git



              Post-Clone hook



              This is attempted here



              But is a bad idea as explained here



              Which brings me to the



              Philosophical difference




              • A corporate-enployer justifiably wants to control what/how its employee-programmers function. Which entails various kinds of machine control

              • A random open source software sitting on github that takes control of some other random person's machine is unethical and illegal.


              Therefore if you were a big fortune-500 player the natural option would be to fork git itself and add a post-clone hook feature in your fork



              A more reasonable and only slightly more inconvenient



              Solution 2




              • Write your own post-clone but manually callable script

              • … which does the requirement of copy if absent leave alone if present

              • And add a (manual) step to your team: (1) clone (2) call script

              • And dont forget the gitignore!!




              If this solution makes sense you may actually prefer



              Solution 3



              Invert the script-inside-git to git-inside-script



              ie ask your team to only download/copy and run a script that




              • Runs git clone

              • Checks for these other files' existence/propriety

              • Creates/downloads them if necessary (maybe from a source independent of your main repo)






              share|improve this answer






























                1














                tl;dr




                • Technically your requirement is contradictory.


                • At a more philosophical level it (seems) to be a clash between open source and corporate philosophy.


                • Anyhow… I'll suggest some things that come to my mind



                Technically



                git either tracks or ignores a file.




                • Tracking is easi(est). Just do nothing…other than using git! And any file is tracked.

                • Ignoring is nearly as easy — just make sure it matches something in your gitignore file.

                • But you cant do both!!

                • Main caveat: Moving a file from tracked to ignored is somewhat non-trivial — simply adding the suitable pattern to gitignore wont cut it once tracked. The relevant


                Best Practice



                Dont start a git project without creating a proper




                • gitignore

                  Also related

                • gitattributes


                So the first (and somewhat unrealistic)



                Suggestion 1




                • Start a new git project

                • Make proper gitignore and gitattribute files

                • Debug if necessary with git-check-ignore

                • Copy,add,commit your normal files

                • Copy, add, status the not-to-be-tracked files. Status should be clean


                But as I said this seems to be not quite what you want because you do want some kind of shared but untracked files.
                So you need to



                Untrack tracked files





                • Clean tip (simple but likely inadequate solution

                • filter branch

                • filter-branch

                • Better alternative to filter branch


                You actually want a git



                Post-Clone hook



                This is attempted here



                But is a bad idea as explained here



                Which brings me to the



                Philosophical difference




                • A corporate-enployer justifiably wants to control what/how its employee-programmers function. Which entails various kinds of machine control

                • A random open source software sitting on github that takes control of some other random person's machine is unethical and illegal.


                Therefore if you were a big fortune-500 player the natural option would be to fork git itself and add a post-clone hook feature in your fork



                A more reasonable and only slightly more inconvenient



                Solution 2




                • Write your own post-clone but manually callable script

                • … which does the requirement of copy if absent leave alone if present

                • And add a (manual) step to your team: (1) clone (2) call script

                • And dont forget the gitignore!!




                If this solution makes sense you may actually prefer



                Solution 3



                Invert the script-inside-git to git-inside-script



                ie ask your team to only download/copy and run a script that




                • Runs git clone

                • Checks for these other files' existence/propriety

                • Creates/downloads them if necessary (maybe from a source independent of your main repo)






                share|improve this answer




























                  1












                  1








                  1







                  tl;dr




                  • Technically your requirement is contradictory.


                  • At a more philosophical level it (seems) to be a clash between open source and corporate philosophy.


                  • Anyhow… I'll suggest some things that come to my mind



                  Technically



                  git either tracks or ignores a file.




                  • Tracking is easi(est). Just do nothing…other than using git! And any file is tracked.

                  • Ignoring is nearly as easy — just make sure it matches something in your gitignore file.

                  • But you cant do both!!

                  • Main caveat: Moving a file from tracked to ignored is somewhat non-trivial — simply adding the suitable pattern to gitignore wont cut it once tracked. The relevant


                  Best Practice



                  Dont start a git project without creating a proper




                  • gitignore

                    Also related

                  • gitattributes


                  So the first (and somewhat unrealistic)



                  Suggestion 1




                  • Start a new git project

                  • Make proper gitignore and gitattribute files

                  • Debug if necessary with git-check-ignore

                  • Copy,add,commit your normal files

                  • Copy, add, status the not-to-be-tracked files. Status should be clean


                  But as I said this seems to be not quite what you want because you do want some kind of shared but untracked files.
                  So you need to



                  Untrack tracked files





                  • Clean tip (simple but likely inadequate solution

                  • filter branch

                  • filter-branch

                  • Better alternative to filter branch


                  You actually want a git



                  Post-Clone hook



                  This is attempted here



                  But is a bad idea as explained here



                  Which brings me to the



                  Philosophical difference




                  • A corporate-enployer justifiably wants to control what/how its employee-programmers function. Which entails various kinds of machine control

                  • A random open source software sitting on github that takes control of some other random person's machine is unethical and illegal.


                  Therefore if you were a big fortune-500 player the natural option would be to fork git itself and add a post-clone hook feature in your fork



                  A more reasonable and only slightly more inconvenient



                  Solution 2




                  • Write your own post-clone but manually callable script

                  • … which does the requirement of copy if absent leave alone if present

                  • And add a (manual) step to your team: (1) clone (2) call script

                  • And dont forget the gitignore!!




                  If this solution makes sense you may actually prefer



                  Solution 3



                  Invert the script-inside-git to git-inside-script



                  ie ask your team to only download/copy and run a script that




                  • Runs git clone

                  • Checks for these other files' existence/propriety

                  • Creates/downloads them if necessary (maybe from a source independent of your main repo)






                  share|improve this answer















                  tl;dr




                  • Technically your requirement is contradictory.


                  • At a more philosophical level it (seems) to be a clash between open source and corporate philosophy.


                  • Anyhow… I'll suggest some things that come to my mind



                  Technically



                  git either tracks or ignores a file.




                  • Tracking is easi(est). Just do nothing…other than using git! And any file is tracked.

                  • Ignoring is nearly as easy — just make sure it matches something in your gitignore file.

                  • But you cant do both!!

                  • Main caveat: Moving a file from tracked to ignored is somewhat non-trivial — simply adding the suitable pattern to gitignore wont cut it once tracked. The relevant


                  Best Practice



                  Dont start a git project without creating a proper




                  • gitignore

                    Also related

                  • gitattributes


                  So the first (and somewhat unrealistic)



                  Suggestion 1




                  • Start a new git project

                  • Make proper gitignore and gitattribute files

                  • Debug if necessary with git-check-ignore

                  • Copy,add,commit your normal files

                  • Copy, add, status the not-to-be-tracked files. Status should be clean


                  But as I said this seems to be not quite what you want because you do want some kind of shared but untracked files.
                  So you need to



                  Untrack tracked files





                  • Clean tip (simple but likely inadequate solution

                  • filter branch

                  • filter-branch

                  • Better alternative to filter branch


                  You actually want a git



                  Post-Clone hook



                  This is attempted here



                  But is a bad idea as explained here



                  Which brings me to the



                  Philosophical difference




                  • A corporate-enployer justifiably wants to control what/how its employee-programmers function. Which entails various kinds of machine control

                  • A random open source software sitting on github that takes control of some other random person's machine is unethical and illegal.


                  Therefore if you were a big fortune-500 player the natural option would be to fork git itself and add a post-clone hook feature in your fork



                  A more reasonable and only slightly more inconvenient



                  Solution 2




                  • Write your own post-clone but manually callable script

                  • … which does the requirement of copy if absent leave alone if present

                  • And add a (manual) step to your team: (1) clone (2) call script

                  • And dont forget the gitignore!!




                  If this solution makes sense you may actually prefer



                  Solution 3



                  Invert the script-inside-git to git-inside-script



                  ie ask your team to only download/copy and run a script that




                  • Runs git clone

                  • Checks for these other files' existence/propriety

                  • Creates/downloads them if necessary (maybe from a source independent of your main repo)







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Feb 17 at 7:26

























                  answered Feb 17 at 7:09









                  RusiRusi

                  1112




                  1112

























                      0
















                      1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.




                      If I'm reading your question correctly, and the files in question contain such things as authentication credentials and site- or developer-specific configuration settings, then this is the way to go.




                      • If there is any chance that your git repo will ever be made accessible to outside or untrusted entities, then your authentication details should not be in it because they will be disclosed to anyone who clones the project. Even if the credentials have been removed at some future point, they'll still be available in the history.


                      • Site-/developer-specific settings don't raise the security issues that authentication information does, but they will still cause issues if multiple sites or developers are involved because, even if you have a policy against committing/pushing changes to those files, it's just a matter of time before someone commits them and causes everyone else's settings to be changed (or spurious conflicts to be generated) the next time they pull. I have personal experience with this one, and it's a major, ongoing nuisance to deal with. In our case, some of the differences were development vs. production settings, as well as site-specific settings, and this caused repeated adverse effects for our production systems.



                      One hacky workaround which I've seen several projects use is to make a sanitized copy of foo.cfg named foo.cfg.default, track foo.cfg.default in git, gitignore foo.cfg, and rely on the user to copy foo.cfg.default to foo.cfg after cloning and customize it (adding authentication credentials, personalized settings, etc.). In your case, since the config files are for a third-party plugin, this could work, since they're probably pretty stable. It's less effective in scenarios where foo.cfg.default will be frequently changing, since it then falls on the user to notice any changes and manually merge them into the local foo.cfg.






                      share|improve this answer




























                        0
















                        1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.




                        If I'm reading your question correctly, and the files in question contain such things as authentication credentials and site- or developer-specific configuration settings, then this is the way to go.




                        • If there is any chance that your git repo will ever be made accessible to outside or untrusted entities, then your authentication details should not be in it because they will be disclosed to anyone who clones the project. Even if the credentials have been removed at some future point, they'll still be available in the history.


                        • Site-/developer-specific settings don't raise the security issues that authentication information does, but they will still cause issues if multiple sites or developers are involved because, even if you have a policy against committing/pushing changes to those files, it's just a matter of time before someone commits them and causes everyone else's settings to be changed (or spurious conflicts to be generated) the next time they pull. I have personal experience with this one, and it's a major, ongoing nuisance to deal with. In our case, some of the differences were development vs. production settings, as well as site-specific settings, and this caused repeated adverse effects for our production systems.



                        One hacky workaround which I've seen several projects use is to make a sanitized copy of foo.cfg named foo.cfg.default, track foo.cfg.default in git, gitignore foo.cfg, and rely on the user to copy foo.cfg.default to foo.cfg after cloning and customize it (adding authentication credentials, personalized settings, etc.). In your case, since the config files are for a third-party plugin, this could work, since they're probably pretty stable. It's less effective in scenarios where foo.cfg.default will be frequently changing, since it then falls on the user to notice any changes and manually merge them into the local foo.cfg.






                        share|improve this answer


























                          0












                          0








                          0









                          1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.




                          If I'm reading your question correctly, and the files in question contain such things as authentication credentials and site- or developer-specific configuration settings, then this is the way to go.




                          • If there is any chance that your git repo will ever be made accessible to outside or untrusted entities, then your authentication details should not be in it because they will be disclosed to anyone who clones the project. Even if the credentials have been removed at some future point, they'll still be available in the history.


                          • Site-/developer-specific settings don't raise the security issues that authentication information does, but they will still cause issues if multiple sites or developers are involved because, even if you have a policy against committing/pushing changes to those files, it's just a matter of time before someone commits them and causes everyone else's settings to be changed (or spurious conflicts to be generated) the next time they pull. I have personal experience with this one, and it's a major, ongoing nuisance to deal with. In our case, some of the differences were development vs. production settings, as well as site-specific settings, and this caused repeated adverse effects for our production systems.



                          One hacky workaround which I've seen several projects use is to make a sanitized copy of foo.cfg named foo.cfg.default, track foo.cfg.default in git, gitignore foo.cfg, and rely on the user to copy foo.cfg.default to foo.cfg after cloning and customize it (adding authentication credentials, personalized settings, etc.). In your case, since the config files are for a third-party plugin, this could work, since they're probably pretty stable. It's less effective in scenarios where foo.cfg.default will be frequently changing, since it then falls on the user to notice any changes and manually merge them into the local foo.cfg.






                          share|improve this answer















                          1. Remove these files from git repository. Add them into .gitignore. Ask all my team members to add these files back to their local project with their own settings.




                          If I'm reading your question correctly, and the files in question contain such things as authentication credentials and site- or developer-specific configuration settings, then this is the way to go.




                          • If there is any chance that your git repo will ever be made accessible to outside or untrusted entities, then your authentication details should not be in it because they will be disclosed to anyone who clones the project. Even if the credentials have been removed at some future point, they'll still be available in the history.


                          • Site-/developer-specific settings don't raise the security issues that authentication information does, but they will still cause issues if multiple sites or developers are involved because, even if you have a policy against committing/pushing changes to those files, it's just a matter of time before someone commits them and causes everyone else's settings to be changed (or spurious conflicts to be generated) the next time they pull. I have personal experience with this one, and it's a major, ongoing nuisance to deal with. In our case, some of the differences were development vs. production settings, as well as site-specific settings, and this caused repeated adverse effects for our production systems.



                          One hacky workaround which I've seen several projects use is to make a sanitized copy of foo.cfg named foo.cfg.default, track foo.cfg.default in git, gitignore foo.cfg, and rely on the user to copy foo.cfg.default to foo.cfg after cloning and customize it (adding authentication credentials, personalized settings, etc.). In your case, since the config files are for a third-party plugin, this could work, since they're probably pretty stable. It's less effective in scenarios where foo.cfg.default will be frequently changing, since it then falls on the user to notice any changes and manually merge them into the local foo.cfg.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Feb 17 at 8:37









                          Dave SherohmanDave Sherohman

                          4,35911529




                          4,35911529






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Super User!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397199%2fhow-to-ignore-a-tracked-file-in-git-without-deleting-it%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Plaza Victoria

                              Puebla de Zaragoza

                              Musa