Re: [PATCH] compat: Allow static initializer for pthreads on Windows

Am 26.10.2016 um 23:57 schrieb Stefan Beller: In Windows it is not possible to have a static initialized mutex as of now, but that seems to be painful for the upcoming refactoring of the attribute subsystem, as we have no good place to put the initialization of the attr global lock. Please

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

Peter Williams writes: > However, for git commands such as diff/status whose job is to display > information it would be nice if they had a --recursive option to > override the default submodule diff/status and show details of the > changes in the submodules. Sometimes

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Junio C Hamano writes: > Stefan Beller writes: > >> Yeah, I can make it work without exposing struct git_attr. > > You completely misunderstood me. "struct git_attr" MUST be visible > to the users so that they can ask for the name in git_check.attr[0]. >

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On 27/10/16 09:59, Junio C Hamano wrote: Stefan Beller writes: - We have to make separate commits and manage corresponding topic branches for the superproject and subprojects. Well yeah, that is how submodule work on a conceptual level. While having multiple commits may

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Stefan Beller writes: > Yeah, I can make it work without exposing struct git_attr. You completely misunderstood me. "struct git_attr" MUST be visible to the users so that they can ask for the name in git_check.attr[0]. What would be nice to hide if you can is the function

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Wed, 2016-10-26 at 19:03 -0700, Stefan Beller wrote: > On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen > wrote: > > 4. I pushed several dangling submodule pointers before I learned I > > could set push.recurseSubmodules = check.  This isn't the default; each > >

Re: Expanding Includes in .gitignore

> The use case for this is where I did not write my own rules, but I want > to keep them updated. https://github.com/github/gitignore is a damn good > resource, but I want to pull it and include relevant bits project by > project and/or system wide. I don't want to have to update many projects >

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 5:49 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> extern struct git_attr *git_attr(const char *); >> ... >> +extern void git_attr_check_append(struct git_attr_check *, >> + const struct

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen wrote: > Hi Stefan, > > I appreciate the effort to remove obstacles to the use of submodules! > It looks like a custom tool is probably still our best option at this > time, though we can always switch back to submodules

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

Hi Stefan, I appreciate the effort to remove obstacles to the use of submodules!  It looks like a custom tool is probably still our best option at this time, though we can always switch back to submodules later. On Wed, 2016-10-26 at 16:23 -0700, Stefan Beller wrote: > On Wed, Oct 26, 2016 at

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Stefan Beller writes: > To explain, you can either have: > struct git_attr_result result[2]; > or > struct git_attr_result *result = git_attr_result_alloc(check); > and both are running just fine in a thread. However you should not > make that variable static. But

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Stefan Beller writes: > extern struct git_attr *git_attr(const char *); > ... > +extern void git_attr_check_append(struct git_attr_check *, > + const struct git_attr *); Another thing. Do we still need to expose git_attr() to the outside

Expanding Includes in .gitignore

I want a feature. It may be a bad-idea(tm). Advice appreciated. I want git to be able to include, in its gitignore files, sub-files of ignores or have it understand a directory of ignore files. Or both. The use case for this is where I did not write my own rules, but I want to keep them updated.

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 5:16 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> +* Allocate an array of `struct git_attr_result` either on the stack >> + or via `git_attr_result_alloc` on the heap when the result size >> + is not known at compile

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Stefan Beller writes: > +* Allocate an array of `struct git_attr_result` either on the stack > + or via `git_attr_result_alloc` on the heap when the result size > + is not known at compile time. The call to initialize >the result is not thread safe, because different

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 4:14 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> @@ -53,19 +57,32 @@ value of the attribute for the path. >> Querying Specific Attributes >> >> >> -* Prepare `struct git_attr_check` using

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

Stefan Beller writes: >> - We have to make separate commits and manage corresponding topic >> branches for the superproject and subprojects. > > Well yeah, that is how submodule work on a conceptual level. > While having multiple commits may seem like overhead, note > the

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen wrote: > I'm the lead developer of a research software application (https://bitb > ucket.org/objsheets/objsheets) that uses modified versions of two > third-party libraries, which we need to version and distribute along >

Re: [PATCHv2 1/2] attr: convert to new threadsafe API

Stefan Beller writes: > @@ -53,19 +57,32 @@ value of the attribute for the path. > Querying Specific Attributes > > > -* Prepare `struct git_attr_check` using git_attr_check_initl() > +* Prepare a `struct git_attr_check` using

Re: [PATCH 28/36] attr: keep attr stack for each check

On Sun, Oct 23, 2016 at 8:10 AM, Ramsay Jones wrote: >> + >> +struct hashmap all_attr_stacks; >> +int all_attr_stacks_init; > > Mark symbols 'all_attr_stacks' and 'all_attr_stacks_init' with > the static keyword. (ie. these are file-local symbols). > > ATB, > Ramsay

"git subtree --squash" interacts poorly with revert, merge, and rebase

I'm the lead developer of a research software application (https://bitb ucket.org/objsheets/objsheets) that uses modified versions of two third-party libraries, which we need to version and distribute along with our application.  For better or for worse, we haven't made it a priority to upstream

Re: What's cooking in git.git (Oct 2016, #07; Wed, 26)

Jonathan Tan writes: > On 10/26/2016 03:29 PM, Junio C Hamano wrote: >> * jt/trailer-with-cruft (2016-10-21) 8 commits >> - trailer: support values folded to multiple lines >> - trailer: forbid leading whitespace in trailers >> - trailer: allow non-trailers in

[PATCHv2 1/2] attr: convert to new threadsafe API

This revamps the API of the attr subsystem to be thread safe. Before we had the question and its results in one struct type. The typical usage of the API was static struct git_attr_check *check; if (!check) check = git_attr_check_initl("text", NULL); git_check_attr(path,

Re: What's cooking in git.git (Oct 2016, #07; Wed, 26)

On 10/26/2016 03:29 PM, Junio C Hamano wrote: * jt/trailer-with-cruft (2016-10-21) 8 commits - trailer: support values folded to multiple lines - trailer: forbid leading whitespace in trailers - trailer: allow non-trailers in trailer block - trailer: clarify failure modes in parse_trailer -

What's cooking in git.git (Oct 2016, #07; Wed, 26)

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. You can find the changes

Re: [PATCH] compat: Allow static initializer for pthreads on Windows

On Wed, Oct 26, 2016 at 2:57 PM, Stefan Beller wrote: > In Windows it is not possible to have a static initialized mutex as of > now, but that seems to be painful for the upcoming refactoring of the > attribute subsystem, as we have no good place to put the initialization > of

[PATCH] compat: Allow static initializer for pthreads on Windows

In Windows it is not possible to have a static initialized mutex as of now, but that seems to be painful for the upcoming refactoring of the attribute subsystem, as we have no good place to put the initialization of the attr global lock. The trick is to get a named mutex as CreateMutex[1] will

[PATCH] attr: expose error reporting function for invalid attribute names

From: Junio C Hamano Export invalid_attr_name_message() function that returns the message to be given when a given pair is not a good name for an attribute. We could later update the message to exactly spell out what the rules for a good attribute name are, etc.

Re: [PATCH 0/2] git-svn: implement "git worktree" awareness

Eric Wong writes: > Eric Wong wrote: >> +Cc Jakub since gitweb could probably take advantage of get_record >> from the first patch, too. I'm not completely sure about the API >> for this, though. > > Jakub: ping? > > +Cc: Junio, too. I'm hoping to have this in

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Jeff King writes: > On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote: > >> > I actually wonder if it is worth carrying around the O_NOATIME hack at >> > all. >> >> Yes, I share the thought. We no longer have too many loose objects >> to matter. >> >> I do not mind

Re: git-archive and submodules

On Wed, Oct 26, 2016 at 1:37 PM, Anatoly Borodin wrote: > are there plans to add submodules support to git-archive? plans by whom? Git is a project with contributors from all over the place. (different time zones, people motivated by different means, i.e. we have the

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 1:40 PM, Johannes Sixt wrote: > Am 26.10.2016 um 22:26 schrieb Jeff King: >> >> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote: >> >>> Am 26.10.2016 um 21:51 schrieb Stefan Beller: it is very convenient to not have to explicitly

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 1:26 PM, Jeff King wrote: > On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote: > >> Am 26.10.2016 um 21:51 schrieb Stefan Beller: >> > it is >> > very convenient to not have to explicitly initialize mutexes? >> >> Not to initialize a mutex is

Re: [PATCH 27/36] attr: convert to new threadsafe API

Am 26.10.2016 um 22:26 schrieb Jeff King: On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote: Am 26.10.2016 um 21:51 schrieb Stefan Beller: it is very convenient to not have to explicitly initialize mutexes? Not to initialize a mutex is still wrong for pthreads. I think Stefan

git-archive and submodules

Hi All, are there plans to add submodules support to git-archive? -- Mit freundlichen Grüßen, Anatoly Borodin

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote: > Am 26.10.2016 um 21:51 schrieb Stefan Beller: > > it is > > very convenient to not have to explicitly initialize mutexes? > > Not to initialize a mutex is still wrong for pthreads. I think Stefan was being loose with his wording.

Re: [PATCH 27/36] attr: convert to new threadsafe API

Am 26.10.2016 um 21:51 schrieb Stefan Beller: it is very convenient to not have to explicitly initialize mutexes? Not to initialize a mutex is still wrong for pthreads. -- Hannes

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 12:51:02PM -0700, Stefan Beller wrote: > > I seem to recall this does not work on Windows, where the pthread > > functions are thin wrappers over CRITICAL_SECTION. Other threaded code > > in git does an explicit setup step before entering threaded sections. > > E.g., see

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote: > > I actually wonder if it is worth carrying around the O_NOATIME hack at > > all. > > Yes, I share the thought. We no longer have too many loose objects > to matter. > > I do not mind flipping the order, but I'd prefer to cook

Re: [PATCH 0/2] git-svn: implement "git worktree" awareness

Eric Wong wrote: > +Cc Jakub since gitweb could probably take advantage of get_record > from the first patch, too. I'm not completely sure about the API > for this, though. Jakub: ping? +Cc: Junio, too. I'm hoping to have this in 2.11. > The following changes since commit

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 5:15 AM, Jeff King wrote: > On Wed, Oct 26, 2016 at 11:35:58AM +0200, Simon Ruderich wrote: > >> > static pthread_mutex_t attr_mutex; >> > -#define attr_lock()pthread_mutex_lock(_mutex) >> > +static inline void attr_lock(void) >> > +{ >> > + static int

Re: A bug with "git svn show-externals"

Tao Peng wrote: > Hi there, > > I met a bug of the "git svn show-externals” command. If a subdirectory item > has a svn:externals property, and the format of the property is “URL first, > then the local path”, running "git svn show-externals” command at the root > level will

Re: [PATCH] Documentation/git-diff: document git diff with 3+ commits

Michael J Gruber writes: > That one is difficult to discover but super useful, so document it: > Specifying 3 or more commits makes git diff switch to combined diff. > > Signed-off-by: Michael J Gruber > --- > > Notes: > Note that we

Re: [PATCH] hex: use unsigned index for ring buffer

René Scharfe writes: > Actually I didn't sign-off on purpose originally. But OK, let's keep > the version below. I just feel strangely sad seeing that concise magic > go. Nevermind. I actually share the sadness, too, but let's be stupid and obvious here. Thanks. > >

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Jeff King writes: > Of the two flags, I would say CLOEXEC is the more important one to > respect because it may actually impact correctness (e.g., leaking > descriptors to sub-processes). Whereas O_NOATIME is purely a performance > optimization. I tend to agree. > I actually

Re: [PATCH] hex: use unsigned index for ring buffer

Am 25.10.2016 um 20:28 schrieb Junio C Hamano: Jeff King writes: On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote: So how about this? It gets rid of magic number 3 and works for array size that's not a power of two. And as a nice side effect it can't trigger a

Re: [PATCH] reset: --unmerge

Duy Nguyen writes: > Interestingly the thread/bug that resulted in that commit started with > "report this bug to git" [2]. Something about git-stash. I quote the > original mail here in case anyone wants to look into it (not sure if > it's actually reported here before, I

Re: [PATCH] rebase: add --forget to cleanup rebase, leave HEAD untouched

Nguyễn Thái Ngọc Duy writes: > There are occasions when you decide to abort an in-progress rebase and > move on to do something else but you forget to do "git rebase --abort" > first. Or the rebase has been in progress for so long you forgot about > it. By the time you

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Wed, Oct 26, 2016 at 09:23:21AM -0700, Junio C Hamano wrote: > >> + /* Might the failure be due to O_NOATIME? */ > >> + if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) { > >> + sha1_file_open_flag &= ~O_NOATIME; > >> + continue; >

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Jeff King writes: >> +/* Try again w/o O_CLOEXEC: the kernel might not support it */ >> +if ((sha1_file_open_flag & O_CLOEXEC) && errno == EINVAL) { >> +sha1_file_open_flag &= ~O_CLOEXEC; >> continue; >>

Re: [PATCH v1 00/19] Add configuration options for split-index

Duy Nguyen writes: > On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano wrote: > > Even if we ignore user index files (by forcing them all to be stored > in one piece), there is a problem with the special temporary file > index.lock, which must use

Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

Duy Nguyen writes: > I don't object the alias.. approach though. It's > definitely a cleaner one in my opinion. It just needs people who can > spend time to follow up until the end. But if someone decides to do > that now, I'll drop the "(properties)!command" and try to

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Tue, Oct 25, 2016 at 2:18 AM, Stefan Beller wrote: > On Mon, Oct 24, 2016 at 11:55 AM, Junio C Hamano wrote: > >> >> Make that a double-asterisk. The same problem appears in an updated >> example in technical/api-gitattributes.txt doc, but the example

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote: > This revamps the API of the attr subsystem to be thread safe. > Before we had the question and its results in one struct type. > The typical usage of the API was > > static struct git_attr_check *check; > > if

Re: [PATCH 32/36] pathspec: allow querying for attributes

(sorry if this should have been answered if I went through the series patch by patch, I wanted to do a proper review but finally have to admit to myself I won't, so I just skim through a single giant diff instead) On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote: >

Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

On Tue, Oct 11, 2016 at 10:01 PM, Jeff King wrote: > On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote: > >> > Yeah, that's reasonable, too. So: >> > >> > [alias] >> > d2u = "!dos2unix" >> > >> > acts exactly as if: >> > >> > [alias "d2u"] >> > command

Re: [Question] Git histrory after greybus merge

Adding Cc: git list, Junio. 2016-10-26 15:55 GMT+03:00 Dmitry Safonov <0x7f454...@gmail.com>: > Hi, > > Is there any way to specify git-log or git-rev-list which root tree to use? > I mean, I got the following situation: > I saw the commit a67dd266adf4 ("netfilter: xtables: prepare for >

Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

On Wed, Oct 26, 2016 at 07:26:20PM +0700, Duy Nguyen wrote: > > I'm not sure this is really any convenience over dumping a corefile > > and using gdb to pull out the > > symbols after the fact. > > So are we back to forcing core files? I'm ok with that! The only > inconvenience I see is pointing

Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

On Wed, Oct 26, 2016 at 7:10 PM, Jeff King wrote: > On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote: > >> > I think you could conditionally make git_path() and all of its >> > counterparts macros, similar to the way the trace code works. It seems >> > like a pretty

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 11:35:58AM +0200, Simon Ruderich wrote: > > static pthread_mutex_t attr_mutex; > > -#define attr_lock()pthread_mutex_lock(_mutex) > > +static inline void attr_lock(void) > > +{ > > + static int initialized; > > + > > + if (!initialized) { > > +

Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote: > > I think you could conditionally make git_path() and all of its > > counterparts macros, similar to the way the trace code works. It seems > > like a pretty maintenance-heavy solution, though. I'd prefer > > conditionally compiling

Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

On Tue, Oct 25, 2016 at 11:15:25AM -0400, Jeff King wrote: > > The "once we've identified" part could be tricky though. This message > > alone will not give us any clue where it's called since it's buried > > deep in git_path() usually, which is buried deep elsewhere. Without > > falling back to

[PATCH] rebase: add --forget to cleanup rebase, leave HEAD untouched

There are occasions when you decide to abort an in-progress rebase and move on to do something else but you forget to do "git rebase --abort" first. Or the rebase has been in progress for so long you forgot about it. By the time you realize that (e.g. by starting another rebase) it's already too

Re: [PATCH 27/36] attr: convert to new threadsafe API

On Wed, Oct 26, 2016 at 10:52:23AM +0200, Johannes Schindelin wrote: > diff --git a/attr.c b/attr.c > index d5a6aa9..6933504 100644 > --- a/attr.c > +++ b/attr.c > @@ -50,7 +50,16 @@ static struct git_attr *(git_attr_hash[HASHSIZE]); > #ifndef NO_PTHREADS > > static pthread_mutex_t attr_mutex; >

Re: [PATCH] reset: --unmerge

On Wed, Oct 26, 2016 at 6:28 AM, Junio C Hamano wrote: > Somebody with a bright idea decided that vc-git-resolve-conflicts > variable should be on by default in Emacs 25.1 X-<, Oh good, I have an excuse to stick to 24.5.1 for a while longer then. > which causes > "save"

Re: [PATCH v1 00/19] Add configuration options for split-index

On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano wrote: >> Timestamps allow us to say, ok this base index file has not been read >> by anybody for N+ hours (or better, days), it's most likely not >> referenced by any temporary index files (including >> $GIT_DIR/index.lock)

[PATCH] Documentation/git-diff: document git diff with 3+ commits

That one is difficult to discover but super useful, so document it: Specifying 3 or more commits makes git diff switch to combined diff. Signed-off-by: Michael J Gruber --- Notes: Note that we have the following now: 'git diff A B' displays 'B minus A'

Re: [PATCH 27/36] attr: convert to new threadsafe API

Hi Stefan, On Sat, 22 Oct 2016, Stefan Beller wrote: > @@ -46,6 +47,19 @@ struct git_attr { > static int attr_nr; > static struct git_attr *(git_attr_hash[HASHSIZE]); > > +#ifndef NO_PTHREADS > + > +static pthread_mutex_t attr_mutex; > +#define attr_lock() pthread_mutex_lock(_mutex)