Re: [PATCHv2 0/2] log decorations for HEAD
Michael J Gruber g...@drmicha.warpmail.net writes: So it didn't take too long to convince me after all :) Here comes Junio's version, preceded by a cleanup of the color setting and resetting for decorations. Junio C Hamano (1): log: decorate HEAD with branch name Michael J Gruber (1): log-tree: properly reset colors log-tree.c| 76 ++- t/t4013/diff.log_--decorate_--all | 2 +- t/t4207-log-decoration-colors.sh | 16 - 3 files changed, 77 insertions(+), 17 deletions(-) Hmph, is the do not leak commit color one the same as 5ee87585 (log --decorate: do not leak commit color into the next item, 2015-03-04) aka $gmane/264788 [*1*] or is there something I missed? [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/264063/focus=264788 -- 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 v2 04/10] archive.c: convert to use struct object_id
On 03/08/2015 12:23 AM, brian m. carlson wrote:
Convert a hard-coded 20 as well.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
archive.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/archive.c b/archive.c
index 96057ed..46d9025 100644
--- a/archive.c
+++ b/archive.c
@@ -101,7 +101,7 @@ static void setup_archive_check(struct git_attr_check
*check)
struct directory {
struct directory *up;
- unsigned char sha1[20];
+ unsigned char sha1[GIT_SHA1_RAWSZ];
This is a local struct, and I think it is only a three-line change to
change the sha1 member to
struct object_id oid;
Though perhaps you are delaying that change for some concrete reason.
[...]
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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 v3 2/2] Added tests for reset -
On Tue, Mar 10, 2015 at 1:52 PM, Sudhanshu Shekhar sudshekha...@gmail.com wrote: On Tue, Mar 10, 2015 at 6:56 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Sudhanshu Shekhar sudshekha...@gmail.com writes: +test_expect_success 'reset - in the presence of file named - with previous branch' ' + echo Unstaged changes after reset: expect + echo M - expect + echo M 1 expect Here and elsewhere: why not cat expect -EOF Unstaged changes after reset: M - M 1 ? I was confused whether to use cat or echo. I thought using cat will disrupt the indentation as the EOF needs to be on a single line. This is why I chose echo. Please let me know your thoughts on this. Here-docs are easier to compose and read than individual 'echo' statements for multi-line content. The '-' in front of EOF allows you to indent the entire body. Even better, use -\EOF to signify that you don't expect any interpolation to occur within the body. -- 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 v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 19, 2015, at 3:35 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
I just built from ‘master’, on FreeBSD 9.3:
cd ~/src
git clone https://github.com/git/git.git
cd git
gmake
Then tried ~/src/git/git clone https://OUR_REPO
It cores too, and I see: git-remote-https.core
Can you compile with debugging symbols and provide a backtrace? I'm not
seeing any such behavior on my end, and I'm not sure whether it's my
patch or something else that might be present in master.
The problem originally occurred under VMware Fusion and I’m unable to get a
backtrace from it.
I suspect memory constraints are a factor. There’s only 5GB RAM available
to this VM.
I have tried in another VM and that succeeds. All good there. It has 40GB
RAM.
I am going to try this on a third system. At present, we’re just 50/50 on
success.
We have made progress I think.
With stock git:
tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds.
2 - without a ticket, nothing works
With patched git:
tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter,
failure
If I have a valid ticket, why am I being prompted for credentials?
It appears patched git always wants credentials entered and ignores the valid
ticket.
2 - without a ticket, entering credentials, SUCCEEDS
Here is my test, with a valid kerberos ticket:
$ git clone https://git.example.com/git/clamav-bytecode-compiler
Cloning into 'clamav-bytecode-compiler'...
Username for 'https://git.example.com':
Password for 'https://git.example.com':
^Cmote: Counting objects: 224546
$
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote: I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? There's already such list in SubmittingPatches, so there's already quite a few to choose from: Also notice that a real name is used in the Signed-off-by: line. Please don't hide your real name. If you like, you can put extra tags at the end: 1. Reported-by: is used to credit someone who found the bug that the patch attempts to fix. 2. Acked-by: says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. Reviewed-by:, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. Tested-by: is used to indicate that the person applied the patch and found it to have the desired effect. You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- 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: Surprising interaction of binary and eol gitattributes
On 10.03.15 20:25, Michael Haggerty wrote: On 03/06/2015 10:30 PM, Torsten Bögershausen wrote: Oops, I misunderstood an internal bug report. In seems that it is the following scenario that is incorrect: *.png text=auto eol=crlf Hm, I don't know if we support this combination at all. The user can specify this combination in a .gitattributes file and we have to react to it *some way*. Theoretically we could document that this combination is undefined and/or emit an error if we see this combination, but we don't do so. The current logic supports auto-detection of text/binary, * text=auto (the files will get the line ending from core.eol or core.autocrlf) or the the setting of a line ending: *.sh eol=lf *.bat eol=crlf Is there a special use-case, which needs the combination of both ? I'm still trying to infer the spirit of the current behavior, so caveats here. This comes from a real-life scenario where a user, somewhere early in .gitattributes, had * text * eol=crlf and then later (this could be in a subdirectory) tried to carve out exceptions to this rule by using *.png binary * text=auto Hm, I can see 2 problems here: the binary attribute does not exist at all. I sometimes which we had it, but we don't. There is text and -text, and that is it. The other problem is the order of the lines, which is fully intuitive for each person who has ever written a matching parser. The parser matches each file namr on it's own, depending on the matching: *.png -text * text=auto means that all png files are binary, and ALL files are auto. Guess what happens to the png's ? The second rule wins, as it is the last rule processed. git check-attr text * A.png: text: auto B.txt: text: auto --- If we reverse the order in .gitattributes, things look better: * text=auto *.png -text git check-attr text * A.png: text: unset B.txt: text: auto This is not very intuitive or even surprising, at least for many people. Unless I mis-understand the problem, it may be that the documentation may be updated ? The general rule for writing .gitattributes is to specify the wider rules first, and then the more specific rules after that. It could be that Documentation/gitattributes.txt should mention this instead: * -text *.txt text *.vcprojeol=crlf *.sheol=lf The other thing is to promote/mention the command git check-attr text * at a prominent place. Intuitively it *feels* like either of the later lines should suppress EOL translation in PNG files (assuming the PNG file has a NUL byte in the first 8k, which this one did). It seems to me that setting text=auto should mean that Git uses its heuristic to guess whether a particular file is text or not, and then treats the file as if it had text or -text set. If the latter, then EOL translation should be suppressed. It also seems to me that binary should imply -eol. Michael -- 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 v3 3/4] docs/git-credential-store: document XDG file and precedence
On Wed, Mar 11, 2015 at 3:47 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com wrote: + +If not set explicitly with '--file', there are two files where +git-credential-store will search for credentials in order of precedence: + +~/.git-credentials:: + User-specific credentials file. + +$XDG_CONFIG_HOME/git/credentials:: + Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set + or empty, `$HOME/.config/git/credentials` will be used. Any credentials + stored in this file will not be used if `~/.git-credentials` has a + matching credential as well. It is a good idea not to create this file + if you sometimes use older versions of Git, as support for this file + was added fairly recently. The final sentence won't age well: fairly recently is too nebulous. It may be sufficient merely to advise the reader to avoid this file if she also uses an older version of Git which doesn't support XDG for credentials. I copied this part from the documentation of git-config. I couldn't find the exact patch in the archives where fairly recently was introduced, but I did find this patch[1] where apparently a version number was supposed to be used instead. [1] http://thread.gmane.org/gmane.comp.version-control.git/198837/focus=200552 So yes, at this point in time I think the sentence should be changed to something like It is a good idea not to create this file if you use older versions of git that do not support this file., although it would be even more useful for users if the version where this feature was introduced is stated as well. This patch series has not even hit pu though ;) Other than this minor point, the patch series seems well prepared and quite nicely done. Thanks. Thank you so much for the positive review. Will re-roll the documentation. Regards, Paul -- 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 v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Tue, Mar 10, 2015 at 06:05:46PM +, Dan Langille (dalangil) wrote: We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure If I have a valid ticket, why am I being prompted for credentials? libcurl won't even attempt authentication if you don't have a username specified. I know that the web server should be able to figure it out from your credentials, so it shouldn't matter what username you provide. This is an unfortuate quirk of lib curl. I understand. Also, are you using 2.3.0, or one of the earlier patched versions? That might affect how it works. I am using git-2.3.0 It appears patched git always wants credentials entered and ignores the valid ticket. So what I think is happening is that you didn't specify a username, but git got a 401, so it prompted. Now it actually attempts to use the password you provided, whereas before it did not. Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? Thank you for your help in getting us this far. This helps us tremendously. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v2 01/10] Define a structure for object IDs.
On Wed, Mar 11, 2015 at 05:26:56PM -0700, Junio C Hamano wrote: brian m. carlson sand...@crustytoothpaste.net writes: Michael Haggerty recommended that I call the structure element sha1 instead of oid in case we want to turn this into a union if we decide to go the additional hash route. I'd advise against it. Yeah, after re-reading this, I think hash is the best choice for the underlying element name. That way, it's different from oid, which would be the instances of the struct itself, and it's sufficiently different from unconverted places in the code, which don't typically use that term. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH v3 4/4] t0302: test credential-store support for XDG_CONFIG_HOME
Hi, Thanks for taking the time to write such a detailed review and catching all of my careless mistakes. On Wed, Mar 11, 2015 at 4:40 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com wrote: t0302 now tests git-credential-store's support for the XDG user-specific configuration file $XDG_CONFIG_HOME/git/credentials. Specifically: * Ensure that the XDG file is strictly opt-in. It should not be created by git at all times if it does not exist. * On the flip side, if the XDG file exists, ~/.git-credentials should not be created at all times. * If both the XDG file and ~/.git-credentials exists, then both files should be used for credential lookups. However, credentials should only be written to ~/.git-credentials. Regarding the final sentence: I don't see a test corresponding to the restriction that only ~/.git-credentials will be modified if both files exist. Am I missing something? Whoops, the test is indeed missing. +test_expect_success '~/.git-credentials is written to when xdg credentials file does not exist' ' + test -s $HOME/.git-credentials +' + +test_expect_success 'xdg credentials file will not be created if it does not exist' ' + test_path_is_missing $HOME/.config/git/credentials Since these two tests are complementary, each checking a facet of the same behavioral rule, it seems like they ought to be combined. For people reading the tests, having them separate implies incorrectly that they are unrelated, making it difficult to understand the overall picture of how the pieces relate to one another. In prose, you would describe the behavior as: When XDG credentials does not exist, write only to ~/.git-credentials; do not create XDG credentials. It's one thought; easy to read and understand. The test should reflect the same intent: test_expect_success '...' ' test -s $HOME/.git-credentials test_path_is_missing $HOME/.config/git/credentials ' The same observation applies to several other tests below. Indeed, it looks much cleaner. Thanks for the suggestion. +' + +test_expect_success 'create $XDG_CONFIG_HOME/git/credentials file' ' + test_might_fail rm $HOME/.git-credentials Can this just be rm -f $HOME/.git-credentials instead? I picked this pattern up in t1306-xdg-files.sh so I thought it is the norm, but turns out it's not. I think I can see the rationale though. At this point in the tests the file ~/.git-credentials is expected to exist, so if it does not exist a diagnostic message should be printed to stderr (which -f will not do). Whether this actually helps is purely theoretical though, so I will change it to rm -f on the next iteration. +' + +test_expect_success 'set up custom XDG_CONFIG_HOME credential file' ' + XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME + mkdir -p $XDG_CONFIG_HOME/git + $XDG_CONFIG_HOME/git/credentials + $HOME/.config/git/credentials +' + +helper_test store + +test_expect_success 'custom XDG_CONFIG_HOME credentials file will be written to if it exists' ' + test_when_finished unset XDG_CONFIG_HOME + test -s $XDG_CONFIG_HOME/git/credentials +' It feels wrong to set global state (XDG_CONFIG_HOME) in one test and then clear it later in another test, and it's not obvious to the casual reader that global state is being modified. An alternative would be to set XDG_CONFIG_HOME outside of the first test to which it applies, clear it after the final test. In reality, however, it only needs to be defined for the helper_test store invocation, so it also could be highly localized: XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME helper_test store unset XDG_CONFIG_HOME A final alternative would be to wrap the block of tests needing XDG_CONFIG_HOME within a subshell and set the variable only within the subshell. Then, there's no need to unset it, and it's clear to the reader that only the tests within the subshell are affected by it. I agree that the setting of XDG_CONFIG_HOME needs to be more localized. This is a by-product of me following the no code outside tests rule too strictly. A quick grep for export in the tests show that quite a lot of tests do use export outside of test scripts, though, so I guess I will change this to export XDG_CONFIG_HOME just before running helper_test store. Thanks for the suggestion. +test_expect_success 'get: return credentials from xdg file if the home files do not have them' ' + mkdir -p $HOME/.config/git + $HOME/.git-credentials + echo https://home-user:home-p...@example.com; $HOME/.config/git/credentials In the other tests, credentials in the XDG file are xdg-user:xdg-pass, and credentials in ~/.git-credentials are home-user:home-pass. It's not at all clear why, in this test, you instead use home-user:home-pass for the XDG credentials. It
Re: [JFF] - and @{-1} on various programs
Michael J Gruber g...@drmicha.warpmail.net writes: Junio C Hamano venit, vidit, dixit 10.03.2015 21:20: JFF stands for just for fun. ... What does not work are what needs further tweaking in revision.c parser. git checkout master git checkout next git log -.. should show what next has on top of master but I didn't touch the range notation so it does not work, for example. builtin/checkout.c | 3 --- builtin/merge.c| 3 +-- builtin/revert.c | 2 -- revision.c | 2 +- sha1_name.c| 57 +- 5 files changed, 37 insertions(+), 30 deletions(-) Like it :) It removes the special casing and makes a shorthand available systematically. I'd say it's useful even without extending it to ranges. I wouldn't have done this if I thought it will lead to an unusable blind alley ;-) But I won't be hacking on this any further for now. Hint hint... -- 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 v2 01/10] Define a structure for object IDs.
On Thu, Mar 12, 2015 at 11:28:10AM +0100, Michael Haggerty wrote:
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
And that would break the abstraction effort if you start calling the
field with a name that is specific to the underlying hash function.
The caller has to change o-sha1 to o-sha256 instead of keeping
that as o-oid and letting the callee handle the implementation
details when calling
if (!hashcmp(o1-oid, o2-oid))
; /* they are the same */
else
; /* they are different */
[...]
Hmm, I guess you imagine that we might sometimes pack SHA-1s, sometimes
SHA-256s (or whatever) in the oid field, which would be dimensioned
large enough for either one (with, say, SHA-1s padded with zeros).
I was imagining that this would evolve into a union (or maybe struct) of
different hash types, like
struct object_id {
unsigned char hash_type;
union {
unsigned char sha1[GIT_SHA1_RAWSZ];
unsigned char sha256[GIT_SHA256_RAWSZ];
} hash;
};
BTW in either case, any hopes of mapping object_id objects directly on
top of buffer memory would disappear.
What I think might be more beneficial is to make the hash function
specific to a particular repository, and therefore you could maintain
something like this:
struct object_id {
unsigned char hash[GIT_MAX_RAWSZ];
};
and make hash_type (or hash_length) a global[0]. I don't think it's
very worthwhile to try to mix two different hash functions in the same
repository, so we could still map directly onto buffer memory if we
decide that's portable enough. I expect the cases where we need to do
that will be relatively limited.
Regardless, it seems that this solution has the most support (including
Junio's) and it's more self-documenting than my current set of patches,
so I'm going to go with it for now. It should be easy to change if the
consensus goes back the other way.
[0] I personally think globals are a bit gross, but they don't seem to
have the problems that they would if git were a shared library.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: [PATCH v2 00/10] Use a structure for object IDs.
Michael Haggerty mhag...@alum.mit.edu writes: I think this is a really interesting project and I hope that it works out. Count me in ;-) In my opinion, the biggest risk (aside from the sheer amount of work required) is the issue that was brought up on the mailing list when you submitted v1 [1]: Converting an arbitrary (unsigned char *) to a (struct object_id *) is not allowed, because the alignment requirements of the latter might be stricter than those of the former. This means that if, for example, we are reading some data from disk or from the network, and we expect the 20 bytes starting with byte number 17 to be a SHA-1 in binary format, we used to be able to do unsigned char *sha1 = buf + 17; and use sha1 like any other SHA-1, without the need for any copying. But we can't do the analogous struct object_id *oid = (struct object_id *)(buf + 17); because the alignment is not necessarily correct. So in a pure struct object_id world, I think we would be forced to change such code to struct object_id oid; hashcpy(oid.sha1, buf + 17); This uses additional memory and introduces copying overhead. Also, the lifetime of oid might exceed the scope of a function, so oid might have to be allocated on the heap and later freed. This adds more computational overhead, more memory overhead, and more programming effort to get it all right. Because we use abstraction to reduce burden on programmers, the last point is really what defeats this approach. I wonder if there is any way to make the new oid wrapped in a struct result in identical binary---that would be a reasonable criterion to judge the goodness of a change line this. Any difference could be (1) compiler being (a) stupid and not taking optimization opportunity it notices for a bare byte array but not for a byte array in struct or (b) clever and taking optimization opportunity the other way around, or (2) breakage in the conversion causing new bugs, perhaps coming from the alignment worries you cited above. (1-a) may or may not be an acceptable price to pay for a cleaner abstraction, but that depends on the extent of damage. (1-b) may be unlikely but if there is such a gain, that's nice ;-). And (2) is obviously a show-stopper X-. So as much as I like the idea of wrapping SHA-1s in objects, I think it would be a good idea to first make sure that we can all agree on a plan for dealing with situations like this. I can think of the following possibilities: These all look sensible to me. 4. We continue to support working with SHA-1s declared to be (unsigned char *) in some performance-critical code, even as we migrate most other code to using SHA-1s embedded within a (struct object_id). This will cost some duplication of code. To accept this approach, we would need an idea of *how much* code duplication would be needed. E.g., how many functions will need both (unsigned char *) versions and (struct object_id *) versions? Ideally, only the ones that knows the underlying hash function is SHA-1 (i.e. anybody who mentions git_SHA_CTX), moves bytes from/to in-core object name field and raw range of bytes (e.g. sha1hash()); everybody else like hashcpy() and hashcmp() should be able to do its thing only on structs and a generic-looking constant that denotes how many bytes there are in the hash (or even sizeof(struct oid)). I do not know what kind of code duplication you are worried about, though. If a callee needs unsigned char *, the caller that has a struct object_id *o should pass o-hash to the callee. We should not add another variant of the same callee that takes a pointer to struct object_id---I think that leads to insanty, e.g. int hashcmp_o_o(struct object_id *, struct object_id *); int hashcmp_o_b(struct object_id *, unsigned char *); int hashcmp_b_o(unsigned char *, struct object_id *); int hashcmp_b_b(unsigned char *, unsigned char *); And please do not suggest switching to C++; all it would do to overload these into a single name is to make the callers harder to read. -- 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 v2 01/10] Define a structure for object IDs.
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I'd advise against it.
As I wrote in $gmane/265337 in response to Michael:
4. We continue to support working with SHA-1s declared to be (unsigned
char *) in some performance-critical code, even as we migrate most other
code to using SHA-1s embedded within a (struct object_id). This will
cost some duplication of code. To accept this approach, we would need an
idea of *how much* code duplication would be needed. E.g., how many
functions will need both (unsigned char *) versions and (struct
object_id *) versions?
...
I do not know what kind of code duplication you are worried about,
though. If a callee needs unsigned char *, the caller that has a
struct object_id *o should pass o-hash to the callee.
And that would break the abstraction effort if you start calling the
field with a name that is specific to the underlying hash function.
The caller has to change o-sha1 to o-sha256 instead of keeping
that as o-oid and letting the callee handle the implementation
details when calling
if (!hashcmp(o1-oid, o2-oid))
; /* they are the same */
else
; /* they are different */
[...]
Hmm, I guess you imagine that we might sometimes pack SHA-1s, sometimes
SHA-256s (or whatever) in the oid field, which would be dimensioned
large enough for either one (with, say, SHA-1s padded with zeros).
I was imagining that this would evolve into a union (or maybe struct) of
different hash types, like
struct object_id {
unsigned char hash_type;
union {
unsigned char sha1[GIT_SHA1_RAWSZ];
unsigned char sha256[GIT_SHA256_RAWSZ];
} hash;
};
BTW in either case, any hopes of mapping object_id objects directly on
top of buffer memory would disappear.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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 v2 01/10] Define a structure for object IDs.
On Thu, Mar 12, 2015 at 5:46 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Thu, Mar 12, 2015 at 11:28:10AM +0100, Michael Haggerty wrote:
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
And that would break the abstraction effort if you start calling the
field with a name that is specific to the underlying hash function.
The caller has to change o-sha1 to o-sha256 instead of keeping
that as o-oid and letting the callee handle the implementation
details when calling
if (!hashcmp(o1-oid, o2-oid))
; /* they are the same */
else
; /* they are different */
[...]
Hmm, I guess you imagine that we might sometimes pack SHA-1s, sometimes
SHA-256s (or whatever) in the oid field, which would be dimensioned
large enough for either one (with, say, SHA-1s padded with zeros).
I was imagining that this would evolve into a union (or maybe struct) of
different hash types, like
struct object_id {
unsigned char hash_type;
union {
unsigned char sha1[GIT_SHA1_RAWSZ];
unsigned char sha256[GIT_SHA256_RAWSZ];
} hash;
};
BTW in either case, any hopes of mapping object_id objects directly on
top of buffer memory would disappear.
What I think might be more beneficial is to make the hash function
specific to a particular repository, and therefore you could maintain
something like this:
struct object_id {
unsigned char hash[GIT_MAX_RAWSZ];
};
and make hash_type (or hash_length) a global[0]. I don't think it's
very worthwhile to try to mix two different hash functions in the same
repository,
This may or may not fall into the mix different hash functions
category. In pack files version 4, trees are encoded to point to other
trees or blobs by a (pack, offset) tuple. It would be great if the new
object_id could support carrying this kind of object id around because
it could help reduce object lookup cost a lot. (pack, offset) can be
converted back to SHA-1 so no info is lost and hashcmp() can compare
(pack, tuple) against an SHA-1 just fine.
so we could still map directly onto buffer memory if we
decide that's portable enough. I expect the cases where we need to do
that will be relatively limited.
Regardless, it seems that this solution has the most support (including
Junio's) and it's more self-documenting than my current set of patches,
so I'm going to go with it for now. It should be easy to change if the
consensus goes back the other way.
[0] I personally think globals are a bit gross, but they don't seem to
have the problems that they would if git were a shared library.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
--
Duy
--
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 v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 11, 2015, at 5:59 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? You might try looking at git config --help. It looks like there's a credential.username option that might do what you want. Brian et al, Thank you for your help and patience with this. It is appreciated. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
[PATCH 3/7] t: translate SIGINT to an exit
Right now if a test script receives SIGINT (e.g., because a
test was hanging and the user hit ^C), the shell exits
immediately. This can be annoying if the test script did any
global setup, like starting apache or git-daemon, as it will
not have an opportunity to clean up after itself. A
subsequent run of the test won't be able to start its own
daemon, and will either fail or skip the tests.
Instead, let's trap SIGINT to make sure we do a clean
shutdown, and just chain it to a normal exit (which will
trigger any cleanup).
Signed-off-by: Jeff King p...@peff.net
---
Possibly we should catch other signals here, too, but SIGINT is the one
that has been biting me over the years (I would sometimes have a stray
apache process hanging around, and I only recently figured out what
caused it).
I think trap ... INT is the most portable way to say this. I would
have thought numbers were more portable, but they are actually an XSI
add-on. Likewise, SIGINT is allowed in POSIX but not required. INT
is part of POSIX.
This is the cleanest way I could come up with to implement this. We
could also just include INT on the same line as the die, but:
1. Then every script which sets a handler (like lib-httpd.sh) would
need to be modified to munge the INT trap, too.
2. It double-calls die, then. We die from the INT handler, which
triggers the EXIT handler. I guess we could clear the handler
inside die() if we needed to.
So I'd rather go this route, unless there turns out to be a weird
portability problem.
t/test-lib.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..f4ba3ff 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -299,6 +299,7 @@ die () {
GIT_EXIT_OK=
trap 'die' EXIT
+trap 'exit $?' INT
# The user-facing functions are loaded from a separate file so that
# test_perf subshells can have them too
--
2.3.2.472.geadab3c
--
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
[PATCH 7/7] t5551: make EXPENSIVE test cheaper
We create 50,000 tags to check that we don't overflow the command-line of fetch-pack. But by using run_with_cmdline_limit, we can get the same effect with a much smaller number of tags. This makes the test fast enough that we can drop the EXPENSIVE prereq, which means people will actually run it. It was not documented to do so, but this test was also the only test of a clone-over-http that requires multiple POSTs during the conversation. We can continue to test that by dropping http.postbuffer to its minimum size, and checking that we get two POSTs. Signed-off-by: Jeff King p...@peff.net --- This is still a slightly expensive test, but it's on par with what the push test does, so hopefully it's OK. And it bothers me that we didn't exercise the multiple-POST code at all in the test suite, as I assume basically nobody runs the tests with --long. I don't think we can shrink it any more. We enforce a hard minimum of LARGE_PACKET_MAX on http.postbuffer, and that assumption runs through the code. Lots of things break if you try to circumvent it, and I didn't bother digging further. t/t5551-http-fetch-smart.sh | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index b970773..df47851 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -224,10 +224,10 @@ test_expect_success 'transfer.hiderefs works over smart-http' ' git -C hidden.git rev-parse --verify b ' -test_expect_success EXPENSIVE 'create 50,000 tags in the repo' ' +test_expect_success 'create 2,000 tags in the repo' ' ( cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git - for i in `test_seq 5` + for i in $(test_seq 2000) do echo commit refs/heads/too-many-refs echo mark :$i @@ -248,13 +248,22 @@ test_expect_success EXPENSIVE 'create 50,000 tags in the repo' ' ) ' -test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command line overflow' ' - git clone $HTTPD_URL/smart/repo.git too-many-refs +test_expect_success CMDLINE_LIMIT \ + 'clone the 2,000 tag repo to check OS command line overflow' ' + run_with_limited_cmdline git clone $HTTPD_URL/smart/repo.git too-many-refs ( cd too-many-refs - test $(git for-each-ref refs/tags | wc -l) = 5 + git for-each-ref refs/tags actual + test_line_count = 2000 actual ) ' +test_expect_success 'large fetch-pack requests can be split across POSTs' ' + GIT_CURL_VERBOSE=1 git -c http.postbuffer=65536 \ + clone --bare $HTTPD_URL/smart/repo.git split.git 2err + grep ^ POST err posts + test_line_count = 2 posts +' + stop_httpd test_done -- 2.3.2.472.geadab3c -- 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 0/7] fix transfer.hiderefs with smart http
On Fri, Mar 13, 2015 at 12:41:01AM -0400, Jeff King wrote: I'm experimenting with using transfer.hiderefs on a server, and it's rather easy to cause a git client to hang when fetching from such a repo over smart http. Details are in the first patch. A note on this hang. What happens is that upload-pack sees a bogus want line and calls die(). The client then sits there forever, but I'm not exactly sure what it's waiting for. This series fixes the bug that caused us to erroneously call die() in upload-pack, so the hang is fixed. But there are other reasons to call die(); it would probably be a good thing if the client side noticed the problem and aborted. -Peff -- 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
[PATCH 4/7] t: redirect stderr GIT_TRACE to descriptor 4
If you run a test script like: GIT_TRACE=1 ./t0061-run-command.sh you may get test failures, because some tests capture and check the stderr output from git commands (and with GIT_TRACE set to 1, the trace output will be included there). When we see GIT_TRACE set like this, we print a warning to the user. However, we can do even better than that by just pointing it to descriptor 4, which all tests leave connected to the test script's stderr. That's likely what the user intended (and any scripts that do want to see GIT_TRACE output will set GIT_TRACE themselves). Not only does this avoid false negatives in the tests, but it means the user will actually see trace output for git calls that redirect their stderr (whereas before, it was sometimes confusingly buried in a file). Signed-off-by: Jeff King p...@peff.net --- I only today figured out the GIT_TRACE=4 trick. Perhaps everybody else did long ago, and I am just slow. :) My first inclination was to mention it in the warning message below, but I cannot see a downside to automatically redirecting it. Even outside of test_expect_* we have the 42 redirection, so we should hit even badly written scripts which call git outside of that environment. t/test-lib.sh | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index f4ba3ff..7dd4b4d 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -152,10 +152,7 @@ unset UNZIP case $(echo $GIT_TRACE |tr [A-Z] [a-z]) in 1|2|true) - echo * warning: Some tests will not work if GIT_TRACE \ - is set as to trace on STDERR ! * - echo * warning: Please set GIT_TRACE to something \ - other than 1, 2 or true ! * + GIT_TRACE=4 ;; esac -- 2.3.2.472.geadab3c -- 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
[PATCH 1/7] upload-pack: fix transfer.hiderefs over smart-http
When upload-pack advertises the refs (either for a normal,
non-stateless request, or for the initial contact in a
stateless one), we call for_each_ref with the send_ref
function as its callback. send_ref, in turn, calls
mark_our_ref, which checks whether the ref is hidden, and
sets OUR_REF or HIDDEN_REF on the object as appropriate. If
it is hidden, mark_our_ref also returns 1 to signal
send_ref that the ref should not be advertised.
If we are not advertising refs, (i.e., the follow-up
invocation by an http client to send its want lines), we
use mark_our_ref directly as a callback to for_each_ref. Its
marking does the right thing, but when it then returns 1
to for_each_ref, the latter interprets this as an error and
stops iterating. As a result, we skip marking all of the
refs that come lexicographically after it. Any want lines
from the client asking for those objects will fail, as they
were not properly marked with OUR_REF.
To solve this, we introduce a wrapper callback around
mark_our_ref which always returns 0 (even if the ref is
hidden, we want to keep iterating). We also tweak the
signature of mark_our_ref to exclude unnecessary parameters
that were present only to conform to the callback interface.
This should make it less likely for somebody to accidentally
use it as a callback in the future.
Signed-off-by: Jeff King p...@peff.net
---
t/t5551-http-fetch-smart.sh | 11 +++
upload-pack.c | 14 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
index 6cbc12d..b970773 100755
--- a/t/t5551-http-fetch-smart.sh
+++ b/t/t5551-http-fetch-smart.sh
@@ -213,6 +213,17 @@ test_expect_success 'cookies stored in http.cookiefile
when http.savecookies set
test_cmp expect_cookies.txt cookies_tail.txt
'
+test_expect_success 'transfer.hiderefs works over smart-http' '
+ test_commit hidden
+ test_commit visible
+ git push public HEAD^:refs/heads/a HEAD:refs/heads/b
+ git --git-dir=$HTTPD_DOCUMENT_ROOT_PATH/repo.git \
+ config transfer.hiderefs refs/heads/a
+ git clone --bare $HTTPD_URL/smart/repo.git hidden.git
+ test_must_fail git -C hidden.git rev-parse --verify a
+ git -C hidden.git rev-parse --verify b
+'
+
test_expect_success EXPENSIVE 'create 50,000 tags in the repo' '
(
cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git
diff --git a/upload-pack.c b/upload-pack.c
index b531a32..c8e8713 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -681,7 +681,7 @@ static void receive_needs(void)
}
/* return non-zero if the ref is hidden, otherwise 0 */
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
+static int mark_our_ref(const char *refname, const unsigned char *sha1)
{
struct object *o = lookup_unknown_object(sha1);
@@ -695,6 +695,12 @@ static int mark_our_ref(const char *refname, const
unsigned char *sha1, int flag
return 0;
}
+static int check_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
+{
+ mark_our_ref(refname, sha1);
+ return 0;
+}
+
static void format_symref_info(struct strbuf *buf, struct string_list *symref)
{
struct string_list_item *item;
@@ -713,7 +719,7 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
- if (mark_our_ref(refname, sha1, flag, NULL))
+ if (mark_our_ref(refname, sha1))
return 0;
if (capabilities) {
@@ -767,8 +773,8 @@ static void upload_pack(void)
advertise_shallow_grafts(1);
packet_flush(1);
} else {
- head_ref_namespaced(mark_our_ref, NULL);
- for_each_namespaced_ref(mark_our_ref, NULL);
+ head_ref_namespaced(check_ref, NULL);
+ for_each_namespaced_ref(check_ref, NULL);
}
string_list_clear(symref, 1);
if (advertise_refs)
--
2.3.2.472.geadab3c
--
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
[PATCH 2/7] upload-pack: do not check NULL return of lookup_unknown_object
We check whether the return value of lookup_unknown_object is NULL, but some code paths dereference it before our check. This turns out not to be capable of causing a segfault, though. The lookup_unknown_object function will never return NULL, since the whole point is to allocate an object struct if it does not find an existing one. So the code here is not wrong, it is just confusing. Let's just drop the NULL check. Signed-off-by: Jeff King p...@peff.net --- upload-pack.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index c8e8713..aa84576 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -689,8 +689,6 @@ static int mark_our_ref(const char *refname, const unsigned char *sha1) o-flags |= HIDDEN_REF; return 1; } - if (!o) - die(git upload-pack: cannot find object %s:, sha1_to_hex(sha1)); o-flags |= OUR_REF; return 0; } -- 2.3.2.472.geadab3c -- 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
Watch DVD movies on Mac Mini via Plex/Home theatre
Watch DVD movies on Mac Mini via Plex/Home theatre This article tells you how to convert DVD collection to MKV/MP4 on Mac for watching on Mac Mini via Plex server and Home theatre and backup them onto NAS sever. While enjoying broadcast and Internet TV on Mac with ease, have you ever thought of putting your DVD movie collections to your media server and other devices Library for playback? Here is a question from one of my friend. Now I wanted to create backups of my dvd collection and to play them without having to search through several shelfs of DVDs and I also wana clear the shelfs to keep it clean. Then how to copy my dvds onto Mac Mini via Plex server and Home theatre, and keep them on NAS for storage? To help him out, I Googled the best Blu-ray/DVD ripper and read the top reviews, I find a wonderful BDMagic for Mac which has many good reviews on internet, no extra charges at checkout. (Read Top 5 Best Blu-ray Ripper for Mac Programs Review) I have successfully ripped my Blu-ray and DVD into mp4 format for watching on my 2 iPads and 1 iPhone with it, and then I recommended it to my friend to help him easily manage his DVD videos with creating backups. Now go to try the trial version to experience what it can do for you. Here let me show you how to convert Blu-ray to MKV/MP4 format for streaming via Plex server and Home theatre step by step. Before going on, please make sure having downloaded and installed it. Note: Pavtube BDMagic is made for Windows users Step 1. Load DVD disc. Launch the program and click Load file button to import DVD source. After loading it successfully, you can go to select subtitle and audio tracks for output. Step 2. Choose MKV/MP4 format. In the dropdown list of Format, there are a mass of video format. You can choose Common Video MKV(Matroska) Video (*.mkv) format for getting the libraries stored on NAS. Or select Common Video H.264 Video(*.mp4) for watching your dvd on Mac Mini through Plex server and Home theatre. Note: You are also allowed to change the video and audio parameters like codec, bitrate, channels, frame rate, etc. You can adjust it according to your demand or keep it default for output. Step 3. Convert DVD movies on Mac. Click the Convert button to start converting DVD to MKV/MP4 format. With the technology of CUDA acceleration it will provide you fast conversion speed. Once completed, go to Open the generated MKV files for playback. (Check CUDA acceleration here) Tips: If you want to bacup dvd movies and DVDs to MKV container format with multiple audio tracks and subtitles included, try Pavtube ByteCopy for Mac. And choose Multi-track Video Lossless/encoded Multi-track MKV(*.mkv) to get multi-track mkv format. Also you could have lots of Money Saving Software Bundles with special offer. Go to find more surprising bundled software and have a try now. Source: http://compatibleformat.snappages.com/blog/2014/04/11/backup-dvd-collection-to-play-via-plex-server-and-home-theatre-on-mac -- View this message in context: http://git.661346.n2.nabble.com/Watch-DVD-movies-on-Mac-Mini-via-Plex-Home-theatre-tp7626972.html Sent from the git mailing list archive at Nabble.com. -- 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
[PATCH 0/7] fix transfer.hiderefs with smart http
I'm experimenting with using transfer.hiderefs on a server, and it's rather easy to cause a git client to hang when fetching from such a repo over smart http. Details are in the first patch. There are 7 patches here, but the entirety of the fix is contained in the first one. The rest are cleanups and test enhancements I found along the way. I moved the fix to the front of the series as we probably want it to go to maint, but the others can wait (being mostly test modifications, they should not cause regressions, but they'd possibly want more cooking time in case I broke the test suite for somebody). The patches are: [1/7]: upload-pack: fix transfer.hiderefs over smart-http The fix. [2/7]: upload-pack: do not check NULL return of lookup_unknown_object A nearby cleanup. [3/7]: t: translate SIGINT to an exit [4/7]: t: redirect stderr GIT_TRACE to descriptor 4 [5/7]: t: pass GIT_TRACE through Apache These all solve irritations I had when trying to debug the test. [6/7]: t5541: move run_with_cmdline_limit to test-lib.sh [7/7]: t5551: make EXPENSIVE test cheaper I had thought at first that the problem was related to large http fetches, but it turned out not to be. But I think these cleanups are a good thing, as they increase the default test coverage. -Peff -- 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 0/7] fix transfer.hiderefs with smart http
On Fri, Mar 13, 2015 at 11:59 AM, Jeff King p...@peff.net wrote: On Fri, Mar 13, 2015 at 12:41:01AM -0400, Jeff King wrote: I'm experimenting with using transfer.hiderefs on a server, and it's rather easy to cause a git client to hang when fetching from such a repo over smart http. Details are in the first patch. A note on this hang. What happens is that upload-pack sees a bogus want line and calls die(). The client then sits there forever, but I'm not exactly sure what it's waiting for. This series fixes the bug that caused us to erroneously call die() in upload-pack, so the hang is fixed. But there are other reasons to call die(); it would probably be a good thing if the client side noticed the problem and aborted. Maybe we could install a custom die handler that also sends ERR line to the client before dying. Even with old clients where ERR lines are not recognized, they would see that as a sign of error and abort. The only thing to be careful is not sending ERR while we're in the middle of sending some pkt-line, and that only happens when die() is called inside packet_write() and we can catch that easily. This is for upload-pack only as the client side can also use packet_buf_write(), a bit harder to know if some pkt-line is being sent. -- Duy -- 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
[PATCH v2] git prompt: Use toplevel to find untracked files.
From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 214e859f99e7..f18aedc73be9 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,7 @@ __git_ps1 ()
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ]
[ $(git config --bool bash.showUntrackedFiles) != false
]
- git ls-files --others --exclude-standard --error-unmatch --
'*' /dev/null 2/dev/null
+ git ls-files --others --exclude-standard --error-unmatch --
':/*' /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
2.3.2
--
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
[PATCH 6/7] t5541: move run_with_cmdline_limit to test-lib.sh
We use this to test http pushing with a restricted
commandline. Other scripts (like t5551, which does http
fetching) will want to use it, too.
Signed-off-by: Jeff King p...@peff.net
---
As we discussed a while ago, this is the exact same code that
run_with_limited_stack uses in t7004. However, I think they are
conceptually two different things, and I could imagine a platform where
they have distinct implementations. So I did not refactor t7004 to make
use of this.
t/t5541-http-push-smart.sh | 6 --
t/test-lib.sh | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t5541-http-push-smart.sh b/t/t5541-http-push-smart.sh
index d2c681e..1ecb588 100755
--- a/t/t5541-http-push-smart.sh
+++ b/t/t5541-http-push-smart.sh
@@ -324,12 +324,6 @@ test_expect_success 'push into half-auth-complete requires
password' '
test_cmp expect actual
'
-run_with_limited_cmdline () {
- (ulimit -s 128 $@)
-}
-
-test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
-
test_expect_success CMDLINE_LIMIT 'push 2000 tags over http' '
sha1=$(git rev-parse HEAD)
test_seq 2000 |
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7dd4b4d..9914d3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1062,3 +1062,9 @@ test_lazy_prereq UNZIP '
$GIT_UNZIP -v
test $? -ne 127
'
+
+run_with_limited_cmdline () {
+ (ulimit -s 128 $@)
+}
+
+test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
--
2.3.2.472.geadab3c
--
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
[PATCH 5/7] t: pass GIT_TRACE through Apache
Apache removes GIT_TRACE from the environment before running git-http-backend. This can make it hard to debug the server side of an http session. Let's let it through. Signed-off-by: Jeff King p...@peff.net --- t/lib-httpd.sh | 1 + t/lib-httpd/apache.conf | 1 + 2 files changed, 2 insertions(+) diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh index d154d1e..e6adf2f 100644 --- a/t/lib-httpd.sh +++ b/t/lib-httpd.sh @@ -79,6 +79,7 @@ HTTPD_DOCUMENT_ROOT_PATH=$HTTPD_ROOT_PATH/www # hack to suppress apache PassEnv warnings GIT_VALGRIND=$GIT_VALGRIND; export GIT_VALGRIND GIT_VALGRIND_OPTIONS=$GIT_VALGRIND_OPTIONS; export GIT_VALGRIND_OPTIONS +GIT_TRACE=$GIT_TRACE; export GIT_TRACE if ! test -x $LIB_HTTPD_PATH then diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index 03a4c2e..0b81a00 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -70,6 +70,7 @@ PassEnv GIT_VALGRIND PassEnv GIT_VALGRIND_OPTIONS PassEnv GNUPGHOME PassEnv ASAN_OPTIONS +PassEnv GIT_TRACE Alias /dumb/ www/ Alias /auth/dumb/ www/auth/dumb/ -- 2.3.2.472.geadab3c -- 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 03/16] list-files: show paths relative to cwd
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- builtin/list-files.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/list-files.c b/builtin/list-files.c index b99f2b7..c444a53 100644 --- a/builtin/list-files.c +++ b/builtin/list-files.c @@ -3,6 +3,7 @@ #include parse-options.h #include pathspec.h #include dir.h +#include quote.h static struct pathspec pathspec; static const char *prefix; @@ -22,7 +23,7 @@ static void add_one(struct string_list *result, const char *name) struct strbuf sb = STRBUF_INIT; struct string_list_item *item; - strbuf_addstr(sb, name); + quote_path_relative(name, prefix_length ? prefix : NULL, sb); item = string_list_append(result, strbuf_detach(sb, NULL)); item-util = (char *)name; } Hmph, wouldn't it make it more cumbersome and problematic to do things like this here in add_one() phase? I am imagining that the endgame of this program will be - populate_cached_entries() reads from the data source (at this step, there is just the index), calling add_one() whose responsibility is to record the paths that are interesting to an in-core structure; - perform some interesting filtering, annotating, ordering, etc. (at this step, there is none) yet to come; - display() will iterate over the result and then format the result. For example, if you do the quote thing too early, don't codepaths in the later phases have to worry about item-string not matching the original pathname anymore? If you want to do something like /bin/ls -t, you may have to lstat() the paths for each item, but if these store a path relative to the prefix, wouldn't you have to prepend the prefix again before running lstat()? I am just wondering if this prefix-stripping and quoting belongs to the output phase, not the input phase. -- 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 03/16] list-files: show paths relative to cwd
Junio C Hamano gits...@pobox.com writes: static struct pathspec pathspec; static const char *prefix; @@ -22,7 +23,7 @@ static void add_one(struct string_list *result, const char *name) struct strbuf sb = STRBUF_INIT; struct string_list_item *item; -strbuf_addstr(sb, name); +quote_path_relative(name, prefix_length ? prefix : NULL, sb); item = string_list_append(result, strbuf_detach(sb, NULL)); item-util = (char *)name; } Hmph, wouldn't it make it more cumbersome and problematic to do things like this here in add_one() phase? I am imagining that the endgame of this program will be - populate_cached_entries() reads from the data source (at this step, there is just the index), calling add_one() whose responsibility is to record the paths that are interesting to an in-core structure; - perform some interesting filtering, annotating, ordering, etc. (at this step, there is none) yet to come; - display() will iterate over the result and then format the result. For example, if you do the quote thing too early, don't codepaths in the later phases have to worry about item-string not matching the original pathname anymore? If you want to do something like /bin/ls -t, you may have to lstat() the paths for each item, but if these store a path relative to the prefix, wouldn't you have to prepend the prefix again before running lstat()? I am just wondering if this prefix-stripping and quoting belongs to the output phase, not the input phase. Hmph, another interpretation of this patch is that your item-string are not the true filenames but the result of applying some interesting processing to the filenames and the true filenames are kept in item-util. Is that what is going on? If that is the case, it sort of makes sense to me, even though it would feel a bit unusual way to use the string-list. 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 01/16] list-files: command skeleton
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
list-files is supposed to be the user friendly version of ls-files, or
an alternative to git-status. Nothing fancy in this patch yet.
The result of applying this patch alone will not give us anything
fancy, but the patch itself is interesting ;-)
+static void populate_cached_entries(struct string_list *result,
+ const struct index_state *istate)
+{
+ int i;
+
+ for (i = 0; i istate-cache_nr; i++) {
+ const struct cache_entry *ce = istate-cache[i];
+
+ if (!match_pathspec(pathspec, ce-name, ce_namelen(ce),
+ 0, NULL,
+ S_ISDIR(ce-ce_mode) ||
+ S_ISGITLINK(ce-ce_mode)))
Because we won't tell the user You gave me Mkaefile but that did
not match when git list-files Mkaefile does not produce anything,
we do not need to pass seen[] down from here.
+ prefix = cmd_prefix;
+ if (prefix)
+ prefix_length = strlen(prefix);
+
+ if (read_cache() 0)
+ die(_(index file corrupt));
+
+ git_config(ls_config, NULL);
+
+ argc = parse_options(argc, argv, prefix, ls_options, ls_usage, 0);
+
+ parse_pathspec(pathspec, 0,
+PATHSPEC_PREFER_CWD |
+PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
+cmd_prefix, argv);
+ pathspec.max_depth = 0;
+ pathspec.recursive = 1;
+
+ refresh_index(the_index, REFRESH_QUIET | REFRESH_UNMERGED,
+ pathspec, NULL, NULL);
It would be better to do read-cache-preload, instead of read-cache,
if you are going to immediately refresh. That is what git status
does.
+ populate_cached_entries(result, the_index);
+ display(result);
+ string_list_clear(result, 0);
+ return 0;
+}
diff --git a/git.c b/git.c
index 18fbf79..ae7fe77 100644
--- a/git.c
+++ b/git.c
@@ -418,6 +418,7 @@ static struct cmd_struct commands[] = {
{ init, cmd_init_db, NO_SETUP },
{ init-db, cmd_init_db, NO_SETUP },
{ interpret-trailers, cmd_interpret_trailers, RUN_SETUP },
+ { list-files, cmd_list_files, RUN_SETUP | USE_PAGER | NEED_WORK_TREE
},
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 02/16] list-files: make :(glob) pathspec default
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/list-files.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/list-files.c b/builtin/list-files.c
index ac33f13..b99f2b7 100644
--- a/builtin/list-files.c
+++ b/builtin/list-files.c
@@ -65,6 +65,8 @@ int cmd_list_files(int argc, const char **argv, const char
*cmd_prefix)
{
struct string_list result = STRING_LIST_INIT_NODUP;
+ setenv(GIT_GLOB_PATHSPECS_ENVIRONMENT, 1, 0);
+
if (argc == 2 !strcmp(argv[1], -h))
usage_with_options(ls_usage, ls_options);
Yikes.
I do not have enough info at this step in the series to judge if it
is sensible to force the :(glob) interpretation as default, but is
it something we would want to do commonly to flip the default per
Git subcommand? If so, using the environment feels like a clunky
way to do that.
How about a two-patch clean-up before this step?
(1) remove the handling of literal_global and friends that peek
into various environment variables from prefix_pathspec(),
which is a function that is repeatedly called for each pathspec
element given from the command line, and move that logic to
parse_pathspec(); pass necessary information down to
prefix_pathspec() as parameter(s);
(2) allow parse_pathspec() so that the caller can say the default,
when there is no environment variable given by the end user to
tell us otherwise, is to :(glob).
--
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] tag: fix some mis-organized options in -h listing
Thanks. Even though this dates back to d96e3c15 (tag: add --column, 2012-04-13), I do not think it is worth backporting it to v1.7.x series, so I'll queue the fix for a bit newer maintenance track, perhaps for v2.1.x and above. -- 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: Promoting Git developers
Fredrik Gustafsson iv...@iveqy.com writes: On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote: I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? There's already such list in SubmittingPatches, so there's already quite a few to choose from: Also notice that a real name is used in the Signed-off-by: line. Please don't hide your real name. If you like, you can put extra tags at the end: 1. Reported-by: is used to credit someone who found the bug that the patch attempts to fix. 2. Acked-by: says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. Reviewed-by:, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. Tested-by: is used to indicate that the person applied the patch and found it to have the desired effect. You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. Hmph, the first step might be to drop that last sentence, I guess, if we consider this a mess and if we want to clean it up. -- 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-completion: add stashes for gitk
Sveinung Kvilhaugsvik sveinun...@users.sourceforge.net writes:
Auto complete stashed modifications for gitk. This makes them easier to
discover and faster to view.
Signed-off-by: Sveinung Kvilhaugsvik sveinun...@users.sourceforge.net
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c21190d..3a23abb 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2644,6 +2644,8 @@ __gitk_main ()
;;
esac
__git_complete_revlist
+ __gitcomp_nl_append $(git --git-dir=$(__gitdir) stash list \
+ | sed -n -e 's/:.*//p')
I do not find it particularly useful to expand gitk stTAB to
gitk st and offer sting stash@{0} stash@{1} stash@{2} stash@{3}
('sting' happens to be just one of the names of my branches) as
possible choices.
Because I happen to have only four stash entries right now, it may
still be manageable, but the stash entries can be dozens for some
people.
Once you have dozens of branches and tags, you learn to avoid gitk
TAB (or git log TAB) to prevent the completion code from
dumping all these refnames at you. Instead, you would give a few
characters before hitting the TAB to limit the completion. But
this change makes it harder if what you want happens to start with
es-tee something, as you would get many stash@{...} entries along
with it. Also, when you have no ref that is named es-tee something,
gitk stTAB completes to gitk stash@{, as if the problem the
change tries to cure is it is unnecessarily hard to type at-mark
open-brace.
I do not have to be the target audience, though. Maybe this is
useful for some people.
A bigger question is why this change is made to gitk completion. If
this completion were useful for gitk, wouoldn't it be equally
useful for git log?
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 v2 01/10] Define a structure for object IDs.
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: This may or may not fall into the mix different hash functions category. In pack files version 4, trees are encoded to point to other trees or blobs by a (pack, offset) tuple. It would be great if the new object_id could support carrying this kind of object id around because it could help reduce object lookup cost a lot. (pack, offset) can be converted back to SHA-1 so no info is lost and hashcmp() can compare (pack, tuple) against an SHA-1 just fine. You mean if it came in pack, offset format, convert it down to sha1 until the last second that it is needed (e.g. need to put that in a tree object in order to compute the object name of the containing tree object)? Sorry, obviously I meant do not convert until the last second. To me, pack, offset information smells to belong more to a struct object (or its subclass) as an optional annotation---when a caller is asked to parse_object(), you would bypass the sha1_read_file() that goes and looks the object name up from the list of pack .idx and instead go there straight using that annotation. -- 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
[PATCH] tag: fix some mis-organized options in -h listing
Running git tag -h currently prints:
[...]
Tag creation options
[...]
--column[=style]show tag list in columns
--sort type sort tags
Tag listing options
--contains commit print only tags that contain the commit
--points-at object print only tags of the object
The --column and --sort options should go under the Tag listing group.
Signed-off-by: Jeff King p...@peff.net
---
builtin/tag.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 4194b9a..6f07ac6 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -605,13 +605,13 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
OPT_STRING('u', local-user, keyid, N_(key-id),
N_(use another key to sign the tag)),
OPT__FORCE(force, N_(replace the tag if exists)),
+
+ OPT_GROUP(N_(Tag listing options)),
OPT_COLUMN(0, column, colopts, N_(show tag list in
columns)),
{
OPTION_CALLBACK, 0, sort, tag_sort, N_(type),
N_(sort tags),
PARSE_OPT_NONEG, parse_opt_sort
},
-
- OPT_GROUP(N_(Tag listing options)),
{
OPTION_CALLBACK, 0, contains, with_commit,
N_(commit),
N_(print only tags that contain the commit),
--
2.3.2.472.geadab3c
--
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 v2 01/10] Define a structure for object IDs.
Duy Nguyen pclo...@gmail.com writes: This may or may not fall into the mix different hash functions category. In pack files version 4, trees are encoded to point to other trees or blobs by a (pack, offset) tuple. It would be great if the new object_id could support carrying this kind of object id around because it could help reduce object lookup cost a lot. (pack, offset) can be converted back to SHA-1 so no info is lost and hashcmp() can compare (pack, tuple) against an SHA-1 just fine. You mean if it came in pack, offset format, convert it down to sha1 until the last second that it is needed (e.g. need to put that in a tree object in order to compute the object name of the containing tree object)? After converting an object name originally represented as pack, offset, if we are doing the union in struct thing, to sha1 representation, you would have to look it up from .idx in order to read the contents the usual way. If that happens often enough, then it may not be worth adding complexity to the code to carry the pack, offset pair around. Unless you fix that union in struct assumption, that is. To me, pack, offset information smells to belong more to a struct object (or its subclass) as an optional annotation---when a caller is asked to parse_object(), you would bypass the sha1_read_file() that goes and looks the object name up from the list of pack .idx and instead go there straight using that annotation. -- 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-completion: add stashes for gitk
Junio C Hamano gits...@pobox.com writes:
... Also, when you have no ref that is named es-tee something,
gitk stTAB completes to gitk stash@{, as if the problem the
change tries to cure is it is unnecessarily hard to type at-mark
open-brace.
I do not have to be the target audience, though. Maybe this is
useful for some people.
There is another thing your patch made me notice, which is not a
problem that is introduced by your desire to include stash entries
to the completion.
The way in which the users can name a stash entry is not very
descriptive. I often cannot offhand remember what stash@{2}
contains, for example, in my tree. So it is not very useful to be
offered a choice among stash@{0} stash@{1} stash@{2} and stash@{3}
by a TAB completion.
If there were a way for users to say The one I made to stash away
that change from the command line (I do not mean git stash list |
grep 'that change'), it would be good. A new syntax to name a
stash entry by pattern matching with the message given to stash
save could be something like (just thinking aloud, not suggesting
that this has to be our final design of that syntax):
$ git log stash@{/$pattern}
and then it mould make a lot of sense for a completion request
$ git log stash@{TAB
to result in something like this:
stash@{/avoid unnecessary negation}
stash@{/style fix t4122}
...
--
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 v2 01/10] Define a structure for object IDs.
On Fri, Mar 13, 2015 at 1:24 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: This may or may not fall into the mix different hash functions category. In pack files version 4, trees are encoded to point to other trees or blobs by a (pack, offset) tuple. It would be great if the new object_id could support carrying this kind of object id around because it could help reduce object lookup cost a lot. (pack, offset) can be converted back to SHA-1 so no info is lost and hashcmp() can compare (pack, tuple) against an SHA-1 just fine. You mean if it came in pack, offset format, convert it down to sha1 until the last second that it is needed (e.g. need to put that in a tree object in order to compute the object name of the containing tree object)? I picked my words poorly. It should be pack, the index in pack instead of the _byte_ offset. This index ranges from 0 to the number of objects minus one. This is essentially what pack v4 stores in places where pack v2 would store SHA-1, which makes me make the connection: both are different ways of identifying an object. After converting an object name originally represented as pack, offset, if we are doing the union in struct thing, to sha1 representation, you would have to look it up from .idx in order to read the contents the usual way. If that happens often enough, then it may not be worth adding complexity to the code to carry the pack, offset pair around. I'd keep it in pack, index for as long as possible (or until higher layer decides that it's not worth keeping in this representation anymore). I can only see two use cases where actual SHA-1 is involved: sorting by SHA-1 (rarely done, probably only in index-pack and pack-objects) and output to the screen (or producing v2 packs). Unless you fix that union in struct assumption, that is. To me, pack, offset information smells to belong more to a struct object (or its subclass) as an optional annotation---when a caller is asked to parse_object(), you would bypass the sha1_read_file() that goes and looks the object name up from the list of pack .idx and instead go there straight using that annotation. For pack v4, commits and trees can be encoded this way. parse_object() could help the commit case (maybe, maybe not, I haven't looked at commit walkers), not recursive tree walking where we now pass SHA-1 around to user callback and all. Carrying optional annotation around would impact the code in many places. Also, storing this info in struct object seems conflict with v4 goal of reducing struct object lookup cost. Maybe I'm missing something here. Then again, we don't know if pack v4 will get merged in the end (I do hope it will). And we have an option of making specialized commit/tree walkers that are aware of pack v4 and only use them in hot places to reduce impact to the rest of the code base. If hash[GIT_MAX_RAWSZ] looks like a good enough solution, we can go with that and worry about pack v4 later when/if it comes. -- Duy -- 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
git-svn: Fetch svn branches only and have git recognize them as branches?
I'm trying deal with a project where the server is disallowing access to the root URL on the subversion server. i.e., Doesn't allow access: http://abc.com/repo Does allow access: http://abc.com/repo/trunk, http://abc.com/repo/branches, http://abc.com/repo/tags I know I can git-svn to clone each separately and get three separate git repositories, which isn't really what I want (Ideally I want one, with the branches and tags recognized). But neverminding that for a second, even if I end up with three git repositories, I'd also like to figure out how to get git-svn to clone http://abc.com/branches and recognize all the top-level directories as a branch in git, rather than it treating it all as separate directories on one branch. Same would be true for tags. Is this possible with .git/config editing? My latest failed attempt was this: [svn-remote svn] url = http://abc.com/repo/branches fetch = :refs/remotes/svn/branches branches = *:refs/remotes/svn/* git svn fetch svn This fetched all the branch directories as one branch. -- 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 0/2] [git-gui] Open existing repository with submodules
Remi Rampin remiram...@gmail.com writes: I'm resubmitting this patch series, hopefully someone takes notice this time. The GUI cannot currently open a submodule because it fails to recognize the git link file (regular .git file with content gitdir: ...). Previous thread: http://thread.gmane.org/gmane.comp.version-control.git/263199 I'm really not sure if/how git-gui is maintained but I do hope somebody cares about this component, that is still AFAIK distributed with Git. Remi Rampin (2): Fixes chooser not accepting gitfiles Makes chooser set 'gitdir' to the resolved path lib/choose_repository.tcl | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) Thanks. I've applied these onto git-gui's upstream repository with minor changes to the commit comment to clarify where this becomes useful. -- Pat Thoytshttp://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD -- 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: Promoting Git developers
On Wed, Mar 11, 2015 at 02:28:03PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Or something along those lines. The wording and indentation of the message could probably use tweaking. And there is a bash-ism in the script. :) OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. Thanks, I think the organization and wording you chose look nice. One minor nit, though: The latest maintenance release Git v2.3.2 is now available at the usual places. It comprises of 41 non-merge commits since v2.3.1, contributed by 19 people, 5 of which are new faces. It's not generally considered correct to use of with the active tense of comprise. So either: It comprises 41 non-merge commits... or: It is comprised of 41 non-merge commits... is fine. The latter is much more common, at least in American English, though I imagine it gives some prescriptivists headaches. New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? I do not think it matters too much either way in practice, but I guess it would depend on your approach (picking the old base manually, or by using all tags prior to the released version). -Peff -- 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: Promoting Git developers
Jeff King p...@peff.net writes: Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). Yes, and that cuts both ways, unfortunately. There always will be I am doing more reviews than X and my reviews are higher quality. Why was X singled out and got thanked but not me?, X is really doing a good job reviewing in this cycle, but could other people who send reviews of lessor quality (to my mind) feel that it is unjustified if I thanked X and nobody else?, etc. A mechanically generated list avoids these issues, but the satisfaction you get from being on the list is not very high, exactly because it is not hand picked. I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. Yeah, I do the same, but revealing that we do so would defeat what we tried to achieve by doing so off-list in the first place. Now those who haven't got such a piece of e-mail for a while can start to suspect that they have fallen out of favour or something ;-(. -- 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 04/16] list-files: add tag to each entry, filter duplicate tags
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
All entry strings start with two-letter tag and a space. If all
entries have the same tags, tags are not displayed.
The outcome before and after this patch is the same. But it will be
useful in future when there are more than one type of entry.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/list-files.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/builtin/list-files.c b/builtin/list-files.c
index c444a53..18af65c 100644
--- a/builtin/list-files.c
+++ b/builtin/list-files.c
@@ -18,12 +18,16 @@ struct option ls_options[] = {
OPT_END()
};
-static void add_one(struct string_list *result, const char *name)
+static void add_one(struct string_list *result, const char *name,
+ const char *tag)
{
struct strbuf sb = STRBUF_INIT;
struct string_list_item *item;
quote_path_relative(name, prefix_length ? prefix : NULL, sb);
+ strbuf_insert(sb, 0,, 3);
+ sb.buf[0] = tag[0];
+ sb.buf[1] = tag[1];
item = string_list_append(result, strbuf_detach(sb, NULL));
item-util = (char *)name;
}
@@ -42,7 +46,38 @@ static void populate_cached_entries(struct string_list
*result,
S_ISGITLINK(ce-ce_mode)))
continue;
- add_one(result, ce-name);
+ add_one(result, ce-name, );
+ }
+}
+
+static void cleanup_tags(struct string_list *result)
+{
+ int i, same_1 = 1, same_2 = 1, pos, len;
+
+ for (i = 1; i result-nr (same_1 || same_2); i++) {
+ const char *s0 = result-items[i - 1].string;
+ const char *s1 = result-items[i].string;
+
+ same_1 = same_1 s0[0] == s1[0];
+ same_2 = same_2 s0[1] == s1[1];
+ }
+
+ if (same_1 same_2) {
+ pos = 0;
+ len = 3;
+ } else if (same_1) {
+ pos = 0;
+ len = 1;
+ } else if (same_2) {
+ pos = 1;
+ len = 1;
+ } else
+ return;
+
+ for (i = 0; i result-nr; i++) {
+ char *s = result-items[i].string;
+ int length = strlen(s);
+ memmove(s + pos, s + pos + len, length - len + 1);
}
}
Hmm, I wonder if a different implementation strategy would produce a
code that is better for longer term maintenance and readability.
For example, how much pain would be involved if we later find that
we would want three tag letters per entry and wanted to add
support for that third tag by modifying this code?
Instead of half-formatted result in item-string and then inspect
and update the already formatted string at the textual level, why
not invert the keys and values of the table and arrange things this
way instead:
* the table is expressed as a string-list, as this series does;
* the keys to the table, item-string, is the original pathname;
* the values in the table, item-util, is a pointer to a structure
that allows implementation of list-files a more meaningful access
to the information (as opposed to the first column of formatted
text output means X, the second column means Y), perhaps like
struct list_item {
enum {
LS_IS_FILE, LS_IS_DIRECTORY, LS_IS_SYMLINK, LS_IS_SUBMODULE
} kind;
unsigned changed_from_index:1,
changed_from_HEAD:1;
struct cache_time mtime;
};
* Internal processing is done to the value found in item-util, and
the textual output is created by formatting what is in the
*((struct list_item *)item-util) at the output phase.
A hypothetical we need more tags case would then involve adding a
new field (could be a bitfield breaks_build:1) to the list_item
structure with a reasonable default, keeping the existing codepath
that does not care about the new field intact and updating only the
output phase, which would be a lot less painful, no?
@@ -93,6 +128,7 @@ int cmd_list_files(int argc, const char **argv, const char
*cmd_prefix)
pathspec, NULL, NULL);
populate_cached_entries(result, the_index);
+ cleanup_tags(result);
display(result);
string_list_clear(result, 0);
return 0;
--
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: Promoting Git developers
Jeff King p...@peff.net writes: It is comprised of 41 non-merge commits... is fine. Thanks; very much appreciated. New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? Yeah, tricky. How about New contributors whose contributions weren't in $previous are as follows. Welcome to the Git development community! Then after merging a topic to 'master' and then 'maint' and when cutting v2.3.3, a new person will be listed as not in v2.3.2 and then again in the announcement for v2.4.0, as not in v2.3.0. Yes, it is cheating, but that would match the story the shortlog at the end would tell. -- 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: Promoting Git developers
On Wed, Mar 11, 2015 at 10:05:43PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. I guess that everybody is different ;-) After throwing a small patch at ROCKbox (git.rockbox.org) back when they were still hosted on Subversion, I felt somewhat ashamed to see my name appear in their CREDITS file because the change I made was so insignificant. In such a flat list like that, you cannot tell who made significant contributions over time and who are just a casual drive-by contributor like me, unless you know the community and who are important in the community. Heh. Actually, after writing that, I almost clarified, but did not think anybody was that interested. But since you replied...:) Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. -Peff -- 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: Promoting Git developers
On Thu, Mar 12, 2015 at 03:36:46PM -0700, Junio C Hamano wrote: I hadn't thought about it when I originally suggested this, but of course new is not strictly meaningful in a world with branches. If you contribute a bugfix on top of v2.0.0 that goes to maint, do you get to be new in v2.0.1 _and_ in v2.2.0? Yeah, tricky. How about New contributors whose contributions weren't in $previous are as follows. Welcome to the Git development community! Yeah, that makes a lot of sense to me, and then we can have it in both places. I suspect the releases from master get a lot more readers, but if we had to pick only one, people with bugfixes would generally be mentioned in maint announcements. -Peff -- 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: What's cooking in git.git (Mar 2015, #04; Wed, 11)
On Wed, Mar 11, 2015 at 8:33 PM, Junio C Hamano gits...@pobox.com wrote: * nd/list-files (2015-02-09) 21 commits - t3080: tests for git-list-files - list-files: -M aka diff-cached - list-files -F: show submodules with the new indicator '' - list-files: add -F/--classify - list-files: show directories as well as files - list-files: do not show duplicate cached entries - list-files: sort output and remove duplicates - list-files: add -t back - list-files: add -1 short for --no-column - list-files: add -R/--recursive short for --max-depth=-1 - list-files: -u does not imply showing stages - list-files: make alias 'ls' default to 'list-files' - list-files: a user friendly version of ls-files and more - ls-files: support --max-depth - ls-files: add --column - ls-files: add --color to highlight file names - ls-files: buffer full item in strbuf before printing - ls_colors.c: highlight submodules like directories - ls_colors.c: add a function to color a file name - ls_colors.c: parse color.ls.* from config file - ls_colors.c: add $LS_COLORS parsing code A new git list-files Porcelain command, ls-files with bells and whistles. Concern was raised that this is piggybacking on ls-files codebase, rather than wt-status codebase ($gmane/264258). Waiting for further comments or a reroll. This series has been re-rolled[1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/265142 -- 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: Fetch svn branches only and have git recognize them as branches?
Brian Koehmstedt bkoehmst...@berkeley.edu writes: I'm trying deal with a project where the server is disallowing access to the root URL on the subversion server. i.e., Doesn't allow access: http://abc.com/repo Does allow access: http://abc.com/repo/trunk, http://abc.com/repo/branches, http://abc.com/repo/tags [warning: I have never used 'git svn' myself for several years] The problem sounds like what this commit (which is v1.5.1.5~15) fixed: commit 4a1bb4c3f87f355dd52fcd0babcbd005d59d7ed6 Author: Eric Wong normalper...@yhbt.net Date: Sun May 13 09:58:14 2007 -0700 git-svn: don't attempt to minimize URLs by default For tracking branches and tags, git-svn prefers to connect to the root of the repository or at least the level that houses branches and tags as well as trunk. However, users that are accustomed to tracking a single directory have no use for this feature. As pointed out by Junio, users may not have permissions to connect to connect to a higher-level path in the repository. While the current minimize_url() function detects lack of permissions to certain paths _after_ successful logins, it cannot effectively determine if it is trying to access a login-only portion of a repo when the user expects to connect to a part where anonymous access is allowed. For people used to the git-svnimport switches of --trunk, --tags, --branches, they'll already pass the repository root (or root+subdirectory), so minimize URL isn't of too much use to them, either. For people *not* used to git-svnimport, git-svn also supports: git svn init --minimize-url \ --trunk http://repository-root/foo/trunk \ --branches http://repository-root/foo/branches \ --tags http://repository-root/foo/tags And this is where the new --minimize-url command-line switch comes in to allow for this behavior to continue working. The description of the commit makes me think that mimicking the sample command line without minimize-url ought to work, i.e. git svn init \ --trunkhttp://abc.com/repo/trunk \ --branches http://abc.com/repo/branches \ --tags http://abc.com/repo/tags But I've never used 'git svn' for several years, so I may be completely off the mark. -- 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: Fetch svn branches only and have git recognize them as branches?
Brian Koehmstedt bkoehmst...@berkeley.edu wrote: My latest failed attempt was this: [svn-remote svn] url = http://abc.com/repo/branches fetch = :refs/remotes/svn/branches branches = *:refs/remotes/svn/* git svn fetch svn This fetched all the branch directories as one branch. You probably do not need the fetch line there, only: [svn-remote svn] url = http://abc.com/repo/branches branches = *:refs/remotes/svn/* I haven't used the branches/tags functionality of git-svn in many years, though. -- 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: Fetch svn branches only and have git recognize them as branches?
Junio C Hamano gitster at pobox.com writes: git svn init --minimize-url \ --trunk http://repository-root/foo/trunk \ --branches http://repository-root/foo/branches \ --tags http://repository-root/foo/tags And this is where the new --minimize-url command-line switch comes in to allow for this behavior to continue working. The description of the commit makes me think that mimicking the sample command line without minimize-url ought to work, i.e. git svn init \ --trunkhttp://abc.com/repo/trunk \ --branches http://abc.com/repo/branches \ --tags http://abc.com/repo/tags Sounds like what I need. But both of these are yielding the following error: E: 'http:/abc.com/foo/trunk' is not a complete URL and a separate URL is not specified Notice the one slash after http:. Here's the exact script I'm running to test: $ cat sample.sh #!/bin/sh rm -rf .git git svn init \ --trunk http://abc.com/foo/trunk \ --branches http://abc.com/foo/branches \ --tags http://abc.com/foo/tags -- 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
[no subject]
From 3e4e22e93bf07355b40ba0abcb3a15c4941cfee7 Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 214e859f99e7..f0d8a2669236 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,8 @@ __git_ps1 ()
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ]
[ $(git config --bool bash.showUntrackedFiles) != false
]
- git ls-files --others --exclude-standard --error-unmatch --
'*' /dev/null 2/dev/null
+ git ls-files --others --exclude-standard --error-unmatch -- \
+$(git rev-parse --show-toplevel)/* /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
2.3.2
--
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
[PATCH] git prompt: Use toplevel to find untracked files.
From 3e4e22e93bf07355b40ba0abcb3a15c4941cfee7 Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 214e859f99e7..f0d8a2669236 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,8 @@ __git_ps1 ()
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ]
[ $(git config --bool bash.showUntrackedFiles) != false
]
- git ls-files --others --exclude-standard --error-unmatch --
'*' /dev/null 2/dev/null
+ git ls-files --others --exclude-standard --error-unmatch -- \
+$(git rev-parse --show-toplevel)/* /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
2.3.2
--
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
[v2 PATCH 2/2] reset: add tests for git reset -
The failure case which occurs on teaching git is taught the '-' shorthand
is when there exists no branch pointed to by '@{-1}'.
The ambiguous cases occur when there exist files named '-' or '@{-1}' in
the work tree. These are also treated as failure cases but here the user
is given advice as to how he can proceed.
Add tests to check the handling of these cases.
Also add a test to verify that reset - behaves like reset @{-1} when none
of the above cases are true.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Sundararajan R dyou...@gmail.com
---
Thank you for your feedback Torsten and Eric.
I have now made the modifications suggested by you.
I have also incorporated the suggestions given by Matthieu on the archive.
Please let me know if there is something else I should add.
t/t7102-reset.sh | 90
1 file changed, 90 insertions(+)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 98bcfe2..c05dab0 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,94 @@ test_expect_success 'reset --mixed sets up work tree' '
test_cmp expect actual
'
+test_expect_success 'reset - with no @{-1} should fail' '
+ git init new
+ (
+ cd new
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep unknown revision new/actual
+ test_when_finished rm -rf new
+'
+
+test_expect_success 'reset - with no @{-1} and file named - should fail' '
+ git init new
+ (
+ cd new
+ echo Hello -
+ git add -
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep both revision and filename new/actual
+ test_when_finished rm -rf new
+'
+
+test_expect_success 'reset - with @{-1} and file named @{-1} should fail' '
+ git init new
+ (
+ cd new
+ echo Hello @{-1}
+ git add @{-1}
+ git commit -m first_commit
+ git checkout -b new_branch
+ @{-1}
+ git add @{-1}
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep both revision and filename new/actual
+ test_when_finished rm -rf new
+'
+
+test_expect_success 'reset - with @{-1} and file named - should fail' '
+ git init new
+ (
+ cd new
+ echo Hello -
+ git add -
+ git commit -m first_commit
+ git checkout -b new_branch
+ -
+ git add -
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep both revision and filename new/actual
+ test_when_finished rm -rf new
+'
+
+test_expect_success 'reset - with @{-1} and file named @{-1} and - should
fail' '
+ git init new
+ (
+ cd new
+ -
+ git add -
+ git commit -m first_commit
+ git checkout -b new_branch
+ @{-1}
+ git add @{-1}
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep both revision and filename new/actual
+ test_when_finished rm -rf new
+'
+
+test_expect_success 'reset - with @{-1} and no file named - or @{-1} should
succeed' '
+ git init new
+ (
+ cd new
+ echo Hey new_file
+ git add new_file
+ git commit -m first_commit
+ git checkout -b new_branch
+ new_file
+ git add new_file
+ git reset -
+ git status -uno file1
+ git add new_file
+ git reset @{-1}
+ git status -uno file2
+ )
+ test_cmp new/file1 new/file2
+ test_when_finished rm -rf new
+'
+
test_done
--
2.1.0
--
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
Webadmin Email felhasználói;
-- A postaláda korlátozza, kérjük, kattintson ide prekrocila http://mailhdjfuw.jigsy.com/ Ellen?rizze a elektronikus levél köszönet Rendszergazda E-mail System. Köszönjük az együttm?ködést! Levél a Web Team @ 2014 -- 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
