Re: [PATCH v3 0/5] clone: --no-tags option

On Fri, Apr 28, 2017 at 12:27 AM, Brandon Williams wrote: > On 04/26, Ævar Arnfjörð Bjarmason wrote: >> This is an expansion of the previously solo 02/05 "clone: add a >> --no-tags option to clone without tags" patch (see >> <20170418191553.15464-1-ava...@gmail.com>). >> >>

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

On Fri, Apr 28, 2017 at 10:42:10AM +0200, Lars Schneider wrote: > >> A separate mailing list sounds like a very good idea to me! > >> Maybe "git-bui...@vger.kernel.org" or something? > >> What would it take to set something up like this? > > > > I suspect that emailing the vger admins is the

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

> On 25 Apr 2017, at 12:01, Jeff King wrote: > > On Tue, Apr 25, 2017 at 10:51:20AM +0200, Lars Schneider wrote: > Off topic, is it possible to receive mail notifications from Travis when a fault is found in either 'pu', 'next' or 'master'? I know how to do it in

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

René Scharfe: Sure, but if we were to start emitting zip64 records regardless of the size of entries then we'd break compatibility. We should have a very good reason for doing that. (I don't see the need so far.) Sure, sounds good. The type of descriptor to use depends on the presence of

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On 04/27/2017 11:17 PM, Stefan Beller wrote: > Maybe turning on this feature by default is the next step instead of > adding them to bash competition or making them available in plumbing > commands for the upcoming release. Hello. Works for me, please ignore the patch I've sent ;) Anyhow, nice

Re: Submodule/contents conflict

On Thu, Apr 27, 2017 at 11:52:24PM +0100, Philip Oakley wrote: > > But note that none of that should ever affect _what_ gets checked out at > > a file or content level. It may only affect the timestamps on the > > resulting files. And I think those timestamps are not something Git > > makes any

Re: [PATCH] diff: prefer indent heuristic over compaction heuristic

On Thu, Apr 27, 2017 at 02:17:55PM -0700, Stefan Beller wrote: > >> Retire "compaction", and keep "indent" as an experimental feature. > >> The latter hopefully will be turned on by default in a future > >> release, but that should be done as a separate step. > > Maybe turning on this feature by

Re: [PATCH 2/2] Have the diff-* builtins configure diff before initializing revisions.

On Thu, Apr 27, 2017 at 04:50:37PM -0400, Marc Branchaud wrote: > Subject: [PATCH 2/2] Have the diff-* builtins configure diff before > initializing revisions. > > This makes the commands respect diff configuration options, such as > indentHeuristic. > > Signed-off-by: Marc Branchaud

Re: [PATCH 1/2] Make the indent heuristic part of diff's basic configuration.

On Thu, Apr 27, 2017 at 04:50:36PM -0400, Marc Branchaud wrote: > Subject: [PATCH 1/2] Make the indent heuristic part of diff's basic > configuration. > > Signed-off-by: Marc Branchaud This needs to be explained better. Why were the options originally in UI config, and

Re: [PATCH 0/2] Make diff plumbing commands respect the indentHeuristic.

On Thu, Apr 27, 2017 at 04:50:35PM -0400, Marc Branchaud wrote: > So here's my attempt at fixing this. > > The thing I was missing is that init_revisions() calls diff_setup(), which > sets the xdl options. It's therefore necessary to have the > diff_indent_heuristic flag set before calling

Re: [PATCH v2] status: add color config slots for branch info in "--short --branch"

On Thu, Apr 27, 2017 at 07:50:32PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > As we discussed elsewhere, it would be nice if this tested remoteBranch, > > too. IMHO the simplest thing to is to rebase it on the t7508 update I > > just posted. > > > > The other option

Re: [Suggestion] Alternative way for displaying help menu of patch flow

On Friday 28 April 2017 12:07 PM, Jeff King wrote: If the hunk is big, that message scrolls off the screen. We could probably put it after the hunk, but I'd worry that the ordering would be confusing (because it comes between the hunk and the "this hunk" prompt. Probably it could be better to

Re: [Suggestion] Alternative way for displaying help menu of patch flow

On Fri, Apr 28, 2017 at 10:44:22AM +0530, Kaartic Sivaraam wrote: > I guess it would be better to display the help menu in a separate flow, like > when the user click the `?` option in the `patch` flow then the whole screen > is cleared and the help menu is displayed in some appropriate place and

God Bless You and Happy Easter!.

Hello My Dear, This is my second mail but No response,from you Why ?regarding my Easter Donation Gift" Reminding notice/ this is to inform you that i am still in the hospital bed taking a medical treatments because of my Old age illness.Please i need your urgent answer/ i want to know if you

<    1   2