[PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

When a caller of sha1_object_info_extended() sets the "contentp" field in object_info, we call unpack_sha1_rest() but do not check whether it signaled an error. This causes two problems: 1. We pass back NULL to the caller via the contentp field, but the function returns "0" for success. A

Re: [ANNOUNCE] Git v2.15.0-rc0

On Thu, Oct 05, 2017 at 02:55:31PM +0900, Junio C Hamano wrote: > Git 2.15 Release Notes (draft) > == > > Backward compatibility notes and other notable changes. > > * Use of an empty string as a pathspec element that is used for >'everything matches' is still

Re: Quoted-printable support in git am

On Thu, Oct 05, 2017 at 11:15:08AM +0200, Mason wrote: > Is there a magic option I should be passing to git am? No, it's supposed to work out of the box. > The patch header contains: > > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: quoted-printable That

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

Jeff King writes: > So I think on the generating side we are better off creating a slightly > longer abbreviation that is unambiguous no matter what context it is > used in. I.e., I'd argue that it's actually more _correct_ to ignore > the disambiguation code entirely on the

Re: couple questions about git "logical variables" and "git var"

On Thu, Oct 05, 2017 at 05:11:04AM -0400, rpj...@crashcourse.ca wrote: > i just ran across "git var" for the first time, and it seems a bit weird. > it refers to the (apparently) four git "logical variables": It's definitely weird. > - GIT_AUTHOR_IDENT > - GIT_COMMITTER_IDENT > -

[PATCH v1 2/2] entry.c: check if file exists after checkout

From: Lars Schneider If we are checking out a file and somebody else racily deletes our file, then we would write garbage to the cache entry. Fix that by checking the result of the lstat() call on that file. Print an error to the user if the file does not exist.

[PATCH v1 1/2] entry.c: update cache entry only for existing files

From: Lars Schneider In 2841e8f ("convert: add "status=delayed" to filter process protocol", 2017-06-30) we taught the filter process protocol to delay responses. That means an external filter might answer in the first write_entry() call on a file that requires

[PATCH v1 0/2] fix temporary garbage in the cache entry

From: Lars Schneider Hi, in [1] Peff noticed that the delayed filter mechanism causes garbage in the cache entry for a brief moment during a delayed checkout process. The first patch fixes this issue. The second patch ensures that we don't write garbage in that way to

Quoted-printable support in git am

Hello everyone, Recently, the SMTP server we use at work started mangling outgoing messages, by converting them to quoted-printable, whatever their original encoding (even 7-bit clean, pure ASCII). This breaks patches I send to Linux mailing lists, because it changes TAB to =09, EQUAL to =3D,

Re: [PATCH v3 5/5] sha1_name: Minimize OID comparisons during disambiguation

On Mon, Oct 02, 2017 at 10:56:51AM -0400, Derrick Stolee wrote: > +static void find_abbrev_len_for_pack(struct packed_git *p, > + struct min_abbrev_data *mad) > +{ > + int match = 0; > + uint32_t num, last, first = 0; > + struct object_id oid; > + > +

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

> On 05 Oct 2017, at 05:46, Jeff King wrote: > > 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.

Re: [PATCH v2 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf

On Thu, Oct 05, 2017 at 04:55:53AM -0400, Jeff King wrote: > On Mon, Sep 25, 2017 at 05:54:49AM -0400, Derrick Stolee wrote: > > > Create helper program test-abbrev to compute the minimum length of a > > disambiguating short-sha for an input list of object ids. > > This seems like something

Re: [PATCH v2 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf

On Mon, Sep 25, 2017 at 05:54:49AM -0400, Derrick Stolee wrote: > Create helper program test-abbrev to compute the minimum length of a > disambiguating short-sha for an input list of object ids. This seems like something that Git ought to be able to do via real commands. Using "log --stdin

git send-email does not work with Google anymore?!

Hi, I used to use the Google SMTP server to send my patches to the list with the following config: [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = larsxschnei...@gmail.com smtpserverport = 587 from = larsxschnei...@gmail.com

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

Jeff King writes: > This is weirdly specific. Can we accomplish the same thing with existing > tools? > > E.g., could: > > git cat-file --batch-all-objects --batch-check='%(objectname)' | > shuffle | > head -n 100 > > do the same thing? > > I know that "shuffle" isn't

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On Thu, Oct 05, 2017 at 06:48:10PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > This is weirdly specific. Can we accomplish the same thing with existing > > tools? > > > > E.g., could: > > > > git cat-file --batch-all-objects --batch-check='%(objectname)' | > >

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On Thu, Oct 5, 2017 at 7:00 PM, Jeff King wrote: > >> Jeff King writes: >> > Actually, I'd just as soon see timings for "git log --format=%h" or "git > log --raw", as opposed to patches 1 and 2. > > You won't see a 90% speedup there, but you will see the actual >

[PATCH] Documentation/git-config.txt: reword missleading sentence

Change the word "bla" to "section.variable" to make it clear that it's a placeholder for a variable name. See discussion at: https://public-inbox.org/git/20171002061303.horde.sl92grzcqtrv9oqkbfpe...@crashcourse.ca/ Noticed-by: rpj...@crashcourse.ca --- Documentation/git-config.txt | 4 ++-- 1

couple questions about git "logical variables" and "git var"

i just ran across "git var" for the first time, and it seems a bit weird. it refers to the (apparently) four git "logical variables": - GIT_AUTHOR_IDENT - GIT_COMMITTER_IDENT - GIT_EDITOR - GIT_PAGER first question -- what is it about precisely those four variables that makes them

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

On Wed, Oct 04, 2017 at 03:07:25PM +0900, Junio C Hamano wrote: > > - 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); > > - if (exists > > -

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

Junio C Hamano writes: > I think the remaining points from my reviews are: > > - It would be better to compute precomputable stuff when used atoms >are parsed, instead of running starts_with() in these functions; After reading the original (before these three patches)

Re: Quoted-printable support in git am

On Thu, Oct 5, 2017 at 6:30 PM, Jeff King wrote: > >> The patch header contains: >> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> Content-Transfer-Encoding: quoted-printable > > That looks right. Though I wouldn't be surprised if whatever generated > the "flowed"

Re: [PATCH v3 0/5] Improve abbreviation disambituation

On Mon, Oct 02, 2017 at 10:56:46AM -0400, Derrick Stolee wrote: > Thanks for the feedback on my previous versions, and for patience > with my inexperience on the mailing list. I tried to respond to all > feedback, but decided to not apply one suggestion: For what it's worth, the optimizations

Re: [PATCH] Documentation/git-config.txt: reword missleading sentence

On Thu, Oct 5, 2017 at 5:17 PM, PAYRE NATHAN p1508475 wrote: > Change the word "bla" to "section.variable" to make it clear that it's a > placeholder for a variable name. Please make sure that your log message shows without wrapping and is a confortable read on a

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On Mon, Sep 25, 2017 at 05:54:48AM -0400, Derrick Stolee wrote: > Create test-list-objects helper program to output a random sample of > OIDs present in the repo. > > If no command line arguments are provided, all OIDs are output. This is weirdly specific. Can we accomplish the same thing with

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Wed, Oct 04, 2017 at 11:59:57AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Here's what I came up with on the "color.ui=always is nonsense that we > > should not offer" front. The number of patches may be a little daunting, > > but most of them are just removing

Re: [PATCH] api-argv-array.txt: Update link to string-list API

Todd Zullinger writes: > I noticed this broken link in the html documentation while building > 2.15.0-rc0. I'm not sure whether it's better to point the link to the > string-list.h file on Git Hub, remove the link, or drop the entire > paragraph. Probably removing the link is

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

On Fri, Oct 06, 2017 at 12:30:08AM -0400, Jeff King wrote: > On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote: > > > > But note that the leak in (2) is actually older than that. > > > The original unpack_sha1_file() directly returned the result > > > of unpack_sha1_rest() to its

[PATCH 1/1] completion: Add forgotten describe options

Signed-off-by: Thomas Braun --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index d934417475..0e16f017a4 100644 ---

Re: [PATCH 6/6] Handle unsupported combination status arguments

On Thu, Oct 5, 2017 at 1:54 PM, wrote: > From: Jameson Miller > > It is not clear what the correct behavior should be when you ask for > specific ignored behavior without reporting untracked files. For now, > report this as an unsupported

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

Jeff King writes: >> diff --git a/entry.c b/entry.c >> index 5dab656364..2252d96756 100644 >> --- a/entry.c >> +++ b/entry.c >> @@ -355,7 +355,8 @@ static int write_entry(struct cache_entry *ce, >> if (state->refresh_cache) { >> assert(state->istate); >>

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

On Fri, Oct 06, 2017 at 01:26:48PM +0900, Junio C Hamano wrote: > > We could probably be a bit more specific about the situation, since the > > user will see this message with no context. Maybe something like: > > > > unable to stat just-written file %s > > > > or something. We should probably

Re: couple questions about git "logical variables" and "git var"

Jeff King wrote: > On Thu, Oct 05, 2017 at 05:11:04AM -0400, rpj...@crashcourse.ca wrote: >> - GIT_AUTHOR_IDENT >> - GIT_COMMITTER_IDENT >> - GIT_EDITOR >> - GIT_PAGER >> >> first question -- what is it about precisely those four variables that makes >> them "logical" variables in git

Re: [RFC] Reporting index properties

Alex Vandiver wrote: > As part of gathering some automated performance statistics of git, it > would be useful to be able to extract some vital properties of the > index. While `git update-index` has ways to _set_ the index version, > and enable/disable various extensions, AFAICT there is no

Re: [PATCH v2] api-argv-array.txt: Remove broken link to string-list API

Jonathan Nieder wrote: Thanks for catching it. Do you use a broken link detection tool to detect this kind of issue automatically? Yeah, in the Fedora git builds we pass all the generated html files through the linkchecker tool (http://wummel.github.io/linkchecker/). We started using that

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote: > > But note that the leak in (2) is actually older than that. > > The original unpack_sha1_file() directly returned the result > > of unpack_sha1_rest() to its caller, when it should have > > been closing the zlib stream itself on

Re: [PATCH 1/1] completion: Add forgotten describe options

On Thu, Oct 5, 2017 at 2:23 PM, Thomas Braun wrote: > completion: Add forgotten describe options When/Why was it forgotten? git-blame thinks it was me in b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21) Which do you add? (dirty and broken) I

Re: [PATCH v2 01/12] sha1_file: do not leak `lock_file`

Martin Ågren writes: > Bump `found` to the scope of the whole function and rearrange the "roll > back or write?"-checks to a straightforward if-else on `found`. This > also future-proves the code by making it obvious that we intend to take > exactly one of these paths. >

Re: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

Martin Ågren writes: > v2: Except for the slightly different documentation in cache.h, this is > a squash of the last two patches of v1. I hope the commit message is > better. Yeah, it is long ;-) but readable. Thanks.

Re: [RFC] Reporting index properties

Jonathan Nieder writes: > Aside: git-update-index(1) says > > Version 4 is relatively young (first released in 1.8.0 in > October 2012). > > My first reaction is to wonder if it is time to introduce a config > option to use index format version 4 by default, since

Re: [PATCH v2] run-command: add hint when a hook is ignored

Damien Marié writes: > if (access(path.buf, X_OK) < 0) { > + int err = errno; OK, so we remember how/why we failed in err. > #ifdef STRIP_EXTENSION > strbuf_addstr(, STRIP_EXTENSION); > if (access(path.buf, X_OK) >= 0) >

Re: [PATCH v2] api-argv-array.txt: Remove broken link to string-list API

Todd Zullinger wrote: > In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/ > into header, 2017-09-26) the string-list API documentation was moved to > string-list.h. The argv-array API documentation may follow a similar > course in the future. Until then, prevent the

Re: couple questions about git "logical variables" and "git var"

On Thu, Oct 05, 2017 at 07:35:30PM -0700, Jonathan Nieder wrote: > > It also only tells half the story. You have to know not just what's in > > $GIT_EDITOR, but you have to know the right way to evaluate it. There's > > a git_editor helper in git-sh-setup, but other scripting languages are > > on

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

On Fri, Oct 06, 2017 at 08:01:48AM +0900, Junio C Hamano wrote: > > But > > I think we'd want to protect the read_blob_entry() call at the top of > > the case with a check for dco->state == CE_RETRY. > > Yeah, I think that makes more sense. > > A patch may look like this on top of these two

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: > Before we put this into stone: > Does it make sense to say "renormalize" instead of "rehash" ? > (That term does exist already for merge. > And rehash is more a technical term, rather then a user-point-of-view > explanation) I do not mind

Re: [RFC] Reporting index properties

Alex Vandiver writes: > On Fri, 6 Oct 2017, Junio C Hamano wrote: >> > Do folks have feelings about surfacing this information, and where such >> > logic should live? >> >> Probably one of the t/helper/test-dump-*.c programs, if we already >> do not have one. > > The goal

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Johannes Schindelin writes: > Subject: Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote > ref name No verb? s/optionally/report/ perhaps? > diff --git a/ref-filter.c b/ref-filter.c > index 4819707d032..b4b2c9b2190 100644 > --- a/ref-filter.c >

Re: hacktoberfest

On Wed, Oct 04, 2017 at 10:20:53PM +0100, pedro rijo wrote: > 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

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

On Thu, 2017-10-05 at 10:13 +0900, Junio C Hamano wrote: > 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

Re: [ANNOUNCE] Git v2.15.0-rc0

Hi Junio, On Thu, 5 Oct 2017, Junio C Hamano wrote: > New contributors whose contributions weren't in v2.14.0 are as follows. > Welcome to the Git development community! > > Ann T Ropea, Daniel Watkins, Dimitrios Christidis, Eric Rannaud, > Evan Zacks, Hielke Christian Braun, Ian Campbell,

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

lars.schnei...@autodesk.com writes: > diff --git a/entry.c b/entry.c > index 1c7e3c11d5..5dab656364 100644 > --- a/entry.c > +++ b/entry.c > @@ -304,7 +304,7 @@ static int write_entry(struct cache_entry *ce, > ce->name, new, size, , dco); >

Re: Quoted-printable support in git am

On 05/10/2017 11:43, Junio C Hamano wrote: > On Thu, Oct 5, 2017 at 6:30 PM, Jeff King wrote: > >> Mason wrote: >> >>> The patch header contains: >>> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> Content-Transfer-Encoding: quoted-printable >> >> That looks right. Though I

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

On Thu, Oct 05, 2017 at 12:44:06PM +0200, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > In 2841e8f ("convert: add "status=delayed" to filter process protocol", > 2017-06-30) we taught the filter process protocol to delay responses. > > That means an

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

On Thu, Oct 05, 2017 at 08:19:13PM +0900, Junio C Hamano wrote: > > diff --git a/entry.c b/entry.c > > index 1c7e3c11d5..5dab656364 100644 > > --- a/entry.c > > +++ b/entry.c > > @@ -304,7 +304,7 @@ static int write_entry(struct cache_entry *ce, > > ce->name,

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

There are times when e.g. scripts want to know not only the name of the upstream branch on the remote repository, but also the name of the remote. This patch offers the new suffix :remotename for the upstream and for the push atoms, allowing to show exactly that. Example: $ cat

[PATCH v2 3/3] for-each-ref: test :remotename and :remoteref

This not only prevents regressions, but also serves as documentation what this new feature is expected to do. Signed-off-by: Johannes Schindelin --- t/t6300-for-each-ref.sh | 32 1 file changed, 32 insertions(+) diff --git

[PATCH v2 0/3] for-each-ref: add :remoteref and :remotename specifiers

This introduces support for git for-each-ref \ --format="%(merge:remotename),%(merge:remoteref)" git for-each-ref \ --format="%(push:remotename),%(push:remoteref)" to figure out the remote nickname as well as the name of the corresponding branch on

[PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

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. An example of this is when a tool wants to push to the very same branch from which it would pull

Re: git send-email does not work with Google anymore?!

On 05/10/2017 12:52, Lars Schneider wrote: > Hi, > > I used to use the Google SMTP server to send my patches to the list with > the following config: > > [sendemail] > smtpencryption = tls > smtpserver = smtp.gmail.com > smtpuser = larsxschnei...@gmail.com >

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

Hi Junio, On Wed, 4 Oct 2017, Junio C Hamano wrote: > 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

[RFC PATCH 0/4] interpret-trailers: introduce "move" action

The purpose of this action is for scripts to be able to keep the user's Signed-off-by at the end. For example say I have a script that adds a Reviewed-by tag: #! /bin/sh them=$(git log -i -1 --pretty='format:%an <%ae>' --author="$*") trailer="Reviewed-by: $them" git log -1

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

On Thu, Oct 05, 2017 at 12:44:07PM +0200, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > If we are checking out a file and somebody else racily deletes our file, > then we would write garbage to the cache entry. Fix that by checking > the result of the

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On 10/5/2017 6:00 AM, Jeff King wrote: On Thu, Oct 05, 2017 at 06:48:10PM +0900, Junio C Hamano wrote: Jeff King writes: This is weirdly specific. Can we accomplish the same thing with existing tools? E.g., could: git cat-file --batch-all-objects

[PATCH 3/4] trailer: create a new function to handle adding trailers

Create a new function apply_arg that takes care of computing the new trailer's "neighbor", checking for duplicates through a pluggable callback, and adding the new argument according to "trailer.where". Rename after_or_end, and don't use it in apply_arg. It's a coincidence that the conditions

[PATCH 4/4] trailer: add "move" configuration for trailer.ifExists

In some cases, people apply patches to a queue branch immediately with "git am -3 -s", and later collect Reviewed-by or Acked-by trailers as they come in from the mailing list. In this case, "where=after" does not have the desired behavior, because it will add the trailer in an unorthodox

[PATCH 2/4] trailer: simplify check_if_different

The check_all argument is pointless, because the function degenerates to !same_trailer when check_all==0 (if same_trailer fails, it always ends up returning 1). Remove it, switching the check_all==0 caller to use same_trailer directly. Signed-off-by: Paolo Bonzini ---

[PATCH 1/4] trailer: push free_arg_item up

All callees of process_trailers_lists are calling free_arg_item. Just do it in process_trailers_lists itself. Signed-off-by: Paolo Bonzini --- trailer.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/trailer.c b/trailer.c index

wildmatch + fnmatch compatibility

Hi all, I noticed a possible inconsistency in the documentation for .gitignore; the pertinent bit is: If the pattern does not contain a slash /, Git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the .gitignore file ...

Re: [ANNOUNCE] Git v2.15.0-rc0

+ Rene - kernel mailing list On Thu, Oct 5, 2017 at 6:10 AM, Johannes Schindelin wrote: > Hi Junio, > > On Thu, 5 Oct 2017, Junio C Hamano wrote: > >> New contributors whose contributions weren't in v2.14.0 are as follows. >> Welcome to the Git development community!

Regression in 'git branch -m'?

Hi everybody, I got something that looks like a regression somewhere since 2.11. This script set -xe rm -rf repo git init repo cd repo git commit -m nix --allow-empty git branch -m master/master git rev-parse HEAD git branch git status causes .git/HEAD to still contain 'ref:

Apply

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financeloa...@hotmail.com

Re: git send-email does not work with Google anymore?!

On 5 October 2017 at 15:43, Paolo Bonzini wrote: > > On 05/10/2017 12:52, Lars Schneider wrote: > > Hi, > > > > I used to use the Google SMTP server to send my patches to the list with > > the following config: > > > > [sendemail] > > smtpencryption = tls > >

Re: git send-email does not work with Google anymore?!

On 05/10/2017 16:21, ankostis wrote: > > But this seems to have stopped working; I clicked the link in the page below > https://support.google.com/accounts/answer/6010255?hl=en > and for my account it tells me "less secure apps" access is unavailable :-( It says for me "This setting is not

Re: [PATCH v2] run-command: add hint when a hook is ignored

Junio C Hamano writes: >> diff --git a/t/t7519-ignored-hook-warning.sh >> b/t/t7519-ignored-hook-warning.sh >> new file mode 100755 Another thing; t7519 is taken by another topic in flight. Let's use t7520 instead.

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

Jeff King writes: > On Thu, Oct 05, 2017 at 08:19:13PM +0900, Junio C Hamano wrote: > >> This is unrelated to the main topic of this patch, but we see this >> just before the precontext of this hunk: >> >> if (dco && dco->state != CE_NO_DELAY) { >>

Re: [RFC] Reporting index properties

Alex Vandiver writes: > Do folks have feelings about surfacing this information, and where such > logic should live? Probably one of the t/helper/test-dump-*.c programs, if we already do not have one.

Re: [PATCH v2 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag

Martin Ågren writes: > diff --git a/read-cache.c b/read-cache.c > index 65f4fe837..1c917eba9 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -2343,14 +2343,13 @@ static int do_write_locked_index(struct index_state > *istate, struct lock_file *l > int ret =

Re: [PATCH v2] run-command: add hint when a hook is ignored

Here is a suggested rewrite of t7519 (I used t7520 to avoid crashing with another topic in flight). - use unused/unallocated 7520 to avoid crashes with bp/fsmonitor topic - use setup inside test_expect_success - use test_i18ngrep to avoid gettext-poison build gotchas - look for specific

Re: [PATCH v2] run-command: add hint when a hook is ignored

Junio C Hamano writes: > I think it is easier to reason about if this were not "else if", but > just a simple "if". And here are two small suggested changes to the code portion of your patch. - break if / else if cascade into two independent if / if statements for

Re: Regression in 'git branch -m'?

On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote: > I got something that looks like a regression somewhere since 2.11. > This script > > set -xe > rm -rf repo > git init repo > cd repo > git commit -m nix --allow-empty > git branch -m master/master > git rev-parse HEAD

[RFC] Reporting index properties

Heya, As part of gathering some automated performance statistics of git, it would be useful to be able to extract some vital properties of the index. While `git update-index` has ways to _set_ the index version, and enable/disable various extensions, AFAICT there is no method by which one can

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

Jeff King writes: > When a caller of sha1_object_info_extended() sets the > "contentp" field in object_info, we call unpack_sha1_rest() > but do not check whether it signaled an error. > > This causes two problems: > > 1. We pass back NULL to the caller via the contentp field, >

[PATCH/RFC] git-post: the opposite of git-cherry-pick

Add a new command that can be used to copy an arbitrary commit to a branch that is not checked out. Signed-off-by: Johannes Sixt --- I have been using this command since years, but got around to write a man page and tests only now. I hope the man page makes sense. I don't have

[RFC] deprecate git stash save? (was: Re: [PATCH 2/3] http-push: fix construction of hex value from path)

On 10/04, Junio C Hamano wrote: > I do not object with such a well designed deprecation plan for any > other features, if there are other "favourite" ones people would > want to deprecate and eventually remove, by the way. Since you were asking :) With the introduction of 'git stash push', my

[ANNOUNCE] Git for Windows 2.14.2(2)

Dear Git users, It is my pleasure to announce that Git for Windows 2.14.2(2) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.14.2 (September 26th 2017) New Features * Comes with BusyBox v1.28.0pre.16467.b4c390e17. * Comes with Git LFS v2.3.2.

[PATCH v2 06/12] cache-tree: simplify locking logic

After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that `newfd` is non-negative. So when we check for exactly that property before calling `write_locked_index()`, the outcome is guaranteed. If we write and commit successfully, we set `newfd = -1`, so that we can later avoid calling

[PATCH v2 05/12] checkout-index: simplify locking logic

`newfd` starts out negative. If we then take the lock, `newfd` will become non-negative. We later check for exactly that property before calling `write_locked_index()`. That is, we are simply using `newfd` as a boolean to keep track of whether we took the lock or not. (We always use `newfd` and

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote: > Add a new command that can be used to copy an arbitrary commit > to a branch that is not checked out. Cool. :) > > Signed-off-by: Johannes Sixt > --- > I have been using this command since years, but got

Re: [PATCH] fsck: check results of lookup_blob() and lookup_tree() for NULL

Am 04.10.2017 um 06:00 schrieb Junio C Hamano: > René Scharfe writes: >> lookup_blob() and lookup_tree() can return NULL if they find an object >> of an unexpected type. Error out of fsck_walk_tree() in that case, like >> we do when encountering a bad file mode. An error message

[PATCH] .mailmap: normalize name for René Scharfe

Reported-by: Johannes Schindelin Reported-by: Stefan Beller Signed-off-by: Rene Scharfe --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index ab85e0d16d..224db83887 100644 --- a/.mailmap +++

[PATCH v2 07/12] apply: move lockfile into `apply_state`

We have two users of `struct apply_state` and the related functionality in apply.c. Each user sets up its `apply_state` by handing over a pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we could never free lockfiles, so making them

[PATCH v2 08/12] apply: remove `newfd` from `struct apply_state`

Similar to a previous patch, we do not need to use `newfd` to signal that we have a lockfile to clean up. We can just unconditionally call `rollback_lock_file`. If we do not hold the lock, it will be a no-op. Where we check `newfd` to decide whether we need to take the lock, we can instead use

[PATCH v2 03/12] lockfile: fix documentation on `close_lock_file_gently()`

Commit 83a3069a3 (lockfile: do not rollback lock on failed close, 2017-09-05) forgot to update the documentation by the function definition to reflect that the lock is not rolled back in case closing fails. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

[PATCH v2 00/12] Re: various lockfile-leaks and -fixes

On 3 October 2017 at 08:21, Junio C Hamano wrote: > Martin Ågren writes: >> On 2 October 2017 at 08:30, Junio C Hamano wrote: >> >> Thanks both of you for your comments. Based on them, I have made the >> following notes: >> ... >>

[PATCH v2 01/12] sha1_file: do not leak `lock_file`

There is no longer any need to allocate and leak a `struct lock_file`. Initialize it on the stack instead. Before this patch, we set `lock = NULL` to signal that we have already rolled back, and that we should not do any more work. We need to take another approach now that we cannot assign NULL.

[PATCH v2 02/12] treewide: prefer lockfiles on the stack

There is no longer any need to allocate and leak a `struct lock_file`. The previous patch addressed an instance where we needed a minor tweak alongside the trivial changes. Deal with the remaining instances where we allocate and leak a struct within a single function. Change them to have the

[PATCH v2 09/12] cache.h: document `write_locked_index()`

The next patches will tweak the behavior of this function. Document it in order to establish a basis for those patches. Signed-off-by: Martin Ågren --- v2: Tweaked to go better with the changed approach in the later patches. cache.h | 16 1 file

[PATCH v2 04/12] tempfile: fix documentation on `delete_tempfile()`

The function has always been documented as returning 0 or -1. It is in fact `void`. Correct that. As part of the rearrangements we lose the mention that `delete_tempfile()` might set `errno`. Because there is no return value, the user can't really know whether it did anyway. Signed-off-by: Martin

[PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

If the original version of `write_locked_index()` returned with an error, it didn't roll back the lockfile unless the error occured at the very end, during closing/committing. See commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13). In commit

[PATCH v2 12/12] read_cache: roll back lock in `update_index_if_able()`

`update_index_if_able()` used to always commit the lock or roll it back. Commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13) stopped rolling it back in case a write was not even attempted. This change in behavior is not motivated in the commit

  1   2   >