Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 4:48 AM, Jeff King wrote: > - return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0; > + return fnmatch_icase_mem(pattern, patternlen, > +name, namelen, > +FNM_PATHNAME) == 0; > } I think you (or

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 3:45 PM, Duy Nguyen wrote: > On Fri, Mar 29, 2013 at 4:48 AM, Jeff King wrote: >> - return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0; >> + return fnmatch_icase_mem(pattern, patternlen, >> +name, namelen, >> +

Re: Change the committer username

You should read the docs. http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Javier Domingo -- 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/5] difftool improvements

This is a consolidated series replacing jk/t7800-modernize. The patches here have been rebased on master. Patch 1 is new and moves the test added by commit 02c5631 (difftool --dir-diff: symlink all files matching the working tree) to the end of the test file. This means that once this is applied

[PATCH 1/5] t7800: move '--symlinks' specific test to the end

This will group the tests more logically when we introduce a helper to run most --dir-diff tests with both --symlinks and --no-symlinks. Signed-off-by: John Keeping --- t/t7800-difftool.sh | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/t/t780

[PATCH 2/5] difftool: don't overwrite modified files

After running the user's diff tool, git-difftool will copy any files that differ between the working tree and the temporary tree. This is useful when the user edits the file in their diff tool but is wrong if they edit the working tree file while examining the diff. Instead of copying uncondition

[PATCH 3/5] t7800: don't hide grep output

Remove the stdin_contains and stdin_doesnt_contain helper functions which add nothing but hide the output of grep, hurting debugging. Suggested-by: Johannes Sixt Signed-off-by: John Keeping --- t/t7800-difftool.sh | 44 +--- 1 file changed, 17 insertions(

[PATCH 4/5] t7800: fix tests when difftool uses --no-symlinks

When 'git difftool --dir-diff' is using --no-symlinks (either explicitly or implicitly because it's running on Windows), any working tree files that have been copied to the temporary directory are copied back after the difftool completes. Because an earlier test uses "git add .", the "output" file

[PATCH 5/5] t7800: run --dir-diff tests with and without symlinks

Currently the difftool --dir-diff tests may or may not use symlinks depending on the operating system on which they are run. In one case this has caused a test failure to be noticed only on Windows when the test also fails on Linux when difftool is invoked with --no-symlinks. Rewrite these tests

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On 29.03.13 11:03, Duy Nguyen wrote: > On Fri, Mar 29, 2013 at 3:45 PM, Duy Nguyen wrote: >> On Fri, Mar 29, 2013 at 4:48 AM, Jeff King wrote: >>> - return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0; >>> + return fnmatch_icase_mem(pattern, patternlen, >>> +

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 6:32 PM, Torsten Bögershausen wrote: >> Just tested. t0003 and t3001 on 'pu' work for me because I have >> USE_WILDMATCH on (which turns FNM_PATHNAME to WM_PATHNAME). Both break >> without USE_WILDMATCH. >> > Hm, tested what? Tested t0003 and t3001 with and without USE_WIL

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 03:45:35PM +0700, Nguyen Thai Ngoc Duy wrote: > On Fri, Mar 29, 2013 at 4:48 AM, Jeff King wrote: > > - return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0; > > + return fnmatch_icase_mem(pattern, patternlen, > > +name, namele

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 08:05:40AM -0400, Jeff King wrote: > On Fri, Mar 29, 2013 at 03:45:35PM +0700, Nguyen Thai Ngoc Duy wrote: > > > On Fri, Mar 29, 2013 at 4:48 AM, Jeff King wrote: > > > - return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0; > > > + return fnmatch_icase_mem(p

[PATCH] rev-list: preallocate object hash table in --all --objects

Every time the object hash table grows, all entries must be rearranged. The few last times could be really expensive when the table contains a lot of entries. When we do "--all --objects" we know in advance we may need to hash all objects. Just prepare the hash table big enough, so there won't be

[Toy PATCH] Avoid spilling collided entries in object hash table to the next slots

If a position in object hash table is taken, we currently check out the next one. This could potentially create long object chains. We could create linked lists instead and leave the next slot alone. This patch relies on the fact that pointers are usually aligned more than one byte and it uses the

Re: [PATCH] rev-list: preallocate object hash table in --all --objects

On Fri, Mar 29, 2013 at 08:20:10PM +0700, Nguyen Thai Ngoc Duy wrote: > Every time the object hash table grows, all entries must be > rearranged. The few last times could be really expensive when the > table contains a lot of entries. > > When we do "--all --objects" we know in advance we may nee

Re: [PATCH] rev-list: preallocate object hash table in --all --objects

On Fri, Mar 29, 2013 at 10:12 PM, Jeff King wrote: > This feels weirdly specific, and like we should just be tuning our hash > table growth better. You show a 3.2% speedup here. I was able to get a > 2.8% speedup just by doing this: It also uses a lot more memory. 5.8m entries for ".. * 2" and 8.

[PATCH] cherry-pick -x: improve handling of one-liner commit messages

git cherry-pick -x normally just appends the "cherry picked from commit" line at the end of the message, which is fine. However, in case the original commit message had only one line, first append a newline, otherwise the second line won't be empty, which is against recommendations. --- sequencer.

Re: [PATCH] rev-list: preallocate object hash table in --all --objects

Jeff King writes: > This feels weirdly specific, and like we should just be tuning our hash > table growth better. You show a 3.2% speedup here. I was able to get a > 2.8% speedup just by doing this: > > diff --git a/object.c b/object.c > index 20703f5..8e5e12c 100644 > --- a/object.c > +++ b/obj

Minor bug in git branch --set-upstream-to adding superfluous branch section to config

Hello there! Please /cc me with responses as I'm not on the mailing list. I'm using git version 1.8.1.msysgit.1 and I ran into a very minor issue. It doesn't actually seem to affect operations, but I thought I'd report it in case someone felt it was worth cleaning up. If you run the following set

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

Duy Nguyen writes: >> So we would want to do any adjustment to the fix when we merge up to >> maint. > > OK. Then Junio, you may need to resolve the conflict with something > like this. Originally match_basename uses fnmatch, not wildmatch. But > using wildmatch there too should be fine, now that

Re: Minor bug in git branch --set-upstream-to adding superfluous branch section to config

On Fri, Mar 29, 2013 at 09:29:14AM -0700, Phil Haack wrote: > If you run the following set of commands: > > git checkout -b some-branch > git push origin some-branch > git branch --set-upstream-to origin/some-branch > git branch --unset-upstream some-branch > git branch --set-

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 09:44:32AM -0700, Junio C Hamano wrote: > Duy Nguyen writes: > > >> So we would want to do any adjustment to the fix when we merge up to > >> maint. > > > > OK. Then Junio, you may need to resolve the conflict with something > > like this. Originally match_basename uses f

Re: [Toy PATCH] Avoid spilling collided entries in object hash table to the next slots

Nguyễn Thái Ngọc Duy writes: > If a position in object hash table is taken, we currently check out > the next one. This could potentially create long object chains. We > could create linked lists instead and leave the next slot alone. In the current code, not just the logic in lookup_object(),

Re: Minor bug in git branch --set-upstream-to adding superfluous branch section to config

Jeff King writes: > I think what happens is that the config editor runs > through the files linearly, munging whatever lines necessary for the > requested operation, and leaving everything else untouched (as it must, > to leave comments and whitespace intact). But it does not keep a > look-behind

Re: Minor bug in git branch --set-upstream-to adding superfluous branch section to config

On Fri, Mar 29, 2013 at 06:20:28PM +0100, Thomas Rast wrote: > Jeff King writes: > > > I think what happens is that the config editor runs > > through the files linearly, munging whatever lines necessary for the > > requested operation, and leaving everything else untouched (as it must, > > to l

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

Miklos Vajna writes: > git cherry-pick -x normally just appends the "cherry picked from commit" > line at the end of the message, which is fine. However, in case the > original commit message had only one line, first append a newline, > otherwise the second line won't be empty, which is against >

Re: Minor bug in git branch --set-upstream-to adding superfluous branch section to config

Phil Haack writes: > Hello there! Please /cc me with responses as I'm not on the mailing list. > > I'm using git version 1.8.1.msysgit.1 and I ran into a very minor issue. It > doesn't actually seem to affect operations, but I thought I'd report it in > case > someone felt it was worth cleaning

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

Jeff King writes: > On Fri, Mar 29, 2013 at 09:44:32AM -0700, Junio C Hamano wrote: > ... >> With the merge-fix, fnmatch_icase_mem() calls into wildmatch(), but >> fnmatch_icase() still calls into fnmatch(). >> >> The latter's flags are meant to be taken from FNM_* family, but the >> former take

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

On Fri, Mar 29, 2013 at 10:23 AM, Junio C Hamano wrote: > Miklos Vajna writes: > >> git cherry-pick -x normally just appends the "cherry picked from commit" >> line at the end of the message, which is fine. However, in case the >> original commit message had only one line, first append a newline,

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 10:35:17AM -0700, Junio C Hamano wrote: > This may be just the matter of naming. > > It smelled wrong to me only because the "fnmatch" in the helper > fnmatch_icase_mem() told me that it should forever use fnmatch > semantics. After reading its (only) two callsites, they

[PATCH] t1300: document some aesthetic failures of the config editor

The config-editing code used by "git config var value" is built around the regular config callback parser, whose only triggerable item is an actual key. As a result, it does not know anything about section headers, which can result in unnecessarily ugly output: 1. When we delete the last key in

gitdiffbinstat - git diff --shortstat -like output for changes in binary files

I use git mostly for game-development which means I have to deal with a lot of binary files (images, sound files etc). When I came to a point where I had run image optimization on a branch, I wanted to know of course how much smaller the new branch was in comparison to master. Problem was that

Re: [Toy PATCH] Avoid spilling collided entries in object hash table to the next slots

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> If a position in object hash table is taken, we currently check out >> the next one. This could potentially create long object chains. We >> could create linked lists instead and leave the next slot alone. > > In the current code, not j

Re: gitdiffbinstat - git diff --shortstat -like output for changes in binary files

On Fri, Mar 29, 2013 at 07:07:32PM +0100, Matthias Krüger wrote: > I use git mostly for game-development which means I have to deal with > a lot of binary files (images, sound files etc). > > When I came to a point where I had run image optimization on a > branch, I wanted to know of course how m

Re: [PATCH] t1300: document some aesthetic failures of the config editor

Jeff King writes: > diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh > index 3c96fda..d62facb 100755 > --- a/t/t1300-repo-config.sh > +++ b/t/t1300-repo-config.sh > @@ -1087,4 +1087,36 @@ test_expect_success 'barf on incomplete string' ' > grep " line 3 " error > ' > > +# goo

Re: gitdiffbinstat - git diff --shortstat -like output for changes in binary files

On 03/29/2013 07:49 PM, Jeff King wrote: On Fri, Mar 29, 2013 at 07:07:32PM +0100, Matthias Krüger wrote: I use git mostly for game-development which means I have to deal with a lot of binary files (images, sound files etc). When I came to a point where I had run image optimization on a branch

Re: gitdiffbinstat - git diff --shortstat -like output for changes in binary files

Jeff King writes: >> I use git mostly for game-development which means I have to deal with >> a lot of binary files (images, sound files etc). >> >> When I came to a point where I had run image optimization on a >> branch, I wanted to know of course how much smaller the new branch >> was in comp

Re: [PATCH] t1300: document some aesthetic failures of the config editor

On Fri, Mar 29, 2013 at 11:51:51AM -0700, Junio C Hamano wrote: > > + cat >expect <<-\EOF && > > + # some intervening lines > > + # that should be saved > > + EOF > > I do not know if I agree with this expectation. > > Most likely these comments are about the section, and possibly even >

Re: [PATCH] t1300: document some aesthetic failures of the config editor

Junio C Hamano writes: > ... If we _were_ to remove the section header at this point, > we should be removing the comment two out of three cases (if it is > about section.key, it should go when section.key goes; if it is > about section, it should go when section goes; if it is a more > generic

Re: [PATCH 2/5] difftool: don't overwrite modified files

John Keeping writes: > After running the user's diff tool, git-difftool will copy any files > that differ between the working tree and the temporary tree. This is > useful when the user edits the file in their diff tool but is wrong if > they edit the working tree file while examining the diff.

Re: [PATCH] rev-list: preallocate object hash table in --all --objects

On Fri, Mar 29, 2013 at 10:29:52PM +0700, Nguyen Thai Ngoc Duy wrote: > On Fri, Mar 29, 2013 at 10:12 PM, Jeff King wrote: > > This feels weirdly specific, and like we should just be tuning our hash > > table growth better. You show a 3.2% speedup here. I was able to get a > > 2.8% speedup just b

Re: [PATCH] t1300: document some aesthetic failures of the config editor

Jeff King writes: > Here it is with the updated expectation. I don't care _that_ much, so if > you feel strongly and want to drop the first test, feel free. As long as we are adding expect_failure without an immediate fix, let's document the ideal, with this patch on top. t/t1300-repo-config.s

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

Hi, On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey wrote: > > Sign-off? Indeed, I forgot about it, my bad. > > I think this is part of the bc/append-signed-off-by topic that is > > about to graduate to 'master'; more specifically, b971e04f54e7 > > (sequencer.c: always separate "(cherr

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

Miklos Vajna writes: > On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey > wrote: > >> > I think this is part of the bc/append-signed-off-by topic that is >> > about to graduate to 'master'; more specifically, b971e04f54e7 >> > (sequencer.c: always separate "(cherry picked from" from comm

Re: [PATCH 2/2] optimize set_shared_perm()

Torsten Bögershausen writes: > optimize set_shared_perm() in path.c: > > - sometimes the chown() function is called even when not needed. > (This can be provoced by running t1301, and adding some debug code) > > Save a chmod from 400 to 400, or from 600->600 on these files: > .git

Re: [PATCH 2/5] difftool: don't overwrite modified files

On Fri, Mar 29, 2013 at 01:20:50PM -0700, Junio C Hamano wrote: > John Keeping writes: > > > After running the user's diff tool, git-difftool will copy any files > > that differ between the working tree and the temporary tree. This is > > useful when the user edits the file in their diff tool bu

[PATCH 2/5 v2] difftool: don't overwrite modified files

After running the user's diff tool, git-difftool will copy any files that differ between the working tree and the temporary tree. This is useful when the user edits the file in their diff tool but is wrong if they edit the working tree file while examining the diff. Instead of copying uncondition

What's cooking in git.git (Mar 2013, #08; Fri, 29)

What's cooking in git.git (Mar 2013, #08; Fri, 29) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. A handful of topics that have been stalle

Reading remote reflogs

Is it possible to somehow fetch the reflog of a remote? I would like to delegate some post-receive actions to an automatically mirrored clone of some repositories. Mirrored repositories don't maintain a reflog, even with core.logAllRefUpdates = true, so to be able to know what was pushed per push,

Re: Reading remote reflogs

Dennis Kaarsemaker writes: > ... Mirrored repositories don't > maintain a reflog, even with core.logAllRefUpdates = true,... Are you sure about this? When log_all_ref_updates is not set, by default we do not log for bare repositories, but other than that, we do not do anything special with resp

Re: Reading remote reflogs

On vr, 2013-03-29 at 15:45 -0700, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > ... Mirrored repositories don't > > maintain a reflog, even with core.logAllRefUpdates = true,... > > Are you sure about this? When log_all_ref_updates is not set, by > default we do not log for bare repo

Re: Reading remote reflogs

Dennis Kaarsemaker writes: > On vr, 2013-03-29 at 15:45 -0700, Junio C Hamano wrote: >> Dennis Kaarsemaker writes: >> >> > ... Mirrored repositories don't >> > maintain a reflog, even with core.logAllRefUpdates = true,... >> >> Are you sure about this? When log_all_ref_updates is not set, by

Re: Reading remote reflogs

On vr, 2013-03-29 at 15:58 -0700, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > On vr, 2013-03-29 at 15:45 -0700, Junio C Hamano wrote: > >> Dennis Kaarsemaker writes: > >> > >> > ... Mirrored repositories don't > >> > maintain a reflog, even with core.logAllRefUpdates = true,... > >

[PATCH v5 0/5] Verify GPG signatures when merging and extend %G? pretty string

I hope I did not introduce more problems than I fixed in this revision ;) On 03/28/2013 11:33 PM, Junio C Hamano wrote: > It would be much easier to read if it were "unless we are not > looking at the very first byte, the previous byte must be LF", i.e. > > if (found != buf && found[-1] !=

[PATCH v5 2/5] commit.c/GPG signature verification: Also look at the first GPG status line

Signed-off-by: Sebastian Götte --- commit.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/commit.c b/commit.c index e94d122..48f09e9 100644 --- a/commit.c +++ b/commit.c @@ -1027,27 +1027,33 @@ static struct { char result;

[PATCH v5 1/5] Move commit GPG signature verification to commit.c

Signed-off-by: Sebastian Götte --- commit.c| 59 + commit.h| 9 ++ gpg-interface.h | 8 + pretty.c| 91 + 4 files changed, 89 insertions(+), 78 deletions(-) diff --git a/

[PATCH v5 4/5] merge/pull Check for untrusted good GPG signatures

When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte --- Documentation/merge-options.txt| 4 ++-- builtin/merge.c| 2 ++ commit.c | 2 ++ co

[PATCH v5 5/5] pretty printing: extend %G? to include 'N' and 'U'

Expand %G? in pretty format strings to 'N' in case of no GPG signature and 'U' in case of a good but untrusted GPG signature in addition to the previous 'G'ood and 'B'ad. This eases writing anyting parsing git-log output. Signed-off-by: Sebastian Götte --- Documentation/pretty-formats.txt | 3 ++

[PATCH v5 3/5] merge/pull: verify GPG signatures of commits being merged

When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte --- Documentatio

Re: [PATCH] t1300: document some aesthetic failures of the config editor

On Fri, Mar 29, 2013 at 01:35:22PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Here it is with the updated expectation. I don't care _that_ much, so if > > you feel strongly and want to drop the first test, feel free. > > As long as we are adding expect_failure without an immediate f

Re: [Toy PATCH] Avoid spilling collided entries in object hash table to the next slots

On Sat, Mar 30, 2013 at 12:15 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> If a position in object hash table is taken, we currently check out >> the next one. This could potentially create long object chains. We >> could create linked lists instead and leave the next slot alone

Re: [PATCH 4/6] dir.c::match_pathname(): pay attention to the length of string parameters

On Fri, Mar 29, 2013 at 09:44:32AM -0700, Junio C Hamano wrote: > I tend to think in the longer term it may be a good idea to build > with USE_WILDMATCH unconditionally (we can lose compat/fnmatch), so > in the end this may not matter that much I was thinking about that yesterday. After all, it's

Re: [PATCH v5 2/5] commit.c/GPG signature verification: Also look at the first GPG status line

Sebastian Götte writes: > static void parse_gpg_output(struct signature_check *sigc) > { > - const char *buf = sigc->gpg_status; > int i; > > + /* Iterate over all search strings */ > for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) { > + const char *found

Re: [PATCH v5 1/5] Move commit GPG signature verification to commit.c

Sebastian Götte writes: > @@ -230,4 +231,12 @@ extern void print_commit_list(struct commit_list *list, > const char *format_cur, > const char *format_last); > > +/* > + * Check the signature of the given commit. The result of the check is

Re: [PATCH v5 3/5] merge/pull: verify GPG signatures of commits being merged

Sebastian Götte writes: > + OPT_BOOLEAN(0, "verify-signatures", &verify_signatures, > + N_("Verify that the named commit has a valid GPG signature")), Please use OPT_BOOL() in new code. Verifying existing OPT_BOOLEAN() can safely converted to OPT_BOOL() and doing so would be a s

Re: Bug in "git rev-parse --verify"

On 03/28/2013 05:52 PM, Junio C Hamano wrote: > You could force rev-parse to resolve the input to an existing > object, with something like this: > > git rev-parse --verify "$ARG^{}" > > It will unwrap a tag, so the output may end up pointing at a object > that is different from $ARG in suc

Re: Bug in "git rev-parse --verify"

Michael Haggerty writes: > 1. An SHA1 is a canonical representation of the argument, useful for > example as the key in a hash map for for looking for the presence of a > commit in a rev-list output. > > 2. An SHA1 is persistent. For example, I use them when caching > benchmark results across ve

Re: Bug in "git rev-parse --verify"

Junio C Hamano writes: >> 3. Verifying arguments at one spot centralizes error-checking at the >> start of a script and eliminates one reason for random git commands to >> fail later (when error recovery is perhaps more difficult). > > Not necessarily, unless your script is a very narrow corner c

You might Select links of london charm bracelet In between An array of Searching

Kochi along with Trivandrum are the actual popular websites meant for searching with this specific The lord's Distinctive Condition. Searching Along with Tamil Nadu. This particular handicrafts associated with Tamil Nadu may get rid of the drop inside your budget. Towards the top of superb along wi

Re: Bug in "git rev-parse --verify"

On 03/30/2013 05:09 AM, Junio C Hamano wrote: > So why not verify arguments while making sure of their type early > with 'rev-parse --verify "$userinput^{desiredtype}"? Yes, that's a better solution in almost all cases. Thanks for the tip. (It doesn't change my opinion that the documentation for

thomas sabo sale Are Verified When Obtaining Well-known To Its Avidnes

This is a reasonably irritating thing should you ever're unable to choose a great reward * thomas sabo charms * goods in your personalized buddy and also cherished one particular, becoming transferred in nearly special day. The initial thomas sabo charms

Sources of pandora sale For Kids, Bags For girls

Making a decision to buy gifts for teenage girls can be very difficult. When you want to give them something special, you might consider * pandora uk * for kids. These options are great options for that gift that you want to be extra special. Whether you

Re: Bug in "git rev-parse --verify"

Michael Haggerty writes: > On 03/30/2013 05:09 AM, Junio C Hamano wrote: >> So why not verify arguments while making sure of their type early >> with 'rev-parse --verify "$userinput^{desiredtype}"? > > Yes, that's a better solution in almost all cases. Thanks for the tip. > > (It doesn't change

[PATCH] rev-parse: clarify documentation for the --verify option

The old version could be read to mean that the argument has to refer to a valid object, but that is incorrect: * the object is not necessarily read (e.g., to check for corruption) * if the argument is a 40-digit string of hex digits, then it is accepted whether or not is is the name of an exist

tiffany jewellery uk Making you Appealing Ladies

Speaking of ladies, elegance as well as love is going to be regarded as their own alternatives. Within their whole life, these people go after the beauty as well as style. Jewellery is actually their own required item. Tiffany jewellery is among the most widely used styles amongst a lot of types o