Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

Thanks for following up. A few minor comments: On Tue, Sep 05, 2017 at 04:57:24PM -0400, Ross Kabus wrote: > From: Ross Kabus > Date: Tue, 5 Sep 2017 13:54:52 -0400 > Subject: [PATCH] commit-tree: don't append a newline with -F Usually you'd just omit these in favor of the

Re: Branch name support & character

Hi, On 7 September 2017 at 13:27, 夏大雨 wrote: > I want to merge branch a to branch b so I rename branch b to a, but > when I push a to remote repo, '&' is took as & operator for shell, > and git push fails. So it would be better that branch name support & > character for

Re: [PATCH 27/34] shortlog: release strbuf after use in insert_one_record()

On Thu, Sep 07, 2017 at 04:51:12AM +0900, Junio C Hamano wrote: > > diff --git a/builtin/shortlog.c b/builtin/shortlog.c > > index 43c4799ea9..48af16c681 100644 > > --- a/builtin/shortlog.c > > +++ b/builtin/shortlog.c > > @@ -50,66 +50,67 @@ static int compare_by_list(const void *a1, const void

Branch name support & character

I want to merge branch a to branch b so I rename branch b to a, but when I push a to remote repo, '&' is took as & operator for shell, and git push fails. So it would be better that branch name support & character for me.

Re: gitmodules below root directory

On Wed, Sep 6, 2017 at 12:58 PM, Junio C Hamano wrote: > The current gitlink implementation records only the "what commit > from the subproject history is to be checked out at this path?" and > nothing else, by storing a single SHA-1 that happens to be the name > of the commit

Re: [RFC PATCH 0/2] Add named reference to latest push cert

Stefan Beller writes: > On the ref to store the push certs: > (a) Currently the ref points at the blob, I wonder if we'd rather want to > point at a commit? (Then we can build up a history of > push certs, instead of relying on the reflog to show all > push certs.

Re: [PATCHv2] pull: honor submodule.recurse config option

Nicolas Morey-Chaisemartin writes: >> If it is not the latter, perhaps we may want to flip the order of >> config parsing and option parsing around? That will allow us to fix >> the handling of autostash thing to use only one variable, and also >> fix your patch to

Re: [PATCH] config: remove git_config_maybe_bool

Martin Ågren writes: > The function was deprecated in commit 89576613 ("treewide: deprecate > git_config_maybe_bool, use git_parse_maybe_bool", 2017-08-07) and has no > users. > > Signed-off-by: Martin Ågren > --- Thanks. Will queue.

Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list

On Wed, Sep 06, 2017 at 08:12:24PM +0200, Martin Ågren wrote: > On 5 September 2017 at 23:26, Junio C Hamano wrote: > > Jeff King writes: > > > >> I noticed the HEAD funniness, too, when looking at this earlier. I agree > >> with Junio that it's not quite

Re: [PATCH v2] merge-recursive: change current file dir string_lists to hashmap

Kevin Willford writes: > The code was using two string_lists, one for the directories and > one for the files. The code never checks the lists independently > so we should be able to only use one list. The string_list also > is a O(log n) for lookup and insertion.

Re: [PATCHv2] builtin/merge: honor commit-msg hook for merges

Stefan Beller writes: >> I also thought that we were hunting calls of cmd_foo() from outside >> the git.c command dispatcher as grave errors and want to clean up >> the codebase to get rid of them. > > ... but I did not account for this fact. (I was not aware of these being >

Re: [PATCH] parse-options: warn developers on negated options

Stefan Beller writes: >> Ahh, I was an idiot (call it vacation-induced-brain-disfunction). I >> forgot about 0f1930c5 ("parse-options: allow positivation of options >> starting, with no-", 2012-02-25), which may have already made your >> new use of "--no-verify" in

[PATCH v2] merge-recursive: change current file dir string_lists to hashmap

The code was using two string_lists, one for the directories and one for the files. The code never checks the lists independently so we should be able to only use one list. The string_list also is a O(log n) for lookup and insertion. Switching this to use a hashmap will give O(1) which will

Re: [PATCHv2] builtin/merge: honor commit-msg hook for merges

On Tue, Sep 5, 2017 at 6:57 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Junio writes: >>> I didn't check how "merge --continue" is implemented, but we need to >>> behave exactly the same way over there, too. Making sure that it is >>> a case in

Re: [PATCH 25/39] sha1_file: allow alt_odb_usable to handle arbitrary repositories

On Wed, Sep 6, 2017 at 1:01 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> Signed-off-by: Jonathan Nieder >> Signed-off-by: Stefan Beller >> --- >> sha1_file.c | 16 +--- >> 1 file changed, 9

Re: [PATCH] parse-options: warn developers on negated options

On Tue, Sep 5, 2017 at 8:16 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Stefan Beller writes: >> >>> This patch disallows all no- options, but we could be more open and allow >>> --no-options that have the NO_NEG bit set.

Re: [RFC PATCH 0/2] Add named reference to latest push cert

On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote: > Currently, git only stores push certificates if there is a receive hook > present. This may violate the principle of least surprise (e.g., I > pushed with --signed, and I don't see anything in upstream). > Additionally,

Re: [PATCH] refs: make sure we never pass NULL to hashcpy

On Wed, Sep 6, 2017 at 2:26 AM, Junio C Hamano wrote: > Thomas Gummerer writes: > >> gcc on arch linux (version 7.1.1) warns that a NULL argument is passed >> as the second parameter of memcpy. >> >> In file included from refs.c:5:0: >> refs.c: In

Re: [PATCH] read-cache: fix index corruption with index v4

On Tue, Sep 5, 2017 at 8:37 PM, Kevin Willford wrote: >> From: Thomas Gummerer [mailto:t.gumme...@gmail.com] >> Sent: Monday, September 4, 2017 4:58 PM [..] >> I unfortunately didn't have more time to dig so >> >> > As ce->name is however not nul terminated >> >> just

Re: [PATCH 25/39] sha1_file: allow alt_odb_usable to handle arbitrary repositories

Jonathan Nieder writes: > Signed-off-by: Jonathan Nieder > Signed-off-by: Stefan Beller > --- > sha1_file.c | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/sha1_file.c b/sha1_file.c > index

Re: gitmodules below root directory

Robert Dailey writes: > The gitmodules documentation[1] states that the .gitmodules file is at > the root. However, it would be nice if this could be supported in any > directory similar to how .gitignore works. I have a mild suspicion that there would be a huge

Re: [PATCH 06/34] clone: release strbuf after use in remove_junk()

Rene Scharfe writes: > Signed-off-by: Rene Scharfe > --- > builtin/clone.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/clone.c b/builtin/clone.c > index 8d11b570a1..dbddd98f80 100644 > --- a/builtin/clone.c > +++

Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list

Martin Ågren writes: > Junio: The topic is in pu as ma/split-symref-update-fix. Re-roll or new > topic or as a separate "patch 4/3" for you to place on top, any > preference? Until a topic hits 'next', you solely own it and it is mostly up to you how to go about

Re: [PATCH 00/34] plug strbuf memory leaks

Rene Scharfe writes: > Release allocated strbufs in functions that are at least potentionally > library-like; cmd_*() functions are out of scope because the process > ends with them and the OS cleans up for us anyway. The patches are > split by function and were generated with

Re: [PATCH 34/34] wt-status: release strbuf after use in wt_longstatus_print_tracking()

Rene Scharfe writes: > If format_tracking_info() returns 0 only if it didn't touch its strbuf > parameter, so it's OK to exit early in that case. Clean up sb in the > other case. These two "if"s confuse me; perhaps the first one is not needed?

Re: [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer

Jeff King writes: > As an aside, the mru code could probably be simplified a bit by reusing > the list implementation from list.h (both were added around the same > time, and it wasn't worth creating a dependency then, but I think list.h > is useful and here to stay at this

Re: [PATCH 27/34] shortlog: release strbuf after use in insert_one_record()

Rene Scharfe writes: > Signed-off-by: Rene Scharfe > --- > builtin/shortlog.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/builtin/shortlog.c b/builtin/shortlog.c > index 43c4799ea9..48af16c681 100644 > --- a/builtin/shortlog.c > +++ b/builtin/shortlog.c

Your Attention Needed please

Dear Friend, It's my pleasure to write you today, I am Mr. Patrick Joseph, I work with the African Development Bank, I wish to place your name as the beneficiary to $17.5 million US dollars only due to the death of the depositor who died years ago along with her family. However, I assure you

Re: gitmodules below root directory

On Wed, Sep 6, 2017 at 6:53 AM, Robert Dailey wrote: > The gitmodules documentation[1] states that the .gitmodules file is at > the root. However, it would be nice if this could be supported in any > directory similar to how .gitignore works. Right now git-subrepo does >

Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list

On 5 September 2017 at 23:26, Junio C Hamano wrote: > Jeff King writes: > >> I noticed the HEAD funniness, too, when looking at this earlier. I agree >> with Junio that it's not quite consistent with the general rule of >> "string list items point to their

Re: [PATCH v4 11/16] revision.c: --all adds HEAD from all worktrees

On Wed, Sep 6, 2017 at 4:19 AM, Duy Nguyen wrote: > > So, probably no worktree iterator (yet). Ok, thanks for considering it.

Re: [PATCH v4 02/16] refs.c: use is_dir_sep() in resolve_gitlink_ref()

On Wed, Sep 6, 2017 at 4:08 AM, Duy Nguyen wrote: > On Thu, Aug 24, 2017 at 2:14 AM, Stefan Beller wrote: >> On Wed, Aug 23, 2017 at 5:36 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> The "submodule" argument in this function is a path, which

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

On 5 September 2017 at 15:05, Jeff King wrote: > 1. It can be compiled conditionally. There's no need in > normal runs to do this free(), and it just wastes time. > By using a macro, we can get the benefit for leak-check > builds with zero cost for normal builds

[PATCH v2] hashmap: address ThreadSanitizer concerns

From: Jeff Hostetler Version 2 addresses the comments and suggestions on version 1. It removes the explicit disable/enable rehash and just relies on the state of hashmap counting. It changes the declaration of the hashmap_get_size() to be static to avoid issues seen on

[PATCH v2] hashmap: add API to disable item counting when threaded

From: Jeff Hostetler This is to address concerns raised by ThreadSanitizer on the mailing list about threaded unprotected R/W access to map.size with my previous "disallow rehash" change (0607e10009ee4e37cb49b4cec8d28a9dda1656a4). See:

Re: [PATCH] hashmap: add API to disable item counting when threaded

On 9/5/2017 9:24 PM, Junio C Hamano wrote: Jeff Hostetler writes: From: Jeff Hostetler I feel somewhat stupid to say this, especially after seeing many people applaud this patch, but I do not seem to be able to even build Git with this

Re: [PATCH] rev-parse: don't trim bisect refnames

On Wed, Sep 6, 2017 at 1:53 PM, Jeff King wrote: > [...] > Subject: [PATCH] rev-parse: don't trim bisect refnames > > Using for_each_ref_in() with a full refname has always been > a questionable practice, but it became an error with > b9c8e7f2fb (prefix_ref_iterator: don't trim too

gitmodules below root directory

The gitmodules documentation[1] states that the .gitmodules file is at the root. However, it would be nice if this could be supported in any directory similar to how .gitignore works. Right now git-subrepo does not support submodules inside of a subrepo[2] (I suspect subtrees would have the same

Re: [PATCH] name-rev: change ULONG_MAX to TIME_MAX

On Wed, Sep 06, 2017 at 01:59:31PM +0200, Michael J Gruber wrote: > BTW, there's more fallout from those name-rev changes: In connection > with that other thread about surprising describe results for emacs.git I > noticed that I can easily get "git name-rev --stdin" to segfault there. > As easy

Re: [PATCH 1/2] system_path: move RUNTIME_PREFIX to a sub-function

On Wed, Sep 06, 2017 at 03:23:42PM +0200, Johannes Schindelin wrote: > On Wed, 6 Sep 2017, Jeff King wrote: > > > I find the diff hard to read because it shows the opposite of what I did > > (moving the big block to its own function, rather than moving the little > > bits to a new copy of the

Re: [PATCH 1/2] system_path: move RUNTIME_PREFIX to a sub-function

Hi Peff, On Wed, 6 Sep 2017, Jeff King wrote: > I find the diff hard to read because it shows the opposite of what I did > (moving the big block to its own function, rather than moving the little > bits to a new copy of the function). I guess --patience would have made it slightly more

Re: [PATCH] config: use a static lock_file struct

On Wed, Sep 06, 2017 at 12:59:46PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > In the long run we may want to drop the "tempfiles must remain forever" > > rule. This is certainly not the first time it has caused confusion or > > leaks. And I don't think it's a

Re: [PATCH 0/10] towards clean leak-checker output

On Tue, Sep 05, 2017 at 10:41:51PM +0200, Martin Ågren wrote: > FWIW, this series (combined with the other series you mentioned) makes > t and t0001 pass for me with gcc/clang. There are actually some > leaks in t, they're just silently being reported to stderr, since > the exit statuses

[PATCH 2/2] git_extract_argv0_path: do nothing without RUNTIME_PREFIX

When the RUNTIME_PREFIX compile-time knob isn't set, we never look at the argv0_path we extract. We can push its declaration inside the #ifdef to make it more clear that the extract code is effectively a noop. This also un-confuses leak-checking of the argv0_path variable when RUNTIME_PREFIX

[PATCH 1/2] system_path: move RUNTIME_PREFIX to a sub-function

The system_path() function has an #ifdef in the middle of it. Let's move the conditional logic into a sub-function. This isolates it more, which will make it easier to change and add to. Signed-off-by: Jeff King --- I find the diff hard to read because it shows the opposite of

[PATCH 0/2] simplifying !RUNTIME_PREFIX

On Wed, Sep 06, 2017 at 10:42:07AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > In fact, the whole extract_argv0_path thing is pointless without > > RUNTIME_PREFIX. So I think one reasonable fix is just: > [...] > Yeah, I kind of like this (I would have reduced the

Re: [PATCH] name-rev: change ULONG_MAX to TIME_MAX

Junio C Hamano venit, vidit, dixit 06.09.2017 05:35: > Michael J Gruber writes: > >> Earlier, dddbad728c ("timestamp_t: a new data type for timestamps", >> 2017-04-26) changed several types to timestamp_t. >> >> 5589e87fd8 ("name-rev: change a "long" variable to timestamp_t", >>

[PATCH] rev-parse: don't trim bisect refnames

On Tue, Sep 05, 2017 at 03:13:41PM -0700, Linus Torvalds wrote: > On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote: > > > > This probably fixes it: > > Yup. Thanks. Thanks for confirming. Here it is with a commit message and test. -- >8 -- Subject: [PATCH] rev-parse: don't trim

Re: [PATCH v4 07/16] refs: add refs_head_ref()

On Fri, Aug 25, 2017 at 4:52 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > ... which does what? > > Unlike refs_for_each_ref() and friends, this does not iterate. > It just uses the same function signature to make a single call >

Re: [PATCH v4 11/16] revision.c: --all adds HEAD from all worktrees

On Thu, Aug 24, 2017 at 2:54 AM, Stefan Beller wrote: >> +int other_head_refs(each_ref_fn fn, void *cb_data) >> +{ >> + struct worktree **worktrees, **p; >> + int ret = 0; >> + >> + worktrees = get_worktrees(0); >> + for (p = worktrees; *p; p++) { >> +

Re: [PATCH v4 02/16] refs.c: use is_dir_sep() in resolve_gitlink_ref()

On Thu, Aug 24, 2017 at 2:14 AM, Stefan Beller wrote: > On Wed, Aug 23, 2017 at 5:36 AM, Nguyễn Thái Ngọc Duy > wrote: >> The "submodule" argument in this function is a path, which can have >> either '/' or '\\' as a separator. Use is_dir_sep() to support

Re: [PATCH v4 00/16] Fix git-gc losing objects in multi worktree

On Fri, Aug 25, 2017 at 6:21 PM, Michael J Gruber wrote: > I suggest we think about the UI exposure a bit when it > comes to including all heads or naming options, though: > > * HEAD is "the current head" > * refs/heads is where all local branch heads are > > * --branches is the

[RFC PATCH 1/2] Always write push cert to disk

receive-pack: store push cert irrespective of hook Push certificates are being saved to disk only when hook was attached on the server side, which may complicate tooling and interaction with the certificates. Add write_push_cert_sha1() to save push cert to disk regardless of this. Signed-off-by:

[RFC PATCH 0/2] Add named reference to latest push cert

Currently, git only stores push certificates if there is a receive hook present. This may violate the principle of least surprise (e.g., I pushed with --signed, and I don't see anything in upstream). Additionally, push certificates could be more versatile if they are not tightly bound to git

[RFC PATCH 2/2] Store latest push cert ref in PUSH_CERT

path: Add named reference to push cert builtin/receive-pack: update named push cert ref Push certificates are "detached" objects on the git objects tree. Add a named reference so the latest push certificate can be easily fetched, verified and stored for later use. This eases tooling around the

[PATCHv3 2/2] pull: honor submodule.recurse config option

"git pull" supports a --recurse-submodules option but does not parse the submodule.recurse configuration item to set the default for that option. Meanwhile "git fetch" does support submodule.recurse, producing confusing behavior: when submodule.recurse is enabled, "git pull" recursively fetches

[PATCHv3 0/2] fix recurse.submodule config for git pull

Changes since v2: - Add a patch that fixes the option parsing order (parse config before cli, not the other way around) - Enhance the tests to check --recurse-submodule and submodule.recurse combinations Nicolas Morey-Chaisemartin (2): pull: fix cli and config option parsing order pull:

Re: RFC v3: Another proposed hash function transition plan

Jonathan Nieder writes: > Linus Torvalds wrote: >> On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote: > >>> This document is still in flux but I thought it best to send it out >>> early to start getting feedback. >> >> This actually looks very

Re: [PATCHv2] pull: honor submodule.recurse config option

Le 06/09/2017 à 03:17, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> "git pull" supports a --recurse-submodules option but does not parse the >> submodule.recurse configuration item to set the default for that option. >> Meanwhile "git fetch"