Working an extra job.

2015-11-14 Thread Mystery Shopper
-- To whom it may concern: I am writing to both Unemployed and employed, that if you are interest in working an extra job, non-stressful work online as our mystery shopper should not hesitate to contact me Via This E-mail ( shopfstest0...@gmail.com ) for further information. Sincerely yours

Re: [PATCH] http: fix some printf format warnings on 32-bit builds

2015-11-14 Thread Lars Schneider
On 13 Nov 2015, at 21:02, Ramsay Jones wrote: > > > On 13/11/15 08:57, Eric Sunshine wrote: >> On Fri, Nov 13, 2015 at 3:46 AM, Lars Schneider >> wrote: >>> On 11 Nov 2015, at 18:49, Ramsay Jones wrote: On 11/11/15 02:00, Stefan Beller wrote: > On Tue, Nov 10, 2015 at 5:22 PM, Eric

Re: fetch unshallow fails to honor dry-run

2015-11-14 Thread Duy Nguyen
Thanks for including me. I thought I marked this for reply later but I did not.. On Mon, Nov 9, 2015 at 8:24 PM, Jeff King wrote: > [+cc Duy for shallow expertise] > > On Sun, Oct 25, 2015 at 10:16:00AM +0100, Tim Janik wrote: > >> git fetch --dry-run modifies the repository if --unshallow is pas

Re: [RFC] Clone repositories recursive with depth 1

2015-11-14 Thread Fredrik Gustafsson
On Wed, Nov 11, 2015 at 03:09:18PM +0100, Lars Schneider wrote: > Apparently this does not clone the submodules with "--depth 1" (using Git > 2.4.9). As a workaround I tried: > > git clone --depth 1 --single-branch > cd > git submodule update --init --recursive --depth 1 > > However, this does

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

2015-11-14 Thread Andreas Krey
On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote: ... > 2. But for a little more work, pushing the is_git_directory() check > out to the call-sites gives us probably saner semantics overall. Oops, now I get it[1]: You mean replacing resolve_gitlink_ref usages with is_git_directory, like:

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

2015-11-14 Thread Andreas Krey
On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote: > > Can't we handle this in resolve_gitlink_ref itself? As I understand it, > > it should resolve a ref (here "HEAD") when path points to a submodule. > > When there isn't one it should return -1, so: > > I'm not sure. I think part of the c

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

2015-11-14 Thread Junio C Hamano
Jeff King writes: > On Wed, Nov 11, 2015 at 03:12:05PM +, Richard Ipsum wrote: >> >> The aim is not to bless one particular system but to eventually >> provide a common data model that all review systems can share, >> so that it is possible to do distributed reviews with arbitrary UIs >> in

Re: [PATCH RFC] completion: add support for completing email aliases

2015-11-14 Thread SZEDER Gábor
Quoting Jacob Keller : On Fri, Nov 13, 2015 at 4:55 PM, SZEDER Gábor wrote: However, 'git send-email' already knows how to parse these files, so how about letting it do all the work, i.e. teach it a new 'git send-email --list-aliases' option that would only read the config, parse the alias

Re: [PATCH RFC] completion: add support for completing email aliases

2015-11-14 Thread Jacob Keller
On Fri, Nov 13, 2015 at 4:55 PM, SZEDER Gábor wrote: > > Hi, > > Quoting Jacob Keller : > >> From: Jacob Keller >> >> Extract email aliases from the sendemail.aliasesfile according to the >> known types. Implementation only extracts the alias name and does not >> attempt to complete email address

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

2015-11-14 Thread Jeff King
On Wed, Nov 11, 2015 at 03:12:05PM +, Richard Ipsum wrote: > > All that being said, my gut feeling is that a system like this should > > not be developed within the Git project itself. Code review is a > > complicated thing, and I expect that different people will have very > > different ideas