Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Am 26.09.2017 um 00:50 schrieb Stefan Beller: submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in

Re: [PATCH 4/4] Move documentation of string_list into string-list.h

Junio C Hamano writes: > > Thanks. I am not sure if you can safely reorder the contents of the > header files in general, but I trust that you made sure that this > does not introduce problems (e.g. referrals before definition). Alas, this time it seems my trust was grossly

Re: '--shallow-since' option is not available for git-pull in Git version 2.14.1

On Mon, Sep 25, 2017 at 04:31:10PM +0900, Sanggyu Nam wrote: > I’ve found that some subcommands such as git-clone, git-fetch, and > git-pull support an option named ‘--shallow-since’, as of Git version > 2.11. This option is documented in the man page of each subcommand. In > Git 2.14.1, I’ve

Re: [PATCH 4/4] Move documentation of string_list into string-list.h

Han-Wen Nienhuys writes: > This mirrors commit bdfdaa4978dd92992737e662f25adc01d32d0774 which did > the same for strbuf.h: > > * API documentation uses /** */ to set it apart from other comments. > > * Function names were stripped from the comments. > > * Ordering of the

Re: [PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently

Han-Wen Nienhuys writes: >>Subject: Re: [PATCH 2/4] Clarify return value ownership of real_path and >>read_gitfile_gently We try to make "shortlog --no-merges" output consistently say what area the change is about, followed by a colon, followed by a short description. >

Re: [PATCH] fast-import: checkpoint: dump branches/tags/marks even if object_count==0

"Eric Rannaud" writes: > The checkpoint command cycles packfiles if object_count != 0, a sensible > test or there would be no pack files to write. Since 820b931012, the > command also dumps branches, tags and marks, but still conditionally. > However, it is possible for a

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King writes: >> #ifndef EUNDERFLOW >> # ifdef ENODATA >> # define EUNDERFLOW ENODATA >> # else >> # define EUNDERFLOW ESPIPE >> # endif >> #endif > > Right, I think our mails just crossed but I'm leaning in this direction. Hmph, I may be slow (or may be skimming the

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

Yaroslav Halchenko writes: > 1. As a workaround for absence of -m theirs I using mtheirs git alias: > (I believe provided to me awhile back here on the list): > > mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u > $1' - > > and it worked fine

[PATCH] fast-import: checkpoint: dump branches/tags/marks even if object_count==0

The checkpoint command cycles packfiles if object_count != 0, a sensible test or there would be no pack files to write. Since 820b931012, the command also dumps branches, tags and marks, but still conditionally. However, it is possible for a command stream to modify refs or create marks without

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

Junio C Hamano writes: > Junio C Hamano writes: > >> I do not recall people talking about symbolic links but the case of >> binary files has been on the wishlist for a long time, and I do not >> know of anybody who is working on (or is planning to work on)

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

Junio C Hamano writes: > I do not recall people talking about symbolic links but the case of > binary files has been on the wishlist for a long time, and I do not > know of anybody who is working on (or is planning to work on) it. Ah, I misremembered. We've addressed the

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

Yaroslav Halchenko writes: > yes it does. Thanks. And that is where I realized that I should have used -X > theirs (not -s theirs), as the instruction on the option for the > (recursive) merge. And now problem is more specific: > > - conflict within file content editing

Re: [PATCH] Documentation: consolidate submodule..update

Brandon Williams writes: >> +The method by which a submodule is updated by 'git submodule update', >> +which is the only affected command, others such as >> +'git checkout --recurse-submodules' are unaffected. It exists for >> +historical reasons, when 'git

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > What do you think of patch 7 in light of this? If the short-read case > gives us a sane errno, should we even bother trying to consistently > handle its error separately? I like the read_exactly_or_die variant because it makes callers more concise, but on the other hand a

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 05:20:20PM -0700, Jonathan Nieder wrote: > > What do you think of ENODATA? The glibc text for it is pretty > > appropriate. If it's not available everywhere, we'd have to fallback to > > something else (EIO? 0?). I don't know how esoteric it is. The likely > > candidate to

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 05:17:32PM -0700, Jonathan Nieder wrote: >> #ifndef EUNDERFLOW >> # ifdef ENODATA >> # define EUNDERFLOW ENODATA >> # else >> # define EUNDERFLOW ESPIPE >> # endif >> #endif > > Right, I think our mails just crossed but I'm leaning in this direction. >

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 05:17:32PM -0700, Jonathan Nieder wrote: > Jonathan Nieder wrote: > > On Mon, Sep 25, 2017 at 08:09:13PM -0400, Jeff King wrote: > > >> ENODATA is not too bad. On my glibc system it yields "No data available" > >> from strerror(), which is at least comprehensible. > >> >

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > I definitely would prefer to avoid EIO, or anything that an actual > read() might return. > > What do you think of ENODATA? The glibc text for it is pretty > appropriate. If it's not available everywhere, we'd have to fallback to > something else (EIO? 0?). I don't know how

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jonathan Nieder wrote: > On Mon, Sep 25, 2017 at 08:09:13PM -0400, Jeff King wrote: >> ENODATA is not too bad. On my glibc system it yields "No data available" >> from strerror(), which is at least comprehensible. >> >> We're still left with the question of whether it is defined everywhere >>

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 05:13:54PM -0700, Jonathan Nieder wrote: > > I actually prefer "0" of the all of the options discussed. At least it > > is immediately clear that it is not a syscall error. > > I have a basic aversion to ": Success" in error messages. Whenever I > see such an error

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 08:09:13PM -0400, Jeff King wrote: > On Mon, Sep 25, 2017 at 05:06:58PM -0700, Stefan Beller wrote: >> After reading this discussion from the sideline, maybe >> >> ENODATA No message is available on the STREAM head read >> queue (POSIX.1) >> >> is not too bad

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 04:55:10PM -0700, Jonathan Nieder wrote: >> All that really matters is the strerror() that the user would see. > > Agreed, though I didn't think those were necessarily standardized. The standard allows them to vary for the sake of internationalization,

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 05:06:58PM -0700, Stefan Beller wrote: > >> If you are okay with the too-long/too-short confusion in EOVERFLOW, then > >> there is EMSGSIZE: > >> > >> Message too long > > > > I don't really like that one either. > > > > I actually prefer "0" of the all of the

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 5:01 PM, Jeff King wrote: > >> If you are okay with the too-long/too-short confusion in EOVERFLOW, then >> there is EMSGSIZE: >> >> Message too long > > I don't really like that one either. > > I actually prefer "0" of the all of the options

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Stefan Beller wrote: > submodule..update can be assigned an arbitrary command via setting > it to "!command". When this command is found in the regular config, Git > ought to just run that command instead of other update mechanisms. > > However if that command is just found in the .gitmodules

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 04:55:10PM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > [EOVERFLOW] > > The file is a regular file, nbyte is greater than 0, the starting > > position is before the end-of-file, and the starting position is > > greater than or equal to the offset

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > [EOVERFLOW] > The file is a regular file, nbyte is greater than 0, the starting > position is before the end-of-file, and the starting position is > greater than or equal to the offset maximum established in the open > file description associated with fildes.

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 04:33:16PM -0700, Jonathan Nieder wrote: >> Jef King wrote: >>> errno = 0; >>> read_in_full(fd, buf, sizeof(buf)); >>> if (errno) >>> die_errno("oops"); [...] >>> in general we frown on it for calls like >>> read(). >>

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 07:37:32PM -0400, Jeff King wrote: > > Correct. Actually more than "frown on": except for with the few calls > > like strtoul that are advertised to work this way, POSIX does not make > > the guarantee the above code would rely on, at all. > > > > So it's not just

Re: [PATCH] Documentation: consolidate submodule..update

Stefan Beller wrote: > By as-is I refer to origin/pu. Ah, okay. I'm not in that habit because pu frequently loses topics --- it's mostly useful as a tool to (1) distribute topic branches and (2) check whether they are compatible with each other. [...] > On Mon, Sep 25, 2017 at 3:22 PM,

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

On Mon, Sep 25, 2017 at 2:54 AM, Derrick Stolee wrote: > Create get_hex_char_from_oid() to parse oids one hex character at a > time. This prevents unnecessary copying of hex characters in > extend_abbrev_len() when finding the length of a common prefix. > > p0008.1:

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 04:33:16PM -0700, Jonathan Nieder wrote: > > If I do this: > > > > errno = 0; > > read_in_full(fd, buf, sizeof(buf)); > > if (errno) > > die_errno("oops"); > > > > then we'll claim an error, even though there was none (remember that > > it's only an error for

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: >> --- a/wrapper.c >> +++ b/wrapper.c >> @@ -318,8 +318,10 @@ ssize_t read_in_full(int fd, void *buf, size_t count) >> ssize_t loaded = xread(fd, p, count); >> if (loaded < 0) >> return -1; >> -if (loaded == 0) >> +

Re: [PATCH 7/7] add xread_in_full() helper

On Mon, Sep 25, 2017 at 03:16:08PM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > Many callers of read_in_full() expect to see exactly "len" > > bytes, and die if that isn't the case. > > micronit: Can this be named read_in_full_or_die? > > Otherwise it's too easy to mistake for a

Re: [PATCH 6/7] worktree: check the result of read_in_full()

On Mon, Sep 25, 2017 at 03:14:26PM -0700, Jonathan Nieder wrote: > > diff --git a/builtin/worktree.c b/builtin/worktree.c > > index 2f4a4ef9cd..87b3d70b0b 100644 > > --- a/builtin/worktree.c > > +++ b/builtin/worktree.c > > @@ -59,7 +59,11 @@ static int prune_worktree(const char *id, struct

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 03:09:14PM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > In an ideal world, callers would always distinguish between > > these cases and give a useful message for each. But as an > > easy way to make our imperfect world better, let's reset > > errno to a known

Re: [PATCH 1/7] files-backend: prefer "0" for write_in_full() error check

On Mon, Sep 25, 2017 at 02:59:27PM -0700, Jonathan Nieder wrote: > > But during the conflict resolution in c50424a6f0 (Merge > > branch 'jk/write-in-full-fix', 2017-09-25), this morphed > > into > [...] > Good eyes. Thanks. Sort of. :) I usually continually rebase my topics until they end up

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially untrusted,

Re: [PATCH] Documentation: consolidate submodule..update

On Mon, Sep 25, 2017 at 3:22 PM, Jonathan Nieder wrote: > Stefan Beller wrote: >> On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams wrote: >>> On 09/25, Stefan Beller wrote: > Have one place to explain the effects of setting submodule..update

Re: git ls-tree -d doesn't work if the specified path is the repository root?

Hi, Roy Wellington wrote: > When I run `git ls-tree -d HEAD -- subdir` from the root of my > repository, where `subdir` is a subdirectory in that root, I get the > treehash of that subdirectory. This is what I expect. > > However, if I merely replace `subdir` with `.` (the root of the >

Re: [PATCH] Documentation: consolidate submodule..update

Stefan Beller wrote: > On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams wrote: >> On 09/25, Stefan Beller wrote: >>> Have one place to explain the effects of setting submodule..update >>> instead of two. >>> >>> Signed-off-by: Stefan Beller >>> --- >

Re: [PATCH] Documentation: consolidate submodule..update

On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams wrote: > On 09/25, Stefan Beller wrote: >> Have one place to explain the effects of setting submodule..update >> instead of two. >> >> Signed-off-by: Stefan Beller >> --- >> >> I disagree. Actually, I

Re: [PATCH 7/7] add xread_in_full() helper

Jeff King wrote: > Many callers of read_in_full() expect to see exactly "len" > bytes, and die if that isn't the case. micronit: Can this be named read_in_full_or_die? Otherwise it's too easy to mistake for a function like xread, which has different semantics. I realize that xmalloc, xmemdupz,

Re: [PATCH 6/7] worktree: check the result of read_in_full()

Jeff King wrote: > We try to read "len" bytes into a buffer and just assume > that it happened correctly. In practice this should usually > be the case, since we just stat'd the file to get the > length. But we could be fooled by transient errors or by > other processes racily truncating the

Re: [PATCH 5/7] worktree: use xsize_t to access file size

Jeff King wrote: > To read the "gitdir" file into memory, we stat the file and > allocate a buffer. But we store the size in an "int", which > may be truncated. We should use a size_t and xsize_t(), > which will detect truncation. > > An overflow is unlikely for a "gitdir" file, but it's a good >

Re: [PATCH 4/7] get-tar-commit-id: prefer "!=" for read_in_full() error check

Jeff King wrote: > Suggested-by: Jonathan Nieder > Signed-off-by: Jeff King > --- > builtin/get-tar-commit-id.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Reviewed-by: Jonathan Nieder

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > In an ideal world, callers would always distinguish between > these cases and give a useful message for each. But as an > easy way to make our imperfect world better, let's reset > errno to a known value. The best we can do is "0", which > will yield something like: > >

Re: [PATCH 2/7] notes-merge: drop dead zero-write code

Jeff King wrote: > We call write_in_full() with a size that we know is greater > than zero. The return value can never be zero, then, since > write_in_full() converts such a failed write() into ENOSPC > and returns -1. We can just drop this branch of the error > handling entirely. > >

Re: [PATCH 1/7] files-backend: prefer "0" for write_in_full() error check

Jeff King wrote: > Commit 06f46f237a (avoid "write_in_full(fd, buf, len) != > len" pattern, 2017-09-13) converted this callsite from: > > write_in_full(...) != 1 > > to > > write_in_full(...) < 0 > > But during the conflict resolution in c50424a6f0 (Merge > branch 'jk/write-in-full-fix',

macOS Git installer on SourceForge

Hi, one of my colleagues made me aware today that the macOS Git installer is hosted on SourceForge and advertised on the official git-scm page: https://git-scm.com/download/mac SourceForge had some bad press as they apparently bundled junkware in their downloads:

[PATCH 7/7] add xread_in_full() helper

Many callers of read_in_full() expect to see exactly "len" bytes, and die if that isn't the case. Since there are two interesting error cases: 1. We saw a read() error. 2. We saw EOF with fewer bytes than expected. we would ideally distinguish between them when reporting to the user. Let's

[PATCH 6/7] worktree: check the result of read_in_full()

We try to read "len" bytes into a buffer and just assume that it happened correctly. In practice this should usually be the case, since we just stat'd the file to get the length. But we could be fooled by transient errors or by other processes racily truncating the file. Let's be more careful.

[PATCH 5/7] worktree: use xsize_t to access file size

To read the "gitdir" file into memory, we stat the file and allocate a buffer. But we store the size in an "int", which may be truncated. We should use a size_t and xsize_t(), which will detect truncation. An overflow is unlikely for a "gitdir" file, but it's a good practice to model.

[PATCH 4/7] get-tar-commit-id: prefer "!=" for read_in_full() error check

Comparing the result of read_in_full() using less-than is potentially dangerous, as discussed in 561598cfcf (read_pack_header: handle signed/unsigned comparison in read result, 2017-09-13). The instance in get-tar-commit-id is OK, because the HEADERSIZE macro expands to a signed integer. But if

[PATCH 3/7] read_in_full: reset errno before reading

Many callers of read_in_full() complain when we do not read their full byte-count. But a check like: if (read_in_full(fd, buf, len) != len) return error_errno("unable to read"); conflates two problem conditions: 1. A real error from read(). 2. There were fewer than "len" bytes

[PATCH 2/7] notes-merge: drop dead zero-write code

We call write_in_full() with a size that we know is greater than zero. The return value can never be zero, then, since write_in_full() converts such a failed write() into ENOSPC and returns -1. We can just drop this branch of the error handling entirely. Suggested-by: Jonathan Nieder

[PATCH 1/7] files-backend: prefer "0" for write_in_full() error check

Commit 06f46f237a (avoid "write_in_full(fd, buf, len) != len" pattern, 2017-09-13) converted this callsite from: write_in_full(...) != 1 to write_in_full(...) < 0 But during the conflict resolution in c50424a6f0 (Merge branch 'jk/write-in-full-fix', 2017-09-25), this morphed into

[PATCH 0/7] read/write_in_full leftovers

This series addresses the bits leftover from the discussion two weeks ago in: https://public-inbox.org/git/20170913170807.cyx7rrpoyhaau...@sigill.intra.peff.net/ and its subthread. I don't think any of these is a real problem in practice, so this can be considered as a cleanup. I'm on the

Re: [PATCH 4/4] Move documentation of string_list into string-list.h

On Mon, Sep 25, 2017 at 10:40 AM, Brandon Williams wrote: > On 09/25, Han-Wen Nienhuys wrote: >> This mirrors commit bdfdaa4978dd92992737e662f25adc01d32d0774 which did > > Not really important but most times we reference another commit from a > commit msg we include the one

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Stefan Beller wrote: > submodule..update can be assigned an arbitrary command via setting > it to "!command". When this command is found in the regular config, Git > ought to just run that command instead of other update mechanisms. > > However if that command is just found in the .gitmodules

[PATCH] t7406: submodule..update command must not be run from .gitmodules

submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially untrusted,

Re: git ls-tree -d doesn't work if the specified path is the repository root?

> Is there some reason for this? This behavior seems like a bug to me: > it means that prior to calling ls-tree I need to check if the > referenced path happens to be the root, and if so, find some other > means (rev-parse?) of converting it to a treehash. Hmm, interesting. I see these four

Re: [PATCH] Documentation: consolidate submodule..update

On 09/25, Stefan Beller wrote: > Have one place to explain the effects of setting submodule..update > instead of two. > > Signed-off-by: Stefan Beller > --- > >> I disagree. Actually, I think the git-config(1) blurb could just > >> point here, and that the text here ought to

git ls-tree -d doesn't work if the specified path is the repository root?

Hi, When I run `git ls-tree -d HEAD -- subdir` from the root of my repository, where `subdir` is a subdirectory in that root, I get the treehash of that subdirectory. This is what I expect. However, if I merely replace `subdir` with `.` (the root of the repository), (i.e., `git ls-tree -d HEAD

[PATCH] Documentation: consolidate submodule..update

Have one place to explain the effects of setting submodule..update instead of two. Signed-off-by: Stefan Beller --- >> I disagree. Actually, I think the git-config(1) blurb could just >> point here, and that the text here ought to be clear about what >> commands it affects

Re: [PATCH] git: add --no-optional-locks option

>> There might be another option to cope with the situation: >> >> 4. Teach all commands to spinlock / busywait shortly for important >> locks instead of giving up. In that case git-status rewriting >> the index ought to be fine? > > We do have all the infrastructure in place to do a

Re: What's cooking in git.git (Sep 2017, #04; Mon, 25)

> > * sb/parse-options-blank-line-before-option-list (2017-08-25) 1 commit > - usage_with_options: omit double new line on empty option list > > "git worktree" with no option and no subcommand showed too many > blank lines in its help text, which has been reduced. > > Superseded by

Re: [PATCH 4/4] Move documentation of string_list into string-list.h

On 09/25, Han-Wen Nienhuys wrote: > This mirrors commit bdfdaa4978dd92992737e662f25adc01d32d0774 which did Not really important but most times we reference another commit from a commit msg we include the one line summary like: 'bdfdaa497 (strbuf.h: integrate api-strbuf.txt documentation,

Re: [PATCH 3/4] Document submodule_to_gitdir

On 09/25, Han-Wen Nienhuys wrote: > Signed-off-by: Han-Wen Nienhuys > --- > submodule.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/submodule.c b/submodule.c > index b12600fc7..b66c23f5d 100644 > --- a/submodule.c > +++ b/submodule.c > @@ -1997,6 +1997,9 @@

Re: [PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently

On 09/25, Han-Wen Nienhuys wrote: > Signed-off-by: Han-Wen Nienhuys > --- > abspath.c | 3 +++ > setup.c | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/abspath.c b/abspath.c > index 708aff8d4..792a2d533 100644 > --- a/abspath.c > +++ b/abspath.c

Re: [PATCH] git: add --no-optional-locks option

On Mon, Sep 25, 2017 at 06:10:12PM +0200, Johannes Schindelin wrote: > On Thu, 21 Sep 2017, Jeff King wrote: > > > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > > to lock the index and update it, 2016-08-12). Folks working on GitHub > > Desktop complained to me that

Re: [PATCH v2 1/1] Win32: simplify loading of DLL functions

Johannes Schindelin wrote: > Dynamic loading of DLL functions is duplicated in several places in Git > for Windows' source code. > > This patch adds a pair of macros to simplify the process: the > DECLARE_PROC_ADDR(, , , > ..) macro to be used at the beginning of a > code block, and the

VKTUR'un SİZE ÖZEL KAMPANYALARI DEVAM EDİYOR!!

Re: [PATCH] git: add --no-optional-locks option

Hi Kaartic, On Sun, 24 Sep 2017, Kaartic Sivaraam wrote: > On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > > Some tools like IDEs or fancy editors may periodically run commands > > like "git status" in the background to keep track of the state of the > > repository. > > I might be

Re: [PATCH] git: add --no-optional-locks option

Hi Peff, On Thu, 21 Sep 2017, Jeff King wrote: > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > to lock the index and update it, 2016-08-12). Folks working on GitHub > Desktop complained to me that it's only available on Windows. :) Okay, so this is trying to help me

Re: [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes

On Sun, Sep 24, 2017 at 09:59:28PM +0200, Martin Ågren wrote: > > Anyway, doing: > > > > > > ASAN_OPTIONS=detect_leaks=1:abort_on_error=0:exitcode=0:log_path=/tmp/lsan/output > > \ > > make SANITIZE=address,leak test > > > > should pass the whole suite and give you a host of files to

[PATCH v2 0/1] Simplify loading of DLL functions on Windows

Changes since v1: - repeated the example from the commit message in the .h file - mentioned that the function is not thread-safe. - added Jonathan's Reviewed-by: footer Johannes Schindelin (1): Win32: simplify loading of DLL functions compat/win32/lazyload.h | 57

[PATCH v2 1/1] Win32: simplify loading of DLL functions

Dynamic loading of DLL functions is duplicated in several places in Git for Windows' source code. This patch adds a pair of macros to simplify the process: the DECLARE_PROC_ADDR(, , , ..) macro to be used at the beginning of a code block, and the INIT_PROC_ADDR() macro to call before using

[PATCH 1/4] Fix typo in submodule.h

Signed-off-by: Han-Wen Nienhuys --- submodule.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/submodule.h b/submodule.h index 6b52133c8..f0da0277a 100644 --- a/submodule.h +++ b/submodule.h @@ -120,7 +120,7 @@ extern int submodule_move_head(const char

[PATCH 3/4] Document submodule_to_gitdir

Signed-off-by: Han-Wen Nienhuys --- submodule.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/submodule.c b/submodule.c index b12600fc7..b66c23f5d 100644 --- a/submodule.c +++ b/submodule.c @@ -1997,6 +1997,9 @@ const char *get_superproject_working_tree(void)

[PATCH 2/4] Clarify return value ownership of real_path and read_gitfile_gently

Signed-off-by: Han-Wen Nienhuys --- abspath.c | 3 +++ setup.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/abspath.c b/abspath.c index 708aff8d4..792a2d533 100644 --- a/abspath.c +++ b/abspath.c @@ -202,6 +202,9 @@ char *strbuf_realpath(struct

[PATCH 4/4] Move documentation of string_list into string-list.h

This mirrors commit bdfdaa4978dd92992737e662f25adc01d32d0774 which did the same for strbuf.h: * API documentation uses /** */ to set it apart from other comments. * Function names were stripped from the comments. * Ordering of the header was adjusted to follow the one from the text file. *

[PATCH 0/4] Assorted comment fixes

I followed Peff's advice for string-list.h comments. Han-Wen Nienhuys (4): Fix typo in submodule.h Clarify return value ownership of real_path and read_gitfile_gently Document submodule_to_gitdir Move documentation of string_list into string-list.h

Re: [PATCH v2 00/21] Read `packed-refs` using mmap()

Hi Peff, On Wed, 20 Sep 2017, Jeff King wrote: > On Tue, Sep 19, 2017 at 08:22:08AM +0200, Michael Haggerty wrote: > > > This branch is also available from my fork on GitHub as branch > > `mmap-packed-refs`. > > > > My main uncertainties are: > > > > 1. Does this code actually work on

Re: [PATCH v2 14/21] read_packed_refs(): ensure that references are ordered when read

Hi Michael, On Thu, 21 Sep 2017, Michael Haggerty wrote: > On 09/20/2017 08:50 PM, Jeff King wrote: > > On Tue, Sep 19, 2017 at 08:22:22AM +0200, Michael Haggerty wrote: > >> If `packed-refs` was already sorted, then (if the system allows it) > >> we can use the mmapped file contents directly.

-s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: >It is a different matter to resurrect the age old discussion that >happend in the summer of 2008 if '-s theirs' should or should not >exist. In short, the previous discussion can be summarised to >"we don't want '-s theirs' as it

-X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko writes: > > d'oh, indeed there is no git-merge-theirs neither in debian pkg or a > > freshly > > built git and I found a rogue script in the PATH (which did nothing > > apparently, sorry!). BUT I was

Re: [PATCH] mailinfo: don't decode invalid =XY quoted-printable sequences

On Sat, Sep 23, 2017 at 08:04:40PM +0200, René Scharfe wrote: > Decode =XY in quoted-printable segments only if X and Y are hexadecimal > digits, otherwise just copy them. That's at least better than > interpreting negative results from hexval() as a character. Thanks, this looks good to me

Re: [PATCH v3 00/21] Read `packed-refs` using mmap()

On Mon, Sep 25, 2017 at 09:59:57AM +0200, Michael Haggerty wrote: > This is v3 of a patch series that changes the reading and caching of > the `packed-refs` file to use `mmap()`. Thanks to Stefan, Peff, Dscho, > and Junio for their comments about v2. I think I have addressed all of > the feedback

Re: [PATCH 3/4] merge: --no-verify to bypass pre-merge hook

Junio C Hamano venit, vidit, dixit 24.09.2017 01:48: > Michael J Gruber writes: > >> From: Michael J Gruber >> >> Analogous to commit, introduce a '--no-verify' option which bypasses the >> pre-merge hook. The shorthand '-n' is taken by the

[RFC PATCH 8/8] sequencer: try to commit without forking 'git commit'

From: Phillip Wood If the commit message does not need to be edited then create the commit without forking 'git commit'. Taking the best time of ten runs with a warm cache this reduces the time taken to cherry-pick 10 commits by 26% (from 319ms to 235ms), and the time

[RFC PATCH 2/8] commit: move code to update HEAD to libgit

From: Phillip Wood Signed-off-by: Phillip Wood --- builtin/commit.c | 31 +++ sequencer.c | 39 ++- sequencer.h | 2 ++ 3 files changed, 47 insertions(+), 25

[RFC PATCH 0/8] sequencer: dont't fork git commit

From: Phillip Wood These patches teach the sequencer to create commits without forking git commit when the commit message does not need to be edited. This speeds up cherry picking 10 commits by 26% and picking 10 commits with rebase --continue by 44%. The first few

[RFC PATCH 1/8] commit: move empty message checks to libgit

From: Phillip Wood Signed-off-by: Phillip Wood --- builtin/commit.c | 70 +++- sequencer.c | 60 sequencer.h | 10 3

[RFC PATCH 4/8] commit: move post-rewrite code to libgit

From: Phillip Wood Signed-off-by: Phillip Wood --- builtin/commit.c | 42 +- sequencer.c | 46 ++ sequencer.h | 2 ++ 3 files changed, 49

[RFC PATCH 5/8] commit: move print_commit_summary() to libgit

From: Phillip Wood Signed-off-by: Phillip Wood --- builtin/commit.c | 126 --- sequencer.c | 116 ++ sequencer.h | 5 +++ 3

[RFC PATCH 6/8] sequencer: simplify adding Signed-off-by: trailer

From: Phillip Wood Add the Signed-off-by: trailer in one place rather than adding it to the message when doing a recursive merge and then again when committing. This means that if there are conflicts when merging with a strategy other than 'recursive' the

[RFC PATCH 7/8] sequencer: load commit related config

From: Phillip Wood Load default values for message cleanup and gpg signing of commits in preparation for committing without forking 'git commit'. Signed-off-by: Phillip Wood --- builtin/rebase--helper.c | 13 -

[RFC PATCH 3/8] sequencer: refactor update_head()

From: Phillip Wood The previous commit was a mechanical translation of the code from builtin/commit.c. Now that it uses its own strbuf for the reflog message it can be simplified slightly. Signed-off-by: Phillip Wood --- sequencer.c | 7

[PATCH v2 0/5] Improve abbreviation disambiguation

Thanks for the feedback on my v1 patch. Thanks also to Jeff Hostetler for helping me with this v2 patch, which includes an extra performance improvement in commit 5. Changes since last version: * Added helper program test-list-objects to construct a list of existing object ids. * test-abbrev

  1   2   >