tiffany uk: fashionables

As one of the numerous agreed on earrings, tiffany uk . adornment is getting when the allow to be aware of any cool gal in any curve within the society. Yet, any Tiffany Earrings Adornment originates out when using the fasted velocity when the fast vali

pandora charms happen to be an exquisite individual variant within the charisma accessory

pandora charms is not really an individual's early days charisma accessory, however , it's quite as exceptional. On earth do you take into account the main charisma accessory everyone used the as the young lady? Which you were which means that proud of every

Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"

On Mon, Feb 4, 2013 at 2:14 PM, Duy Nguyen wrote: > * foo (rebasing) Well, this one does not make sense (or causes more confusion). -- 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.k

Re: [PATCH] Verify Content-Type from smart HTTP servers

Jeff King writes: > I was specifically thinking of this (on top of your patch): > > diff --git a/remote-curl.c b/remote-curl.c > index e6f3b63..63680a8 100644 > --- a/remote-curl.c > +++ b/remote-curl.c > @@ -134,14 +134,12 @@ static struct discovery* discover_refs(const char > *service) >

Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"

On Mon, Feb 4, 2013 at 4:23 AM, Matthieu Moy wrote: > Nguyễn Thái Ngọc Duy writes: > >> --- a/t/t6030-bisect-porcelain.sh >> +++ b/t/t6030-bisect-porcelain.sh >> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing >> ".git/BISECT_START" not modified if >> cp .git/BISECT_START s

Re: Segmentation fault with latest git (070c57df)

Jongman Heo writes: > Jonathan Nieder wrote: >> Jongman Heo wrote: >> >>> Unfortunately, the patch didn't help to me. >> >>Thanks for testing. Did you apply the patch to the older version of >>git that generates builtin/.depend/fetch.o.d or the newer version that >>consumes it? >> >>Curious, >>

Re: Re: Segmentation fault with latest git (070c57df)

Jonathan Nieder wrote: > Jongman Heo wrote: > >> Unfortunately, the patch didn't help to me. > >Thanks for testing. Did you apply the patch to the older version of >git that generates builtin/.depend/fetch.o.d or the newer version that >consumes it? > >Curious, >Jonathan Hi, Jonathan, I applie

Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations

Jens Lehmann writes: > Am 28.01.2013 21:34, schrieb Junio C Hamano: > ... >> I was imagining that "foreach --untracked" could go something like this: >> >> * If you are inside an existing git repository, read its index to >>learn the gitlinks in the directory and its subdirectories. >> >>

pandora charms initiated to provide a couple transfer internet business on 1982

This is often ones own all sorts of things to grasp around tutorial to help you Pandora expensive jewelry, as a result of Pandora bracelets and even pandora charms with the Pandora bangles and even Pandora rings including some past. [url=http://www.genuinepandoracharmssale.co.uk/] pandora charms

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

Greg KH writes: >> Then how about fixing kup to try both versions of Git? There will >> be people who run different versions of Git anyway, and kup should >> not be preventing Git from helping people on other platforms, or >> improving its output in general. > > I think the combinations of diffe

Re: Segmentation fault with latest git (070c57df)

Jongman Heo wrote: > Unfortunately, the patch didn't help to me. Thanks for testing. Did you apply the patch to the older version of git that generates builtin/.depend/fetch.o.d or the newer version that consumes it? Curious, Jonathan -- To unsubscribe from this list: send the line "unsubscribe

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

On Thu, Jan 31, 2013 at 07:33:52PM +0100, René Scharfe wrote: > Am 31.01.2013 18:28, schrieb Greg KH: > > I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546 > > (archive-tar: split long paths more carefully). The diff of a hex dump > > of the tar archives shows the following di

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

On Thu, Jan 31, 2013 at 12:52:15PM -0500, Konstantin Ryabitsev wrote: > On 31/01/13 12:41 PM, Greg KH wrote: > > Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up > > doing lots of kernel releases while traveling), would be a horrible > > change. I'd rather just keep using th

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote: > Greg KH writes: > > > On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: > > > >> How about fixing kup to teach the "let's cheat and let the other end > >> run 'git archive', if the resulting archive and GPG signature

Re: [PATCH] Handle path completion and colon for tcsh script

Thanks for a detailed explanation. The two examples illustrating different interpretation of the same word were really good. Will replace and requeue. -- 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 ht

RE: [PATCH] Handle path completion and colon for tcsh script

> > The problem is, if the directory name *already* has a slash, Bash adds > > another slash! > > So bash users do see the trailing slash because bash adds one to > what we compute and return, which we do strip the trailing slash > exactly because we know bash will add one. The problem is sligh

Re: [PATCH] send-email: ignore files ending with ~

On Mon, Feb 4, 2013 at 2:16 AM, Antoine Pelisse wrote: > On Sun, Feb 3, 2013 at 3:55 PM, Alexandre Courbot wrote: >> It certainly happened to a lot of people already: you carefully prepare >> your set of patches, export them using format-patch --cover-letter, >> write your cover letter, and send

Re: Re: Re: Re: Re: Segmentation fault with latest git (070c57df)

Jonathan Nieder wrote: > Jongman Heo wrote: > >>> But it doesn't stimulate any prerequisites in make, which is weird. >>> What's in builtin/.depend/fetch.o.d? >[...] >> please see below~. >> >> $ cat builtin/.depend/fetch.o.d >> fetch.o: builtin/fetch.c cache.h git-compat-util.h compa

Re: Feature request: Allow extracting revisions into directories

On 02/03/2013 11:41 PM, Robert Clausecker wrote: > > Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty: >> Could you help me understand why piping it to tar (actually 'tar -C >> /dest/dir -x') is not sufficient to achieve what you want? > > Piping the output of git archive into tar

Re: [PATCH 2/3] combine-diff: suppress a clang warning

John Keeping writes: >> If we were to be touching that area of code, I'd rather see a change >> to make it more robust against such a corner case. If it results in >> squelching misguided clang warnings against programmers who should >> not be writing in C, that is a nice side effect, but I loat

Re: Moving (renaming) submodules, recipe/script

On Sun, Feb 03, 2013 at 10:36:17PM +, TJ wrote: > I've recently had need to re-arrange more than ten submodules within > a project and discovered there is apparently no easy way to do it. I ran into a similar problem last month, and wrote a similar script [1] ;). There are a few other related

Re: Feature request: Allow extracting revisions into directories

On Sun, Feb 03, 2013 at 03:18:05PM +0100, Robert Clausecker wrote: > git currently has the archive command that allows to save an arbitrary > revision into a tar or zip file. Sometimes it is useful to not save this > revision into an archive but to directly put all files into an arbitrary > direct

Re: [PATCH 2/3] combine-diff: suppress a clang warning

On Sun, Feb 03, 2013 at 01:07:48PM -0800, Junio C Hamano wrote: > John Keeping writes: > > > A quick search turned up the original thread where this feature was > > added to Clang [1]. It seems that it does find genuine bugs where > > people try to log values by doing: > > > > log("failed to

[RFC] Should "log --cc" imply "log --cc -p"?

I think a natural way to ask reviewing the recent merges while showing tricky ones would be to say: $ git log --first-parent --cc master..pu But this does not to show what I expect to see, which is an output of: $ git log --first-parent --cc -p master..pu This is only a minor ir

Re: [PATCH] git p4: chdir resolves symlinks only for relative paths

mfaze...@szemafor.com wrote on Tue, 29 Jan 2013 09:37 +0100: > If a p4 client is configured to /p/foo which is a symlink > to /vol/bar/projects/foo, then resolving symlink, which > is done by git-p4's chdir will confuse p4: "Path > /vol/bar/projects/foo/... is not under client root /p/foo" > While

[New Feature] git-submodule-move - Easily move submodules

I've recently had need to re-arrange more than ten submodules within a project and discovered there is apparently no easy way to do it. Using some suggestions I found on Stack Overflow I eventually figured out the steps required. Because the steps can be complex I thought it would be handy to ha

Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"

Junio C Hamano writes: > Yeah, I do not think "bisecting other" alone makes much sense. > > What does "other" refer to when you start your bisection at a > detached head? I personally think "other" has _any_ value in that s/_any_/_no_/; obviously ;-) > message, because "(no branch, bisecting)"

Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"

Matthieu Moy writes: > Nguyễn Thái Ngọc Duy writes: > >> --- a/t/t6030-bisect-porcelain.sh >> +++ b/t/t6030-bisect-porcelain.sh >> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing >> ".git/BISECT_START" not modified if >> cp .git/BISECT_START saved && >> test_must_fail

Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"

Nguyễn Thái Ngọc Duy writes: > --- a/t/t6030-bisect-porcelain.sh > +++ b/t/t6030-bisect-porcelain.sh > @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing > ".git/BISECT_START" not modified if > cp .git/BISECT_START saved && > test_must_fail git bisect start $HASH4 foo --

Re: [PATCH 2/3] combine-diff: suppress a clang warning

John Keeping writes: > A quick search turned up the original thread where this feature was > added to Clang [1]. It seems that it does find genuine bugs where > people try to log values by doing: > > log("failed to handle error: " + errno); To be perfectly honest, anybody who writes such a

Re: [PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing

John Keeping writes: > diff --git a/builtin/apply.c b/builtin/apply.c > index 6c11e8b..4745e75 100644 > --- a/builtin/apply.c > +++ b/builtin/apply.c > @@ -1041,15 +1041,17 @@ static int gitdiff_renamedst(const char *line, struct > patch *patch) > > static int gitdiff_similarity(const char *l

Re: [PATCH] Handle path completion and colon for tcsh script

Manlio Perillo writes: > The problem is that when using the "new" > `compopt -o filenames` command, Bash assumes COMPREPLY contains a list > of filenames, and when it detects a directory name, it adds a slash. > > The problem is, if the directory name *already* has a slash, Bash adds > another sl

Re: [PATCH 2/3] combine-diff: suppress a clang warning

On Sun, Feb 03, 2013 at 11:58:15AM -0800, Junio C Hamano wrote: > John Keeping writes: > > > When compiling combine-diff.c, clang 3.2 says: > > > > combine-diff.c:1006:19: warning: adding 'int' to a string does not > > append to the string [-Wstring-plus-int] > > prefix =

Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

Jonathan Nieder writes: > Anand Kumria wrote: > >> I've not been able to find the canonical location of your gitk repository. > > Here's how I find it: > > $ git clone git://repo.or.cz/git.git > [...] > $ cd git > $ git log -1 --oneline -- gitk-git > ec3ae6ec Merge git://o

Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

Hi Anand, Anand Kumria wrote: > I've not been able to find the canonical location of your gitk repository. Here's how I find it: $ git clone git://repo.or.cz/git.git [...] $ cd git $ git log -1 --oneline -- gitk-git ec3ae6ec Merge git://ozlabs.org/~paulus/gitk

Re: [PATCH] Handle path completion and colon for tcsh script

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/02/2013 21:10, Junio C Hamano ha scritto: > Marc Khouzam writes: > >> Recent enhancements to git-completion.bash provide >> intelligent path completion for git commands. Such >> completions do not add the '/' at the end of directories >> for r

Re: [PATCH 2/3] combine-diff: suppress a clang warning

John Keeping writes: > When compiling combine-diff.c, clang 3.2 says: > > combine-diff.c:1006:19: warning: adding 'int' to a string does not > append to the string [-Wstring-plus-int] > prefix = COLONS + offset; >~~~^~~~ > combine-di

Re: Getting started contributing.

Duy Nguyen writes: > On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano wrote: >> On the other hand, there probably still are many loose ends. > > A few other things > > - Mark more strings for translation (not as easy as it sounds, some > strings can't be translated) True, but not a good advice f

Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)

John Keeping writes: > On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote: >> It looks good to go. The additional "|| :" in the makefile is a nice >> touchup that made it more robust too. > > Looks good to me as well. Thanks, both. -- To unsubscribe from this list: send the line "uns

Re: [PATCH] git-send-email: add ~/.authinfo parsing

On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote: > I wrote a Perl credential helper for netrc parsing which is pretty > robust, has built-in docs with -h, and doesn't depend on external > modules. The netrc parser regex was stolen from Net::Netrc. > > It will by default use ~/.authin

Re: [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum

John Keeping wrote: > From: Antoine Pelisse > > Create a GREP_HEADER_FIELD_MIN so we can check that the field value is > sane and silent the clang warning. Thanks. Looks good to me. [...] > --- a/grep.c > +++ b/grep.c > @@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct

Re: [PATCH 2/3] combine-diff: suppress a clang warning

On Mon, Feb 04, 2013 at 02:20:06AM +0800, Tay Ray Chuan wrote: > On Sun, Feb 3, 2013 at 10:37 PM, John Keeping wrote: > > When compiling combine-diff.c, clang 3.2 says: > > > > combine-diff.c:1006:19: warning: adding 'int' to a string does not > > append to the string [-Wstring-plu

Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

Hi Pau, I've not been able to find the canonical location of your gitk repository. I've tried kernel.org, samba.org and ozlabs.org; none of them to have it - nor does any amount of google searching I do reveal the location. I realise you've probably had a busy month with linux.conf.au but it wou

Re: [PATCH 2/3] combine-diff: suppress a clang warning

On Sun, Feb 3, 2013 at 10:37 PM, John Keeping wrote: > When compiling combine-diff.c, clang 3.2 says: > > combine-diff.c:1006:19: warning: adding 'int' to a string does not > append to the string [-Wstring-plus-int] > prefix = COLONS + offset; >

Re: Feature request: Allow extracting revisions into directories

Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty: > Could you help me understand why piping it to tar (actually 'tar -C > /dest/dir -x') is not sufficient to achieve what you want? Piping the output of git archive into tar is of course a possible solution; I just don't like the fa

Re: [PATCH] send-email: ignore files ending with ~

On Sun, Feb 3, 2013 at 3:55 PM, Alexandre Courbot wrote: > It certainly happened to a lot of people already: you carefully prepare > your set of patches, export them using format-patch --cover-letter, > write your cover letter, and send the set like this: > > $ git send-email --to=somerenowneddeve

Re: [PATCH 0/3] Make Git compile warning-free with Clang

Thanks John, I couldn't find any time to send that "sum-up" series. On Sun, Feb 3, 2013 at 3:37 PM, John Keeping wrote: > The first two patches here were sent to the list before but seem to have > got lost in the noise [1][2]. The final one is new but was prompted by > discussion in the same thr

Re: Feature request: Allow extracting revisions into directories

On 02/03/2013 07:48 PM, Robert Clausecker wrote: > Hello! > > git currently has the archive command that allows to save an arbitrary > revision into a tar or zip file. Sometimes it is useful to not save this > revision into an archive but to directly put all files into an arbitrary > directory. Cu

Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines

j...@keeping.me.uk wrote on Fri, 01 Feb 2013 11:16 +: > On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote: > > On 01/30/2013 09:31 PM, John Keeping wrote: > > > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: > > >> [...] maybe we should establish a small Python

[PATCH] send-email: ignore files ending with ~

It certainly happened to a lot of people already: you carefully prepare your set of patches, export them using format-patch --cover-letter, write your cover letter, and send the set like this: $ git send-email --to=somerenowneddeveloper --to=myfutureemployer --cc=thismailinglistiwanttoimpress 00

[PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing

This was prompted by an incorrect warning issued by clang [1], and a suggestion by Linus to restrict the range to check for values greater than INT_MAX since these will give bogus output after casting to int. In fact the (dis)similarity index is a percentage, so reject values greater than 100. [1

[PATCH 2/3] combine-diff: suppress a clang warning

When compiling combine-diff.c, clang 3.2 says: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array

[PATCH 1/3] fix clang -Wtautological-compare with unsigned enum

From: Antoine Pelisse Create a GREP_HEADER_FIELD_MIN so we can check that the field value is sane and silent the clang warning. Clang warning happens because the enum is unsigned (this is implementation-defined, and there is no negative fields) and the check is then tautological. Signed-off-by:

[PATCH 0/3] Make Git compile warning-free with Clang

The first two patches here were sent to the list before but seem to have got lost in the noise [1][2]. The final one is new but was prompted by discussion in the same thread. After applying all of these patches, I don't see any warnings compiling Git with Clang 3.2. [1] http://article.gmane.org/

Feature request: Allow extracting revisions into directories

Hello! git currently has the archive command that allows to save an arbitrary revision into a tar or zip file. Sometimes it is useful to not save this revision into an archive but to directly put all files into an arbitrary directory. Currently this seems to be not possible to archive directly; th

Re: Getting started contributing.

From: "Junio C Hamano" Sent: Sunday, February 03, 2013 7:49 AM adamfraser writes: I've done a little searching and haven't been able to find an official bug tracker for git is there somewhere I can find some bugs to help fix? You came to the right place. A new bug or regression is report

Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)

On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote: > On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano wrote: > > Junio C Hamano writes: > > > > Regarding these two topics > > > >> * da/mergetool-docs (2013-01-30) 7 commits > >> - doc: generate a list of valid merge tools > >> - me

Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)

On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano wrote: > Junio C Hamano writes: > > Regarding these two topics > >> * da/mergetool-docs (2013-01-30) 7 commits >> - doc: generate a list of valid merge tools >> - mergetool--lib: list user configured tools in '--tool-help' >> - fixup! doc: gen

Re: Getting started contributing.

On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano wrote: > On the other hand, there probably still are many loose ends. A few other things - Mark more strings for translation (not as easy as it sounds, some strings can't be translated) - Color more in the output where it makes sense - Stop/Warn