Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required

Am 13.05.2017 um 00:36 schrieb Junio C Hamano: Thanks, all three patches look good. Will queue. Let's merge them to 'next' soonish and eventually down to 'master' and 'maint'. The patches change translated strings. You should probably wait for an update of their translations before you

Re: [PATCH] hashmap: hashmap_get_next passes through keydata as well

On Sat, May 13, 2017 at 1:50 AM, Jeff King wrote: > On Fri, May 12, 2017 at 01:02:44PM -0700, Stefan Beller wrote: > >> The 'keydata' may be of value in the underlying compare function to decide >> if the given two entries are the same. > > I had to scratch my head over this for a

Re: [PATCH] usage.c: drop set_error_handle()

On 13/05/17 04:48, Jeff King wrote: > The set_error_handle() function was introduced by 3b331e926 > (vreportf: report to arbitrary filehandles, 2015-08-11) so > that run-command could send post-fork, pre-exec errors to > the parent's original stderr. > > That use went away in 79319b194

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

On Sat, May 13, 2017 at 1:44 AM, Jonathan Nieder wrote: > Johannes Schindelin wrote: > >> On Windows, `(1|2)` is not a valid file name, and therefore the tag >> cannot be created as expected by the new test. >> >> So simply skip this test on Windows. >> >> Signed-off-by:

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

On Fri, May 12, 2017 at 12:50 PM, Johannes Schindelin wrote: > On Windows, `(1|2)` is not a valid file name, and therefore the tag > cannot be created as expected by the new test. > > So simply skip this test on Windows. Thanks for the hotfix. I'll fix this in my v2,

Re: [PATCH 11/29] grep: add a test helper function for less verbose -f \0 tests

On Fri, May 12, 2017 at 7:06 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Add a helper function to make the tests which check for patterns with >> \0 in them more succinct. Right now this isn't a big win, but >> subsequent commits will

[PATCH] Use https links to Wikipedia to avoid http redirects

Signed-off-by: Sven Strickroth --- Documentation/gitweb.txt | 2 +- bisect.c | 2 +- gitweb/gitweb.perl | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index 96156e5e1..88450589a

Re: [PATCH] doc: use https link to Wikipeai to avoid http redirect

On Sat, May 13, 2017 at 11:54 AM, Sven Strickroth wrote: Spelling error: Wikipeai Looks good, but let's change these too while we're at it: $ git grep http://en.wikip Documentation/gitweb.txt:87:http://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Jonathan Nieder writes: > Johannes Schindelin wrote: >> On Fri, 12 May 2017, Junio C Hamano wrote: > >>> And this one is also important. I do not think we had to touch any >>> code that handles .git/remotes/ or .git/branches when we extended >>> the .git/config based

[PATCH] doc: use https link to Wikipeai to avoid http redirect

Signed-off-by: Sven Strickroth --- Documentation/gitweb.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index 96156e5e1..88450589a 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@

Re: [PATCH v3] fetch-pack: always allow fetching of literal SHA1s

On Thu, May 11, 2017 at 10:00:50AM -0700, Brandon Williams wrote: > > None of this is your problem now either way; the advertisement-limiting > > extension is still vaporware, albeit one we've discussed a lot. I just > > wanted to make sure we weren't painting ourselves into any corners. And > >

Re: What's cooking in git.git (May 2017, #04; Fri, 12)

On Fri, May 12, 2017 at 03:43:21PM +0900, Junio C Hamano wrote: > * sg/clone-refspec-from-command-line-config (2017-05-09) 2 commits > - git-clone --config order & fetching extra refs during initial clone > - clone: respect configured fetch respecs during initial fetch > > "git clone -c

git subtree merge deletes files in top directory

Hi, I'm trying to add a subtree which contains a folder with the same name as the subtree directory itself. Adding seems to work, but if i pull after the subtree remote changed, files in my top directory are deleted and everything seems to have "moved up" one directory - although i specify a

Re: [PATCH v7 00/10] refactor the filter process code into a reusable module

On Mon, May 08, 2017 at 10:58:46AM +0900, Junio C Hamano wrote: > Will queue; during the pre-release freeze, new things would move > slowly, but let's see if we have more comments from others and then > merge it to 'next' soon after the 2.13 final. I gave it a fresh read-through. I had a few

Re: [PATCH v7 09/10] sub-process: move sub-process functions into separate files

On Fri, May 05, 2017 at 11:28:01AM -0400, Ben Peart wrote: > +static void subprocess_exit_handler(struct child_process *process) > +{ > + sigchain_push(SIGPIPE, SIG_IGN); > + /* Closing the pipe signals the subprocess to initiate a shutdown. */ > + close(process->in); > +

Re: [PATCH v7 04/10] convert: move packet_write_line() into pkt-line as packet_writel()

On Fri, May 05, 2017 at 11:27:56AM -0400, Ben Peart wrote: > +int packet_writel(int fd, const char *line, ...); This isn't a new problem, but I noticed that this function should probably get annotated to describe its interface. Junio, can you pick up the patch below on top of Ben's series (or

Re: [PATCH] hashmap: hashmap_get_next passes through keydata as well

On Fri, May 12, 2017 at 01:02:44PM -0700, Stefan Beller wrote: > The 'keydata' may be of value in the underlying compare function to decide > if the given two entries are the same. I had to scratch my head over this for a minute, because there isn't really any motivating example of what you're

Re: [PATCH v6] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 01:46:48PM -0700, Jonathan Tan wrote: > Change from v5: used "ensure_tip_oids_initialized" function instead. > This removes some of the muddiness (e.g. with newlist being modified > after the function). I don't think it really improves the muddiness. You are still calling

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Fri, May 12, 2017 at 11:00:36AM -0700, Jonathan Tan wrote: > > @@ -617,7 +632,8 @@ static void filter_refs(struct fetch_pack_args *args, > > else if (cmp == 0) { > > keep = 1; /* definitely have it */ > >

Re: Best "triangle" workflow setup?

On Fri, May 12, 2017 at 09:53:23AM -0500, Robert Dailey wrote: > Thanks, just curious, where in the git documentation is the "origin" > to "origin/HEAD" resolution documented? I checked the git-revisions > page but it doesn't seem to mention it there. Thanks for explaining > though. In

<    1   2