Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-01-23 22:24, Torsten Bögershausen wrote: > [...] either to always switch off SANITY for CYGWIN (or Windows in general). Nice one! You gave me the chuckle for the day ;-) Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull not ignoring the file which has been sent to the temporary ignore list
On Sat, Jan 24, 2015 at 10:20:46AM +0630, Arup Rakshit wrote: > On Friday, January 23, 2015 01:14:03 PM you wrote: > > [..] > > There are some configuration files, like `database.yml`, where we > generally put our local DB credentials and we don't want to share such > things. That's why we always put related settings inside the > .gitignore file. But while I will change it, git will not track the > changes of the file, but .gitignore. That's why I used the first > thread command. But when the time the came to take a `git pull`, I got > to know about the mess. What should be the ideal decision in this case > ? > In an ideal sittuation, configuration data is not stored inside git, because this would tie the code only to one environment. So what you would store in git is a template of the configuration data, that can be used to create the actual config file that is used. This way, you don't have any problems with having to change tracked files only for you local environment. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Finanzierung Angebot
Hallo Ich finanzieren alle Großprojekt und ich gewähre Darlehen mit 3 % Zinsen. Bitte schreiben Sie mir um einen Kredit zu beantragen E-Mail: lock.ka...@yahoo.com Herzliche Grüße. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Finanzierung Angebot
Hallo Ich finanzieren alle Großprojekt und ich gewähre Darlehen mit 3 % Zinsen. Bitte schreiben Sie mir um einen Kredit zu beantragen E-Mail: lock.ka...@yahoo.com Herzliche Grüße. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Finanzierung Angebot
Hallo Ich finanzieren alle Großprojekt und ich gewähre Darlehen mit 3 % Zinsen. Bitte schreiben Sie mir um einen Kredit zu beantragen E-Mail: lock.ka...@yahoo.com Herzliche Grüße. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-new-workdir: support submodules
} Or one new-workdir checkout's branch may check out a top-level } project from today while the other one may have a top-level project } from two years ago, This is also true, but just as much a problem with the 'git new-workdir' script as it existed before my change. It already symlinks the top-level .git/config directory, which lists a remote, submodules, and many other things. Does symlinking the config file for submodules add any new wrinkles, that symlinking the config file for the top-level repository does not? craig On Fri, Jan 23, 2015 at 5:37 PM, Junio C Hamano wrote: > Craig Silverstein writes: > Doesn't a submodule checkout keep some state tied to the working tree in its repository configuration file? >>> >>> Do you mean, in 'config' itself? If so, I don't see it. (Though it's >>> possible there are ways to use submodules that do keep working-tree >>> state in the config file, and we just happen not to use those ways.) >>> Here's what my webapp/.git/modules/khan-exercises/config looks like: >>> --- >>> [core] >>> repositoryformatversion = 0 >>> filemode = true >>> bare = false >>> logallrefupdates = true >>> worktree = ../../../khan-exercises >>> [remote "origin"] >>> url = http://github.com/Khan/khan-exercises.git >>> fetch = +refs/heads/*:refs/remotes/origin/* >>> [branch "master"] >>> remote = origin >>> merge = refs/heads/master >>> rebase = true >>> [submodule "test/qunit"] >>> url = https://github.com/jquery/qunit.git >>> -- >>> >>> The only thing that seems vaguely working-tree related is the >>> 'worktree' field, which is the field that motivated me to set up my >>> patch the way it is. > > That is the location of the working tree of the top-level > superproject. Tied to the state of the submodule working tree > appear in [submodule "test/qunit"] part. > > In one new-workdir checkout, that submodule may be "submodule > init"ed, while another one, it may not be. > > Or one new-workdir checkout's branch may check out a top-level > project from today while the other one may have a top-level project > from two years ago, and between these two checkouts of the top-level > project, the settings of submodule."test/qunit".* variables may have > to be different (perhaps even URL may have to point at two different > repositories, one historical one to grab the state two years ago, > the other current one). > > So sharing config between top-level checkouts may not be enough to > "support submodules" (the patch title). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html