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 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
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 prevent"git 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: [PATCH/RFC 5/5] add tests for checking the behaviour of "unset.variable"
On Mon, Oct 6, 2014 at 11:59 AM, Tanay Abhra 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 prevent"git 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/4/2014 1:42 AM, Junio C Hamano wrote: > Matthieu Moy writes: > >> Junio C Hamano 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: [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: 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: Can I fetch an arbitrary commit by sha1?
On Thu, Oct 2, 2014 at 12:10 PM, Jeff King 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: [RFC/PATCH 1/2] config: Add safe-include directive
Rasmus Villemoes writes: > Junio C Hamano 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
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
Junio C Hamano 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
