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

Am 27.10.2016 um 23:49 schrieb Jacob Keller: Ok, so I've been reading this thread. I don't understand your objections to emulating in this way.. Could you clearly spell out why you believe this solution isn't acceptable? So far all I've understood was "it's not critical sections" and "it

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

Junio C Hamano wrote: > Junio C Hamano writes: > > > Linus Torvalds writes: > > > >> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: > >>> > >>> Would the best endgame shape for this function be to

Re: [RFC PATCH 0/5] recursively grep across submodules

On Thu, Oct 27, 2016 at 7:50 PM, Junio C Hamano wrote: > > Unless you are imagining "git grep" to initialize and checkout a > submodule that is not checked out on-demand, I do not think you have > any reason to even look at ".gitmodules" for the purpose of "I want > to grep

Loan

-- Are you in need of easy qualifying business or personal loans? We offer all kinds of loans at 3% contact us today at. Carmona.gomez402@gmail.comFull Name:Need Loan Amount:Loan Duration:Phone Number:Applied before :?State:Monthly Income:Country:contact us today at.

"git push" says "src refspec XYZ matches more than one" even without explicit XYZ argument.

1. My repo has a branch named 'v1' that is tracking 'origin/v1'. 2. My repo has a tag named 'v1'. 3. I have "push.default" set to "upstream". I made a commit on branch 'v1' and tried doing a push: # git push error: src refspec v1 matches more than one. error: failed to push some refs

Re: Expanding Includes in .gitignore

Jeff King writes: > However, as I said elsewhere, I'm not convinced this feature is all that > helpful for in-repository .gitignore files, and I think it does > introduce compatibility complications. People with older git will not > respect your .gitignore.d files. Whereas

Re: [RFC PATCH 0/5] recursively grep across submodules

Stefan Beller writes: >> Just a few brief comments, before reading the patches carefully. >> >> * It is somewhat surprising that [1/5] is even needed (in other >>words, I would have expected something like this to be already >>there, and my knee-jerk reaction was

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

Junio C Hamano writes: > Linus Torvalds writes: > >> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: >>> >>> Would the best endgame shape for this function be to open with >>> O_NOATIME (and retry without), and then

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

Linus Torvalds writes: > On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: >> >> Would the best endgame shape for this function be to open with >> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2) >> but ignoring an error

Re: [RFC PATCH 0/5] recursively grep across submodules

On Thu, Oct 27, 2016 at 4:26 PM, Junio C Hamano wrote: > Brandon Williams writes: > >> As for the rest of the series, it should be ready for review or comments. > > Just a few brief comments, before reading the patches carefully. > > * It is somewhat

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

On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: > > Would the best endgame shape for this function be to open with > O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2) > but ignoring an error from it, I guess? That would be the closest > to what we

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

Linus Torvalds writes: > But the basic issue still remains - I'd really prefer to have NOATIME > stay around for all those poor misguided souls that for some reason > don't like "relatime" or run old kernels. But whether it is with > O_NOATIME at open time or with

Re: feature request

On Thu, 27 Oct 2016, John Rood wrote: Thanks, I think changing the default for windows is a good idea. notepad doesn't work well with unix line endings, wordpad handles the files much more cleanly. David Lang

Re: [RFC PATCH 0/5] recursively grep across submodules

Brandon Williams writes: > As for the rest of the series, it should be ready for review or comments. Just a few brief comments, before reading the patches carefully. * It is somewhat surprising that [1/5] is even needed (in other words, I would have expected something

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

On Thu, Oct 27, 2016 at 4:09 PM, Linus Torvalds wrote: > > That said, now that I think about it, I should double-check: maybe > open() doesn't actually set atime at all, and we *could* do NOATIME > with SETFL after all. Checked. Yup. O_NOATIME could easily be done

Re: feature request

Thanks. I wasn't aware of --no-edit, but that is indeed exactly what I was looking for. I think your point about encouraging users to make good use of commit messages is good. My concern though is that vim isn't encouraging users to leave good messages as much as it is scaring them away from

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

On Thu, Oct 27, 2016 at 3:56 PM, Junio C Hamano wrote: > > I also thought O_NOATIME shouldn't be an effective fcntl(2) thing, > for the reasons you stated above, when I was studying the area > because of the discussion on these patches. I was surprised to see > that

Re: Expanding Includes in .gitignore

On 28/10/16 10:07, Jeff King wrote: > I think it does > introduce compatibility complications. If this is not a show stopper, I am happy to knock out a short functional spec. I'll give it some hours before I begin.

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

Linus Torvalds writes: > Note that you can *not* do the same thing with O_NOATIME, since the > whole point of O_NOATIME is that it changes the behavior of the open > itself (unlike O_CLOEXEC which changes _later_ behavior, and can > always be replaced by FD_CLOEXEC

Re: feature request

John Rood writes: [administrivia: do not top post] > What I'm really seeking is not a make-shift solution for myself, but > an intuitive solution for the novice user-base at large. Well, there are -m and --no-edit. Recording commits with useless single liner is a bad

Re: feature request

What I'm really seeking is not a make-shift solution for myself, but an intuitive solution for the novice user-base at large. On Thu, Oct 27, 2016 at 5:27 PM, Junio C Hamano wrote: > John Rood writes: > >> I suppose I can do git config --global

Re: feature request

John Rood writes: > On Thu, Oct 27, 2016 at 5:30 PM, Stefan Beller wrote: >> On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >>> Users should be able to configure Git to not send them into a Vim editor. >>> >>> When users

Re: feature request

Thanks, I think changing the default for windows is a good idea. The -m indeed accomplishes one-line messages when you are voluntarily doing a commit. However, the scenario I mentioned is "When users pull commits, and a new commit needs to be created for the merge" In this situation, the user

[PATCH 4/5] grep: optionally recurse into submodules

Allow grep to recognize submodules and recursively search for patterns in each submodule. This is done by forking off a process to recursively call grep on each submodule. The top level --super-prefix option is used to pass a path to the submodule which can in turn be used to prepend to output

[PATCH 5/5] grep: enable recurse-submodules to work on objects

Teach grep to recursively search in submodules when provided with a object. This allows grep to search a submodule based on the state of the submodule that is present in a commit of the super project. When grep is provided with a object, the name of the object is prefixed to all output. In

[PATCH 1/5] submodules: add helper functions to determine presence of submodules

Add two helper functions to submodules.c. `is_submodule_initialized()` checks if a submodule has been initialized at a given path and `is_submodule_checked_out()` check if a submodule has been checked out at a given path. Signed-off-by: Brandon Williams --- submodule.c | 39

[PATCH 3/5] grep: add submodules as a grep source type

Add `GREP_SOURCE_SUBMODULE` as a grep_source type and cases for this new type in the various switch statements in grep.c. When initializing a grep_source with type `GREP_SOURCE_SUBMODULE` the identifier can either be NULL (to indicate that the working tree will be used) or a SHA1 (the REV of the

[PATCH 2/5] submodules: load gitmodules file from commit sha1

teach submodules to load a '.gitmodules' file from a commit sha1. This enables the population of the submodule_cache to be based on the state of the '.gitmodules' file from a particular commit. Signed-off-by: Brandon Williams --- cache.h| 2 ++ config.c

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

On Thu, Oct 27, 2016 at 3:24 AM, Jeff King wrote: > > +cc Linus as the original author of 144bde78e9 in case there is > something subtle I'm missing, but this really just seems like it's > an outdated optimization. I'd *really* like to keep O_NOATIME if at all possible. It made a

[RFC PATCH 0/5] recursively grep across submodules

This patch series adds some basic api functions to the submodule interface as well as teaching grep to recursively search in submodules. The additions to the submodule interface allow grep to verify that a submodule has been initialized and checked out prior to launching a child process. One

Re: Expanding Includes in .gitignore

On 28/10/16 10:07, Jeff King wrote: > I think it does > introduce compatibility complications. People with older git will not > respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local > matter. I know. I don't think it's a serious compatibility issue, but more important people

Re: feature request

On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > Users should be able to configure Git to not send them into a Vim editor. > > When users pull commits, and a new commit needs to be created for a > merge, Git's current way of determining a commit message is to send > the

Re: feature request

John Rood writes: > I suppose I can do git config --global core.editor notepad > However, this really only addresses my second concern. > > My first concern is that using a text editor at all seems like > overkill in many scenarios. Nobody stops you from writing a "type

Re: feature request

I suppose I can do git config --global core.editor notepad However, this really only addresses my second concern. My first concern is that using a text editor at all seems like overkill in many scenarios. For that reason, I still think the other two options I mentioned would be beneficial. On

[PATCH] 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: Expanding Includes in .gitignore

On 28/10/16 10:55, Aaron Pelly wrote: > 2) I fetch a repo with a hostile ignore file. It includes files from > $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay > attention. Commit. Push. Problems if my test data comes from production. > > Is this mitigated currently? > > Not that

[PATCH] valgrind: support test helpers

Tests run with --valgrind call git commands through a wrapper script that invokes valgrind on them. This script (valgrind.sh) is in turn invoked through symlinks created for each command in t/valgrind/bin/. Since e6e7530d (test helpers: move test-* to t/helper/ subdirectory) these symlinks have

Re: feature request

Unfortunately, in my case I'm on windows (my company's choice, not mine). On Thu, Oct 27, 2016 at 5:01 PM, Stefan Beller wrote: > On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: >> Users should be able to configure Git to not send them into a Vim

Re: feature request

On Thu, Oct 27, 2016 at 2:55 PM, John Rood wrote: > Users should be able to configure Git to not send them into a Vim editor. See https://git-scm.com/docs/git-var GIT_EDITOR Text editor for use by Git commands. The value is meant to be interpreted by the shell when it

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

> there isn't really a great place to put a dynamic initialization. Answering this question specifically (Where to put it?), I am about to send out a patch that puts it in compat/mingw.c:2232: diff --git a/compat/mingw.c b/compat/mingw.c index 3fbfda5..9881c3d 100644 --- a/compat/mingw.c +++

Re: Expanding Includes in .gitignore

On 28/10/16 09:55, Jeff King wrote: > On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote: > >>> - we parse possibly-hostile .gitignore files from cloned repositories. >>> What happens when I include ask to include /etc/passwd? Probably >>> nothing, but there are setups where it

feature request

Users should be able to configure Git to not send them into a Vim editor. When users pull commits, and a new commit needs to be created for a merge, Git's current way of determining a commit message is to send the user into a Vim window so that they can write a message. There are 2 reasons why

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

On Thu, Oct 27, 2016 at 1:05 PM, Johannes Sixt wrote: >> The implementation under discussion (well we did not discuss the >> implementation a >> whole lot yet) ... > > > There's not a whole lot to discuss: it must be rewritten from scratch (it's > not just the memory barriers, it

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

Jeff King writes: > +cc Linus as the original author of 144bde78e9 in case there is > something subtle I'm missing, but this really just seems like it's > an outdated optimization. > > -- >8 -- > Subject: [PATCH] sha1_file: stop opening files with O_NOATIME > > When we open object

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 2:04 PM, Jeff King wrote: > I'm not convinced this is needed for in-repo .gitignore files. The point > is that you are pulling together separate files that may be administered > independently. But git repositories inherently have a whole-project > view. I'm

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

On Wed, Oct 26, 2016 at 6:33 AM, Duy Nguyen wrote: > (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) > >

Re: Expanding Includes in .gitignore

On 28/10/16 10:04, Jeff King wrote: > On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote: > >>> I think the normal behavior in such "foo.d" directory is to just sort >>> the contents lexically and read them in order, as if they were all >>> concatenated together, and with no recursion.

Re: [PATCH v2 2/2] convert.c: stream and fast search for binary

tbo...@web.de writes: > From: Torsten Bögershausen > > When statistics are done for the autocrlf handling, the search in > the content can be stopped, if e.g > - a search for binary is done, and a NUL character is found > - a search for CRLF is done, and the first CRLF is found. >

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote: > On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote: > > > > - we parse possibly-hostile .gitignore files from cloned repositories. > > > What happens when I include ask to include /etc/passwd? Probably > > > nothing,

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote: > > I think the normal behavior in such "foo.d" directory is to just sort > > the contents lexically and read them in order, as if they were all > > concatenated together, and with no recursion. I.e., behave "as if" the > > user had

Re: Expanding Includes in .gitignore

On 28/10/16 08:48, Jacob Keller wrote: > I would strongly prefer rc.d style directories either with a "if the > .gitignore is a directory treat it like rc.d" or even "add support for > .gitignore.d as well as .gitignore" I think adding .gitignore.d shouldn't break existing systems, is intuitive,

Re: [PATCH 17/36] attr: expose validity check for attribute names

On Mon, Oct 24, 2016 at 2:07 PM, Stefan Beller wrote: > On Sun, Oct 23, 2016 at 8:07 AM, Ramsay Jones > wrote: >> >> >> On 23/10/16 00:32, Stefan Beller wrote: >>> From: Junio C Hamano >>> >>> Export attr_name_valid() function,

Re: Expanding Includes in .gitignore

On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote: > > - we parse possibly-hostile .gitignore files from cloned repositories. > > What happens when I include ask to include /etc/passwd? Probably > > nothing, but there are setups where it might matter (e.g., something > >

Re: [PATCH] git-svn: do not reuse caches memoized for a different architecture

Junio C Hamano wrote: > Just peeking from the sideline, but the your squash looks like an > improvement to me. Thanks. > Hopefully the final version after your interaction with Dscho can > come to me via another "pull this now"? Not sure if I'll be online the next few days,

Re: Drastic jump in the time required for the test suite

Johannes Schindelin wrote: > I know you are a fan of testing things thoroughly in the test suite, but I > have to say that it is getting out of hand, in particular due to our > over-use of shell script idioms (which really only run fast on Linux, not > a good idea for

Re: Expanding Includes in .gitignore

On 27/10/16 23:50, Jeff King wrote: > I'd shy away from an actual include directive, as it raises a lot of > complications: I'm leaning that way now too. > - we parse possibly-hostile .gitignore files from cloned repositories. > What happens when I include ask to include /etc/passwd?

Re: [PATCH v15 01/27] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

On Thu, Oct 27, 2016 at 6:59 PM, Junio C Hamano wrote: > Cc'ed those who touched either "git-bisect.sh" or "builtin/bisect-helper.c" > in our relatively recent past. > > Does any of you (and others on the list) have time and inclination > to review this series? As part of my

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

Am 27.10.2016 um 21:08 schrieb Stefan Beller: On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote: Johannes Sixt writes: Am 27.10.2016 um 19:01 schrieb Stefan Beller: ... It is not possible to mark a mutex uninitialized on Windows without an extra piece

Re: [PATCH v2 1/2] read-cache: factor out get_sha1_from_index() helper

tbo...@web.de writes: > From: Torsten Bögershausen > > Factor out the retrieval of the sha1 for a given path in > read_blob_data_from_index() into the function get_sha1_from_index(). > > This will be used in the next commit, when convert.c can do the > analyze for "text=auto"

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 3:50 AM, Jeff King wrote: > On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote: > >> 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

Re: [PATCH] git-svn: do not reuse caches memoized for a different architecture

Eric Wong writes: > Johannes Schindelin wrote: >> +++ b/perl/Git/SVN.pm >> @@ -1658,6 +1658,11 @@ sub tie_for_persistent_memoization { >> if ($memo_backend > 0) { >> tie %$hash => 'Git::SVN::Memoize::YAML', "$path.yaml"; >> }

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

On Thu, Oct 27, 2016 at 11:49 AM, Junio C Hamano wrote: > Johannes Sixt writes: > >> Am 27.10.2016 um 19:01 schrieb Stefan Beller: >> ... >> It is not possible to mark a mutex uninitialized on Windows without an >> extra piece of data. A solution would become

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

Johannes Sixt writes: > Am 27.10.2016 um 19:01 schrieb Stefan Beller: > ... > It is not possible to mark a mutex uninitialized on Windows without an > extra piece of data. A solution would become quite complicated quite > quickly, and at the cost of additional operations that are

Re: [PATCH] Update git rebase documentation to clarify HEAD behavior

From: "Junio C Hamano" Cody Sehl writes: The first few paragraphs in the git-rebase.txt documentation lay out the steps git takes during a rebase: 1. everything from `..HEAD` is saved to a temporary area 2. `HEAD` is set to `` 3. the changes held in

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

Michael J Gruber writes: > It did not exist, but even at that point in time, "git log A..B" listed > only commits between the merge base and B, not those which are only in A > and not in B. Whereas "git diff A B" shows the differences between the > endpoints A and B.

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

Stefan Beller writes: > The pathspec mechanism is extended via the new > ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it > requires paths to not just match the given pattern but also have the > specified attrs attached for them to be chosen. I was

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

Am 27.10.2016 um 19:01 schrieb Stefan Beller: Johannes Sixt writes: This is the pessimization that I am talking about. I would not mind at all if it were only for the attribute subsystem, but the proposed patch would pessimize *all* uses of pthread_mutex_lock. It would only

Re: [PATCH] git-compat-util: move content inside ifdef/endif guards

Jeff King writes: > Commit 3f2e2297b9 (add an extra level of indirection to > main(), 2016-07-01) added a declaration to git-compat-util.h, > but it was accidentally placed after the final #endif that > guards against multiple inclusions. > > This doesn't have any actual impact on

[PATCH] git-compat-util: move content inside ifdef/endif guards

Commit 3f2e2297b9 (add an extra level of indirection to main(), 2016-07-01) added a declaration to git-compat-util.h, but it was accidentally placed after the final #endif that guards against multiple inclusions. This doesn't have any actual impact on the code, since it's not incorrect to repeat

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

On Thu, Oct 27, 2016 at 10:01:02AM -0700, Stefan Beller wrote: > > That function can > > be called from main() of platforms that cannot statically initialize > > mutices, > > By main you mean the main() in common-main.c or cmd_main in git.c ? Any setup or initialization for library functions

Re: [PATCH v4 00/14] Mark strings in Perl scripts for translation

> Vasco Almeida (14): > i18n: add--interactive: mark strings for translation > i18n: add--interactive: mark simple here-documents for translation > i18n: add--interactive: mark strings with interpolation for > translation > i18n: clean.c: match string with git-add--interactive.perl >

Re: [PATCH v2 0/2] Stream and fast search

Cc'ed those who touched convert.c or read-cache.c in our relatively recent past with a change that affects the eol conversion codepath. Does any of you (and others on the list) have time and inclination to review this series? Thanks.

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

> Johannes Sixt writes: > This is the pessimization that I am talking about. I would not mind at all if > it were only for the attribute subsystem, but the proposed patch would > pessimize *all* uses of pthread_mutex_lock. It would only pessimize *uninitialized* mutexes? For

Re: [PATCH v15 01/27] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Cc'ed those who touched either "git-bisect.sh" or "builtin/bisect-helper.c" in our relatively recent past. Does any of you (and others on the list) have time and inclination to review this series? Thanks.

Re: [PATCH] reset: --unmerge

Andreas Schwab writes: > On Okt 25 2016, 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-< > > This is consistent with the behaviour of the other VC

Re: [PATCH v1 16/19] read-cache: unlink old sharedindex files

Duy Nguyen writes: > Christian, if we assume to go with Junio's suggestion to disable > split-index on temporary files, the only files left we have to take > care of are index and index.lock. I believe pruning here in this code > will have an advantage over in "git gc --auto"

Re: [PATCH] reset: --unmerge

On Okt 25 2016, 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-< This is consistent with the behaviour of the other VC backends, where it isn't even customizable. Andreas. --

Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

Hi Hannes, On Tue, 25 Oct 2016, Johannes Sixt wrote: > Am 25.10.2016 um 20:13 schrieb Stefan Beller: > > On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano wrote: > > > - the "off-by-one fix" part of sb/submodule-ignore-trailing-slash > > >needs to be in the upcoming

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote: > 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

Re: [PATCH v1 16/19] read-cache: unlink old sharedindex files

On Tue, Oct 25, 2016 at 5:43 PM, Duy Nguyen wrote: >> static int write_shared_index(struct index_state *istate, >> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state >> *istate, >> } >> ret = rename_tempfile(_sharedindex, >>

Re: Expanding Includes in .gitignore

On 27/10/16 21:19, Alexei Lozovsky wrote: >> I'm thinking something like ". path/to/include/file" in an ignore file, >> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore >> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent >> mixture of these things. > >

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

On Wed, Oct 26, 2016 at 11:51 PM, Junio C Hamano wrote: > 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

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

On Wed, Oct 26, 2016 at 02:15:33PM -0700, Junio C Hamano wrote: > 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

Re: Expanding Includes in .gitignore

On 27/10/16 15:22, Stefan Beller wrote: >> 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

Re: [PATCH v1 16/19] read-cache: unlink old sharedindex files

On Thu, Oct 27, 2016 at 12:25 PM, Duy Nguyen wrote: > On Tue, Oct 25, 2016 at 5:43 PM, Duy Nguyen wrote: >>> static int write_shared_index(struct index_state *istate, >>> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state >>> *istate,

Re: Expanding Includes in .gitignore

> I'm thinking something like ". path/to/include/file" in an ignore file, > and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore > and $GIT_DIR/info/exclude to be directories. Or some sane and consistent > mixture of these things. I think the rc.d-like approach with directories

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

Junio C Hamano venit, vidit, dixit 26.10.2016 20:11: > 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

Re: [PATCH] Update git rebase documentation to clarify HEAD behavior

Cody Sehl writes: > The first few paragraphs in the git-rebase.txt documentation lay out the > steps git takes during a rebase: > 1. everything from `..HEAD` is saved to a temporary area > 2. `HEAD` is set to `` > 3. the changes held in the temporary area are applied one by

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

Junio C Hamano writes: > Johannes Sixt writes: > >>> As many codepaths may not even need access to the attributes, I >>> doubt that would be a very productive direction to go. >> >> So, what is productive then? Pessimizing one (not exactly minor) platform? > >

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

Am 27.10.2016 um 08:21 schrieb Junio C Hamano: Johannes Sixt writes: As many codepaths may not even need access to the attributes, I doubt that would be a very productive direction to go. So, what is productive then? Pessimizing one (not exactly minor) platform? Lazy

[PATCH] Update git rebase documentation to clarify HEAD behavior

The first few paragraphs in the git-rebase.txt documentation lay out the steps git takes during a rebase: 1. everything from `..HEAD` is saved to a temporary area 2. `HEAD` is set to `` 3. the changes held in the temporary area are applied one by one in order on top of the new `HEAD` The second

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

Johannes Sixt writes: >> As many codepaths may not even need access to the attributes, I >> doubt that would be a very productive direction to go. > > So, what is productive then? Pessimizing one (not exactly minor) platform? Lazy on-demand initialization as needed, perhaps? The

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

Am 27.10.2016 um 08:02 schrieb Junio C Hamano: Johannes Sixt writes: 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,

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

Johannes Sixt writes: > 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

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

Junio C Hamano writes: > 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