[ANNOUNCE] Git v2.15.0-rc0

An early preview release Git v2.15.0-rc0 is now available for testing at the usual places. It is comprised of 672 non-merge commits since v2.14.0, contributed by 66 people, 20 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

Taylor Blau writes: > It may make sense to send my other series to 'master' as well > ("ref-filter.c: pass empty-string as NULL to atom parsers"). Thanks for reminding. I was involved in the review and remember that everybody was happy with the direction. The topic was left

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

"Robert P. J. Day" writes: >> If this were --include=untracked vs --include=all, then I'd say your >> suggestion will violate the usual expectation of "on the command >> line, last one wins", but "--include-untracked" and "--all" are >> spelled very differently, and may

3% Interest Rate

We can help you with a genuine loan to meet your needs. Do you need a personal or business loan without stress and quick approval? Do you need an urgent loan today? No Credit Checks * LOAN APPROVAL IN 60MINS !! * GUARANTEED SAME DAY TRANSFER !! * 100% APPROVAL RATE !! *LOW INTEREST RATE !!

lstat-ing delayed-filter output, was Re: playing with MSan

On Wed, Oct 04, 2017 at 08:30:05PM +0100, Thomas Gummerer wrote: > > So I dunno. This approach is a _lot_ more convenient than trying to > > rebuild all the dependencies from scratch, and it runs way faster than > > valgrind. It did find the cases that led to the patches in this > > series, and

Re: Line ending normalization doesn't work as expected

Junio C Hamano writes: > Both this and its "git read-tree --empty" cousin share a grave > issue. The "git add ." step would mean that before doing these > commands, your working tree must be truly clean, i.e. the paths > in the filesystem known to the index must match what is

Deleting a branch after merging it results in "there may be uncommitted changes"

Hello, I'm trying to understand Git and the mess I've made. Some time ago, I did crazy things like adding to master even though I was working in develop, leaving it a commit ahead and X commits behind. I did crazier things, like trying to amend a previous post's message. Anyway, I follow a very

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

Junio C Hamano wrote: > From: Taylor Blau > Date: Mon, 2 Oct 2017 09:10:34 -0700 > Subject: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers > > Peff points out that different atom parsers handle the empty > "sub-argument" list differently. An example of this is

Re: [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers

Johannes Schindelin writes: > Note: the `%(push:remote-name)` placeholder is only interpolated by the value > of `branch..pushRemote`; unlike `git push`, it does not fall back to > `branch..remote`. Likewise, `%(push:remote-ref)` interpolates to the > empty string

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

Taylor Blau writes: > On Tue, Oct 03, 2017 at 08:55:01AM +0900, Junio C Hamano wrote: >> Jonathan Nieder writes: >> >> > The above does a nice job of explaining >> > >> > - what this change is going to do >> > - how it's good for the internal code

Re: Line ending normalization doesn't work as expected

Junio C Hamano wrote: > Jonathan Nieder writes: >> git checkout --renormalize . >> git status; # Show files that will be normalized >> git commit; # Commit the result >> >> What do you think? Would you be interested in writing a patch for it? >> ("No" is as

Re: cmd.exe Terminal is closing when cloning a repository on windows 10 (64.bit)

Hi, On Thu, 5 Oct 2017, Johannes Schindelin wrote: > On Mon, 2 Oct 2017, André Netzeband wrote: > > > I installed git for windows 2.14.2 (64bit) and was trying to clone a > > repository from a command terminal (cmd.exe): > > > > git clone > >

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: > One solution, which you can tell your team, is this one: > $ git rm -r --cached . && git add . Both this and its "git read-tree --empty" cousin share a grave issue. The "git add ." step would mean that before doing these commands, your working tree

Re: Line ending normalization doesn't work as expected

Jonathan Nieder writes: > I suspect what we are dancing around is the need for some command like > > git checkout --renormalize . > > which would shorten the sequence to > > git checkout --renormalize . > git status; # Show files that will be normalized >

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

Derrick Stolee writes: > On 10/4/2017 2:07 AM, Junio C Hamano wrote: >> Derrick Stolee writes: >> >>> - exists = has_sha1_file(sha1); >>> - while (len < GIT_SHA1_HEXSZ) { >>> - struct object_id oid_ret; >>> - status =

Re: [PATCH v2] branch: change the error messages to be more meaningful

Kaartic Sivaraam writes: > Moreover, as a consequence of my assumption that the tests don't check > for the error messages themselves; I haven't even thought of checking > whether the tests or the travis-ci build succeeded as a consequence of > my patches that

Re: cmd.exe Terminal is closing when cloning a repository on windows 10 (64.bit)

Hi André, On Mon, 2 Oct 2017, André Netzeband wrote: > I installed git for windows 2.14.2 (64bit) and was trying to clone a > repository from a command terminal (cmd.exe): > > git clone https://netzeb...@bitbucket.org/Netzeband/deep-speeddreams.git > > First everything went well, but after the

RE

Your email has been randonly selected for my foundation Donation reply to email: eriling.persson...@swedenmail.com for more details

Re: hacktoberfest

seems my last answer was blocked due to HTML :( here's the answer: Seems a nice start yes. I've been on vacations, but next week I will go trough the current issues and add the hacktoberfest label to some issues if you agree. I went through the open issues a few moments ago. Some were closed

Re: Line ending normalization doesn't work as expected

On Wed, Oct 04, 2017 at 11:26:55AM -0500, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > > Torsten Bögershausen writes: > > > >>> $ git rm -r --cached . && git add . > >> > >> (Both should work) > >> > >> To be honest, from the

Re: [PATCH 1/3] path.c: fix uninitialized memory access

Junio C Hamano wrote: > From: Jeff King > Date: Tue, 3 Oct 2017 19:30:40 -0400 > Subject: [PATCH] path.c: fix uninitialized memory access > > In cleanup_path we're passing in a char array, run a memcmp on it, and > run through it without ever checking if something is in the array

Re: [PATCH 3/3] sub-process: allocate argv on the heap

On 10/04, Junio C Hamano wrote: > Johannes Sixt writes: > > > Am 03.10.2017 um 21:57 schrieb Thomas Gummerer: > >> diff --git a/sub-process.c b/sub-process.c > >> index 6dde5062be..4680af8193 100644 > >> --- a/sub-process.c > >> +++ b/sub-process.c > >> @@ -77,7 +77,9 @@ int

Re: playing with MSan, was Re: [PATCH 0/3] fixes for running the test suite with --valgrind

On 10/04, Jeff King wrote: > On Tue, Oct 03, 2017 at 07:41:54PM -0400, Jeff King wrote: > > > I think using SANITIZE=memory would catch these, but it needs some > > suppressions tuning. The weird "zlib reads uninitialized memory" error > > is a problem (valgrind sees this, too, but we have

Re: [PATCH 1/3] path.c: fix uninitialized memory access

On 10/04, Junio C Hamano wrote: > Jonathan Nieder writes: > > > Jeff King wrote: > >> On Tue, Oct 03, 2017 at 03:45:01PM -0700, Jonathan Nieder wrote: > > > >>> In other words, an alternative fix would be > >>> > >>> if (*path == '.' && path[1] == '/') { > >>>

Weird behavior/bug for git clean in untracked directory

Hello I'm a little bit confused about the behavior of git clean when trying to clean multiple files/directories at once. For instance if I create two directories with an empty file in an new git repository as such: mkdir tmprepo cd tmprepo git init mkdir a b touch a/file b/file and

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

On Wed, Oct 04, 2017 at 05:46:21PM +0900, Junio C Hamano wrote: > Jeff King writes: > > >> - pretty.c: delimit "%(trailers)" arguments with "," > >> > >> "git for-each-ref --format=..." learned a new format element, > >> %(trailers), to show only the commit log trailer part of

Re: Line ending normalization doesn't work as expected

On Wed, Oct 4, 2017 at 11:59 AM, Jonathan Nieder wrote: > Hi Robert, > > Robert Dailey wrote: > >> You guys are obviously worlds ahead of me on the internals of things, >> but from my perspective I like to avoid the "plumbing" commands as >> much as I can. > > I suspect what

Re: disable interactive prompting

Thanks for pointing out the option. I tried "git help push" and searched for "prompt", "interactive", "credentials"... I don't think I would have figured to try "git help git" from "git help" even after reading it carefully. I'd suggest adding a hint in "git help". I also don't seem have the

Re: disable interactive prompting

Hi, The prompt asks for my https username/password: > $ grv > originhttps://github.com/user/dotemacs (fetch) > originhttps://github.com/user/dotemacs (push) > $ gpom > [1] 22549 > $ Username for 'https://github.com': > $ fg > { git push origin master &>/dev/null < /dev/null;

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

On Mon, 2 Oct 2017, Junio C Hamano wrote: > Thomas Gummerer writes: > > > This is fine when --include-untracked is specified first, as --all > > implies --include-untracked, but I guess the behaviour could be a > > bit surprising if --all is specified first and

Re: disable interactive prompting

On Wed, Oct 04, 2017 at 09:10:48AM -0700, Ernesto Alfonso wrote: > Waiting for git-push synchronously slows me down, so I have a bash > alias/function to do this in the background. But when my origin is https, I > get an undesired interactive prompt. I've tried to disable by > redirecting stdin:

Re: disable interactive prompting

Hi Ernesto, Ernesto Alfonso wrote: > Waiting for git-push synchronously slows me down, so I have a bash > alias/function to do this in the background. But when my origin is https, I > get an undesired interactive prompt. I've tried to disable by > redirecting stdin: > > git push ${REMOTE}

Re: Line ending normalization doesn't work as expected

Hi Robert, Robert Dailey wrote: > You guys are obviously worlds ahead of me on the internals of things, > but from my perspective I like to avoid the "plumbing" commands as > much as I can. I suspect what we are dancing around is the need for some command like git checkout

Re: Line ending normalization doesn't work as expected

On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > Torsten Bögershausen writes: > >>> $ git rm -r --cached . && git add . >> >> (Both should work) >> >> To be honest, from the documentation, I can't figure out the difference >> between >> $ git read-tree

disable interactive prompting

Hi, Waiting for git-push synchronously slows me down, so I have a bash alias/function to do this in the background. But when my origin is https, I get an undesired interactive prompt. I've tried to disable by redirecting stdin: git push ${REMOTE} ${BRANCH} &>/dev/null

Re: distinguishing between staged and unstaged content in a stash?

On Wed, 4 Oct 2017, Kevin Daudt wrote: > On Wed, Oct 04, 2017 at 07:10:46AM -0400, rpj...@crashcourse.ca wrote: > > > > couple (admittedly trivial) questions about stashing. first, can > > i clarify that when one stashes content, a stash *always* > > distinguishes between what was staged, and

Re: Enhancement request: git-push: Allow (configurable) default push-option

Hi Stefan, I will look at it. Thanks, Marius 2017-10-03 18:53 GMT+02:00 Stefan Beller : > On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga wrote: >> There is a need to pass predefined push-option during "git push" >> without need to specify it

Re: distinguishing between staged and unstaged content in a stash?

On Wed, Oct 04, 2017 at 07:10:46AM -0400, rpj...@crashcourse.ca wrote: > > couple (admittedly trivial) questions about stashing. first, can i > clarify that when one stashes content, a stash *always* distinguishes > between what was staged, and what was unstaged? that is, when one is >

Re: [PATCH v2] setup: update error message to be more meaningful

On Tue, 2017-10-03 at 09:32 +0900, Junio C Hamano wrote: > > As an aside, I wonder if we want to _() the message. It's outside > the scope of this fix, obviously. > I'm surprised it isn't already! I think it should. As an aside, I wanted to know whether we should add 'test_expect_failure's

Re: [PATCH] test-list-objects: mark file-local symbols as static

On 10/3/2017 5:51 PM, Ramsay Jones wrote: Signed-off-by: Ramsay Jones --- Hi Derrick, If you need to re-roll your 'ds/find-unique-abbrev-optim' branch, could you please squash this into the relevant patch (commit 3792c78ba0, "test-list-objects: list a subset of

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 04 Oct 2017, at 13:55, Junio C Hamano wrote: > > Lars Schneider writes: > >>> The delayed progress API is being simplified so I'll probably do a >>> bit of evil merge while merging this to 'pu'. >> >> I just realized that this patch got lost

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

On 10/3/2017 7:42 PM, Jonathan Tan wrote: On Tue, Oct 3, 2017 at 7:39 AM, Jeff Hostetler wrote: As I see it there are the following major parts to partial clone: 1. How to let git-clone (and later git-fetch) specify the desired subset of objects that it wants?

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

On 10/4/2017 2:07 AM, Junio C Hamano wrote: Derrick Stolee writes: - exists = has_sha1_file(sha1); - while (len < GIT_SHA1_HEXSZ) { - struct object_id oid_ret; - status = get_short_oid(hex, len, _ret, GET_OID_QUIETLY); -

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

On 10/4/2017 2:10 AM, Junio C Hamano wrote: Derrick Stolee writes: ... I understand that this patch on its own does not have good numbers. I split the patches 3 and 4 specifically to highlight two distinct changes: Patch 3: Unroll the len loop that may inspect all files

Re: [PATCH v8 00/12] Fast git status via a file system watcher

On 10/4/2017 2:38 AM, Alex Vandiver wrote: On Wed, 4 Oct 2017, Junio C Hamano wrote: Rats indeed. Let's go incremental as promised, perhaps like this (but please supply a better description if you have one). I think you'll also want the following squashed into 5c8cdcfd8 and def437671: --

Re: [PATCH v2] branch: change the error messages to be more meaningful

On Wed, 2017-10-04 at 13:11 +0900, Junio C Hamano wrote: > > It is a bit dissapointing that we do not need to touch tests, as it > indicates that the logic to diagnose extra arguments as an error has > no coverage. Even if there were tests I don't think they would have needed any updation as

Ahoj drahý!!

Hi Dear!! Nice meeting you as i got your email through my personal search, my name is Katie Higgins, i am (Blue Angels United officer), working for U.S Navy base camp here in Syria.. i urgently seek your assistance, please kindly write me at your convenience,look forward reading from you soon.

Re: [PATCH v8 00/12] Fast git status via a file system watcher

On 10/3/2017 10:09 PM, Junio C Hamano wrote: Ben Peart writes: Well, rats. I found one more issue that applies to two of the commits. Can you squash this in as well or do you want it in some other form? Rats indeed. Let's go incremental as promised, perhaps like this

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

Lars Schneider writes: >> The delayed progress API is being simplified so I'll probably do a >> bit of evil merge while merging this to 'pu'. > > I just realized that this patch got lost :-( Really? Isn't it 52f1d62e ("convert: display progress for filtered objects

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 04 Oct 2017, at 12:52, Lars Schneider wrote: > > >> On 24 Aug 2017, at 21:40, Junio C Hamano wrote: >> >> Lars Schneider writes: >> >>> In 2841e8f ("convert: add "status=delayed" to filter process protocol", >>>

Re: [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name.

Junio C Hamano writes: >> +if (explicit) >> +*s = xstrdup(merge); >> +else >> +*s = ""; > > Here is the same "who are we trying to help---users who want to know > where their push goes, or users who are debugging

distinguishing between staged and unstaged content in a stash?

couple (admittedly trivial) questions about stashing. first, can i clarify that when one stashes content, a stash *always* distinguishes between what was staged, and what was unstaged? that is, when one is stashing, the "--keep-index" option relates to whether or not staged changes are left in

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 24 Aug 2017, at 21:40, Junio C Hamano wrote: > > Lars Schneider writes: > >> In 2841e8f ("convert: add "status=delayed" to filter process protocol", >> 2017-06-30) we taught the filter process protocol to delayed responses. >> These responses

playing with MSan, was Re: [PATCH 0/3] fixes for running the test suite with --valgrind

On Tue, Oct 03, 2017 at 07:41:54PM -0400, Jeff King wrote: > I think using SANITIZE=memory would catch these, but it needs some > suppressions tuning. The weird "zlib reads uninitialized memory" error > is a problem (valgrind sees this, too, but we have suppressions). I dug into this a little

Re: Is git am supposed to decode MIME?

Florian Weimer writes: > The git am documentation talks about “mailboxes”. I suppose these > contain messages in Internet Mail syntax. Is git am supposed to > decode MIME? > > I'm asking because I have a message whose body is encoded as > quoted-printable, but git am does

Re: Is git am supposed to decode MIME?

On Wed, Oct 04, 2017 at 10:44:31AM +0200, Florian Weimer wrote: > The git am documentation talks about “mailboxes”. I suppose these contain > messages in Internet Mail syntax. Is git am supposed to decode MIME? > > I'm asking because I have a message whose body is encoded as >

Re: [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name.

Johannes Schindelin writes: > From: J Wyman > > There are times when scripts want to know not only the name of the > push branch on the remote, but also the name of the branch as known > by the remote repository. > > A useful example of this is

Re: [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name

Junio C Hamano writes: >> +} else if (atom->u.remote_ref.option == RR_REMOTE_NAME) { >> +int explicit; >> +const char *remote = starts_with(atom->name, "push") ? >> +pushremote_for_branch(branch, ) : >> +

Re: [PATCH v2] oidmap: map with OID as key

Jeff King writes: > On Tue, Oct 03, 2017 at 05:29:01PM -0700, Jonathan Tan wrote: > >> At this point I decided that I prefer the thin wrapper, but the "light >> touch" (struct oidmap_entry, oidcmpfn(), oidmap_get() only) still >> better than the status quo. > > OK. I can certainly

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

Jeff King writes: >> - pretty.c: delimit "%(trailers)" arguments with "," >> >> "git for-each-ref --format=..." learned a new format element, >> %(trailers), to show only the commit log trailer part of the log >> message. >> >> Will merge to 'next'. > > I think we want the

Is git am supposed to decode MIME?

The git am documentation talks about “mailboxes”. I suppose these contain messages in Internet Mail syntax. Is git am supposed to decode MIME? I'm asking because I have a message whose body is encoded as quoted-printable, but git am does not parse the patch contained in it. If git am is

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

On Wed, Oct 04, 2017 at 04:19:52PM +0900, Junio C Hamano wrote: > I wanted to do v2.15-rc0 today but it seems that this has to slip, > with too many topics still in flight in 'next' among which many are > fixes, one is even a fix for a recent regression. You probably already figured this out,

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

On Wed, Oct 04, 2017 at 04:02:12AM -0400, Jeff King wrote: > On Wed, Oct 04, 2017 at 04:19:52PM +0900, Junio C Hamano wrote: > > > * jt/partial-clone-lazy-fetch (2017-10-02) 18 commits > [...] > > The merge of this topic into jch (at 766f92478b0) causes the test suite > to fail when compiled

Re: Git for Windows: mingw.c's strange usage of creation time as ctime?

Hello Jonathan, On 04.10.2017 04:23, Jonathan Nieder wrote: +git-for-windows Hi Marc, Marc Strapetz wrote: compat/mingw.c assigns the Windows file creation time [1] to Git's ctime fields at line 591 and at line 705: buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

On Wed, Oct 04, 2017 at 04:19:52PM +0900, Junio C Hamano wrote: > * jt/partial-clone-lazy-fetch (2017-10-02) 18 commits > - fetch-pack: restore save_commit_buffer after use > - unpack-trees: batch fetching of missing blobs > - clone: configure blobmaxbytes in created repos > - clone: support

Re: [PATCH v2] oidmap: map with OID as key

On Tue, Oct 03, 2017 at 05:29:01PM -0700, Jonathan Tan wrote: > At this point I decided that I prefer the thin wrapper, but the "light > touch" (struct oidmap_entry, oidcmpfn(), oidmap_get() only) still > better than the status quo. OK. I can certainly live with that. And worst case, I suppose,

What's cooking in git.git (Oct 2017, #01; Wed, 4)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. I wanted to do v2.15-rc0 today

Re: [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name

Johannes Schindelin writes: > This patch offers the new suffix :remote for the upstream and for the > push atoms, allowing to show exactly that. Has the design changed since this description and examples were written? The documentation talks about ":remote-name". I

Re: [PATCH v8 00/12] Fast git status via a file system watcher

On Wed, 4 Oct 2017, Junio C Hamano wrote: > Rats indeed. Let's go incremental as promised, perhaps like this > (but please supply a better description if you have one). I think you'll also want the following squashed into 5c8cdcfd8 and def437671: -- >8 -- >From

Re: [PATCH 2/3] http-push: fix construction of hex value from path

Jeff King writes: > More seriously, is there any interest in marking it as deprecated in the > release notes and issuing a warning when it's used for a few cycles? No objection from me. I do not object with such a well designed deprecation plan for any other features, if there

Re: [PATCH v3 00/10] protocol transition

Thanks. All of my review comments from the previous round seem to have been addressed, so this is Reviewed-by: me ;-)

Re: [PATCH v3 4/5] sha1_name: Parse less while finding common prefix

Derrick Stolee writes: > diff --git a/sha1_name.c b/sha1_name.c > index f2a1ebe49..5081aeb71 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -480,13 +480,23 @@ struct min_abbrev_data { > char *hex; > }; > > +static inline char get_hex_char_from_oid(const

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

Derrick Stolee writes: > On 10/3/2017 6:49 AM, Junio C Hamano wrote: >> Derrick Stolee writes: >> >>> p0008.1: find_unique_abbrev() for existing objects >>> -- >>> >>> For 10 repeated tests, each checking

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

Derrick Stolee writes: > -int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len) > +struct min_abbrev_data { > + unsigned int init_len; > + unsigned int cur_len; > + char *hex; > +}; > + > +static int extend_abbrev_len(const struct object_id