Re: [RFC/PATCH 1/2] config: Add safe-include directive
Junio C Hamano gits...@pobox.com wrote: (by the way, we do not do dashes in names for configuration by convention) OK. Actually, I now think I'd prefer a subsection [include safe], but I don't have any strong preferences regarding the names. That syntax _could_ be just a relative path (e.g. project.gitconfig names the file with that name at the top-level of the working tree), and if we are to do so, we should forbid any relative path that escapes from the working tree (e.g. ../project.gitconfig is forbidden, but down/down/../../.gitconfig could be OK as it is the same as .gitconfig). For that matter, anything with /./ and /../ in it can safely be forbidden without losing functionality. I agree that it would be most useful to interpret relative paths as being relative to the working tree. I'm not sure what would be gained by checking for ./ and ../ components, a symlink could easily be used to circumvent that. And we can allow absolute path, e.g. /etc/gitconfig, of course, but I'd prefer to at least initially forbid an absolute path, due to the same worries I have against the unset some variables defined in /etc/gitconfig topic we discussed earlier today in a separate thread. One might (ab)use the feature to only use some settings from a global file, e.g. [include safe] whitelist = !foo.* path = ~/extra.gitconfig But I'm fine with forbidding absolute paths until someone actually comes with such a use case. Another design decision we would need to make is if it should be allowed for a safe-included file to use safe-include directive to include other files. Offhand I do not think of a reason we absolutely need to support it, but there may be an interesting workflow enabled if we did so. I dunno. After one level of safe-include, any safe-include can also be done as a normal include (but one may need to spell the path differently if the two included files are not both at the top of the working tree). One could imagine a project supplying lots of defaults and splitting those into separate files, each included from a single project.gitconfig. Anyway, my proposal allows nesting includes and safe-includes inside safe-includes; forbidding it would just be a matter of adding a safe_include_depth == 0 check in two places. (Then safe_include_depth probably could/should be renamed in_safe_include.) I think I have a slight preference to allowing nested includes, but if absolute paths are forbidden for safe-includes, they should also be forbidden for include-inside-safe-include. Rasmus -- 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
Kedves Email felhasználói
Kedves Email felhasználói Túllépte 23.432 doboz állította be Web Services / menedzser, és akkor lesz probléma küldő és e-mailt kap, míg újra ellenőrizni. Frissítenie kell Kattintson hivatkozásra, és az alábbi információkat, hogy ellenőrizze a számla Kérjük, kattintson az alábbi linkre, vagy másolja a böngészőben jelölőnégyzetet. http://mailupdattw245t.jigsy.com/ Figyelem! Ellenkező esetben, akkor csak korlátozottan férnek hozzá az e-mail postaládájába. igen a Tudod frissíteni a számla számított három napon belül frissítések kommunikáció Fiókját zárva lesz tartósan. Üdvözlettel, ® System Manager -- 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: [RFC/PATCH 1/2] config: Add safe-include directive
Rasmus Villemoes r...@rasmusvillemoes.dk writes: Junio C Hamano gits...@pobox.com wrote: (by the way, we do not do dashes in names for configuration by convention) OK. Actually, I now think I'd prefer a subsection [include safe], but I don't have any strong preferences regarding the names. I think Peff mentioned something about having the second level between include and path, so I'll defer it to him. That syntax _could_ be just a relative path (e.g. project.gitconfig names the file with that name at the top-level of the working tree), and if we are to do so, we should forbid any relative path that escapes from the working tree (e.g. ../project.gitconfig is forbidden, but down/down/../../.gitconfig could be OK as it is the same as .gitconfig). For that matter, anything with /./ and /../ in it can safely be forbidden without losing functionality. I agree that it would be most useful to interpret relative paths as being relative to the working tree. I'm not sure what would be gained by checking for ./ and ../ components, a symlink could easily be used to circumvent that. If the limit to the the working tree is the reason to suggest a relative path to be taken as relative to the working tree, which my suggestion clearly was, the reader should be intelligent enough to infer that an implementation working in that mode should make sure symlinks and any other means do not step outside it. And as you noticed that, you apparently are ;-) One might (ab)use the feature to only use some settings from a global file, e.g. [include safe] whitelist = !foo.* path = ~/extra.gitconfig You do not have to write something you do not want to use in your own ~/extra.gitconfig that is under your $HOME/, so I'd prefer to explicitly forbidding such a use case at least in the beginning. -- 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: Can I fetch an arbitrary commit by sha1?
On Thu, Oct 2, 2014 at 12:10 PM, Jeff King p...@peff.net wrote: On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote: My understanding is that you are allowed to ask for a SHA1, but most git servers refuse the request. But if you already have the SHA locally, then git doesn't neet to bother asking the server for it, so there's no request to be refused. That's right. It is the server which enforces the you cannot fetch an arbitrary sha1 rule. But I think Christian is arguing that the client side should complain that $sha1 is not a remote ref, and therefore not something we can fetch. This used to be the behavior until 6e7b66e (fetch: fetch objects by their exact SHA-1 object names, 2013-01-29). The idea there is that some refs may be kept hidden from the ref advertisement, but clients who learn about the sha1 out-of-band may fetch the tips of hidden refs. I'm not sure it is a feature that has been particularly well-used to date, though. There are efforts in the scientific communities at preserving experimental software and results. One of the things we'd like to do is shallow clone a specific sha1 commit from e.g. GitHub. [I think GitHub has this disabled though? I haven't been able to get it to work.] I guess this feature was a step in the right direction but it's not usable AFAIK. Tags are not really suitable as they could change and there are possible namespace issues. -- Patrick Donnelly -- 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: Can I fetch an arbitrary commit by sha1?
On Mon, 6 Oct 2014, Patrick Donnelly wrote: There are efforts in the scientific communities at preserving experimental software and results. One of the things we'd like to do is shallow clone a specific sha1 commit from e.g. GitHub. [I think GitHub has this disabled though? I haven't been able to get it to work.] I guess this feature was a step in the right direction but it's not usable AFAIK. Tags are not really suitable as they could change and there are possible namespace issues. remember that git != github and it's not hard to run your own git server. if you sign tags, they should be very stable. You do have the namespace issue, but unless you have a lot of different people tagging in the same repository, that shouldn't be an issue (and if you do, can't you use the person's name as part of the tag?) David Lang -- 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: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
Am 06.10.2014 um 07:17 schrieb Marat Radchenko: On Tue, Sep 30, 2014 at 11:02:29AM +0400, Marat Radchenko wrote: This patch series fixes building on modern MinGW and MinGW-W64 (including x86_64!). Junio, ping? Sorry, I forgot to report that this updated series works now for me. The patches all look reasonable. I don't have an opinion on the restriction that MSVC 2010 can't be used anymore (path 08/14). -- Hannes -- 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/RFC 5/5] add tests for checking the behaviour of unset.variable
On 10/4/2014 1:42 AM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Well, the normal use-case for unset.variable is to put it in a local config file, to unset a variable set in another, lower-priority file. I agree that is one major use case. This common use-case works with the command-line git config, and it would be a pity to forbid the common use-case because of a particular, unusual case. Either you are being incoherent or I am not reading you right. If you said If this common use-case worked with the command-line 'git config', it would be nice, but it would be a pity because it does not, I would understand. I think you missed the another in my sentence above. The normal use-case is to have foo.bar and unset.variable=foo.bar in different files. In this case, you do not care about the position in file. I didn't miss anything. The reason you want to have unset foo.bar in your .git/config is to override a foo.bar = z you have in another place, e.g. ~/.gitconfig; which would let you sanely do another foo.bar = x in .git/config for multi-value foo.bar, *if* the unset comes before foo.bar. But what if you have this in your .git/config file [core] bare = false ... standard stuff left by git init ... [foo] bar = x before you add unset foo.bar there? And that is not a contribed example. The likely reason why you want to resort to unset foo.bar is that you found that you get an unwanted foo.bar=z in addition to desired foo.bar=z in a repository that has the above in .git/config, and at that point you would want to say I want to unset the outside influence. And there is no [unset] variable = foo.bar in there yet; without some special casing, if you treated unset.variable as if it were just another ordinary variable, it would go after you define your own foo.bar=x, which is not what you want. I have made some conclusions after reading the whole thread, 1 Add some tests for this use case which seems the most appropriate use case for this feature, (Copied from Junio's mail) - Define [xyzzy] frotz 1 in $HOME/.gitconfig (I think $HOME defaults to your trash directory). - Verify that git config xyzzy.frotz gives 1. - Define [unset] variable = xyzzy.frotz in .git/config (it is OK to use git config unset.variable xyzzy.frotz here). - Verify that git config xyzzy.frotz does not find anything. - Define [xyzzy] frotz 2 in .git/config (again, it is OK to use git config xyzzy.frotz 2 here). - Verify that git config xyzzy.frotz gives 2. 2 Leave the internal implementation as it is, as it helps in manually writing unset.variable in its appropriate place by using an editor, i.e this use case, [unset] variable = ... nullify some /etc/gitconfig values ... [include] path = ~/.gitcommon [unset] variable = ... nullify some ~/.gitcommon values ... [xyzzy] frotz = nitfol 3 Special case unset.variable, so that git config unset.variable foo.baz pastes it on the top of the file. The implementation should be trivial, but, Junio had said in an earlier mail that he doesn't think this approach would do much good. Other than this approach, Junio had suggested to append it after the last mention of foo.baz, but I don't think if it would be worth it, but still I will cook up the code for it. 4 Change the name to config.unset or something. I will make the above changes in the next revision. Thanks. -- 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/RFC 5/5] add tests for checking the behaviour of unset.variable
On Mon, Oct 6, 2014 at 11:59 AM, Tanay Abhra tanay...@gmail.com wrote: 3 Special case unset.variable, so that git config unset.variable foo.baz pastes it on the top of the file. The implementation should be trivial, but, Junio had said in an earlier mail that he doesn't think this approach would do much good. Other than this approach, Junio had suggested to append it after the last mention of foo.baz,... Just to make sure there is no misunderstanding. it in append it above does not refer to unset.variable, and the last mention of foo.baz is not [foo]baz=value The point is to preventgit config --add foo.baz anothervalue starting from --- --- --- [foo] bar = some [unset] variable = foo.baz --- --- --- from adding foo.baz next to existing foo.bar. We would want to end up with --- --- --- [foo] bar = some [unset] variable = foo.baz [foo] baz = anothervalue --- --- --- So When dealing with foo.baz, ignore everything above the last unset.variable that unsets foo.baz is what I meant (and I think that is how I wrote). -- 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/RFC 5/5] add tests for checking the behaviour of unset.variable
On 10/7/2014 12:58 AM, Junio C Hamano wrote: The point is to preventgit config --add foo.baz anothervalue starting from --- --- --- [foo] bar = some [unset] variable = foo.baz --- --- --- from adding foo.baz next to existing foo.bar. We would want to end up with --- --- --- [foo] bar = some [unset] variable = foo.baz [foo] baz = anothervalue --- --- --- So When dealing with foo.baz, ignore everything above the last unset.variable that unsets foo.baz is what I meant (and I think that is how I wrote). Yes, that was what I inferred too, I should have worded it more carefully, thanks. -- 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 svn's performance issue and strange pauses, and other thing
-- On Sun, Oct 5, 2014 02:02 BST Eric Wong wrote: Eric Wong normalper...@yhbt.net wrote: Jakob sent some patches a few months ago which seem to address the issue. Unfortunately we forgot about them :x Hin-Tak: have you tried Jakob's patches? I've taken another look, signed-off and pushed to my master. Can you take a look at the following two mergeinfo-speedups in my repo? (git://bogomips.org/git-svn) Jakob Stoklund Olesen (2): git-svn: only look at the new parts of svn:mergeinfo git-svn: only look at the root path for svn:mergeinfo Also downloadable here: http://bogomips.org/git-svn.git/patch?id=9b258e721b30785357535 http://bogomips.org/git-svn.git/patch?id=73409a2145e93b436d74a Can you please give them a try? Apologies - I applied them on top of 2.1.0 earlier today, and the svn repo just hasn't been changed much recently to show any interesting behavior with 'git svn fetch --all', so I thought about whether I should wait to report. Then I changed my mind, and decided what the hell, let's clone the whole thing again :-). So I made a new directory, run 'git init', just copy .git/config from the old reop and am doing 'git svn fetch --all' in the new empty directory again. So far it seems to be good. But I am only at revision 35700-ish at the moment, and the whole thing is 66700-ish. Oh, I forgot to mention that the strange pauses seem to be followed by messages like these: W:svn cherry-pick ignored (/branches/R-2-12-branch:52939,54476,55265) - missing 492 commit(s) (eg 9bf20dca6a8b05dff28e6486b1613f10825972c9) W:svn cherry-pick ignored (/branches/R-2-13-branch:55265,55432) - missing 231 commit(s) (eg 9290cf6ce2d7f6cca168cf326eed6e9fe760895f) W:svn cherry-pick ignored (/branches/R-2-15-branch:58894,59717) - missing 405 commit(s) (eg ed84a373b33f728949edf3371829fc3414c343a8) W:svn cherry-pick ignored (/branches/R-3-0-branch:62497) - missing 154 commit(s) (eg 9e4742d201771c9658417c2d2f83838e550e3162) W:svn cherry-pick ignored (/trunk: So presumably I'd only see interesting behavior when there are a number of branches. It seems the first branches are around revision 48000-ish, so I might have to wait a bit. So far, the new clone hasn't created .git/svn/.caches/ yet; and memory consumption seems okay also. -- 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
