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

On Tue, Oct 25, 2016 at 11:16:20AM -0700, Junio C Hamano wrote: > diff --git a/sha1_file.c b/sha1_file.c > index 5d2bcd3ed1..09045df1dc 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -1571,12 +1571,17 @@ int git_open(const char *name) > if (fd >= 0) >

A bug with "git svn show-externals"

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 result in an unusable output. Example: $ svn

Re: [PATCH] Allow stashes to be referenced by index only

On 25/10/16 22:41, Junio C Hamano wrote: > Aaron M Watson writes: > > Aaron M Watson writes: > >> Instead of referencing "stash@{n}" explicitly, it can simply be >> referenced as "n". >> Most users only reference stashes by their position >> in the

Re: [PATCH] reset: --unmerge

Duy Nguyen writes: > BTW making git-add (and "git commit -a") refuse files with conflict > markers present could prevent this mistake earlier and is probably a > better option because the user won't have to discover 'reset > --unmerge'. That may help some users, but you are

Re: [PATCH v3 0/3] quick reroll of Lars's git_open() w/ O_CLOEXEC

Lars Schneider writes: > heavy CPU/network task in the background now (I can't/don't want to > stop that ATM). > > Here is the relevant part of the log: > > ++ rm -f rot13-filter.log > ++ git checkout --quiet --no-progress . > + test_eval_ret_=255 > + want_trace > +

Re: [PATCH v3 3/3] read-cache: make sure file handles are not inherited by child processes

Eric Wong writes: > But I have a _slight_ preference towards Dscho's version in > in case we > decide to start using another O_* flag in here. Interesting. The reason why I have a slight preferene to separate the fixed part and

Re: [PATCH v3 0/3] quick reroll of Lars's git_open() w/ O_CLOEXEC

> On 25 Oct 2016, at 20:16, Junio C Hamano wrote: > > Here is to make sure everybody is on the same page regarding the > series. The patches are adjusted for comments from Eric and Dscho. Thank you, Junio! Your v3 looks good to me and I compiled and tested it on Windows.

Re: [PATCH] Allow stashes to be referenced by index only

Aaron M Watson writes: Aaron M Watson writes: > Instead of referencing "stash@{n}" explicitly, it can simply be > referenced as "n". > Most users only reference stashes by their position > in the stash stask (what I refer to as the "index"). It is

Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes

Am 24.10.2016 um 21:53 schrieb Lars Schneider: On 24 Oct 2016, at 21:22, Johannes Sixt wrote: Am 24.10.2016 um 20:03 schrieb larsxschnei...@gmail.com: From: Lars Schneider This fixes "convert: add filter..process option" (edcc8581) on Windows.

Re: [PATCH v3 3/3] read-cache: make sure file handles are not inherited by child processes

Junio C Hamano wrote: > @@ -156,7 +156,14 @@ void fill_stat_cache_info(struct cache_entry *ce, struct > stat *st) > static int ce_compare_data(const struct cache_entry *ce, struct stat *st) > { > int match = -1; > - int fd = open(ce->name, O_RDONLY); > + static

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

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 release but the "trailing /. in base should not affect the resolution of

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

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"; > } else { > + # first verify that

Re: password forgot

That is asking for your local computer password. This uninstaller also has nothing to do with git itself, but with the third-party git package you installed. The git project does not ship an 'uninstall.sh' On Tue, 2016-10-25 at 13:23 -0300, Luciano Schillagi wrote: > sorry, I'm a little confused

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

Jeff King writes: > On Mon, Oct 24, 2016 at 06:09:00PM -0700, Junio C Hamano wrote: > >> - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto >>scaling the default abbreviation length when Git produces a short >>object name to adjust to the modern times. Peff

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

Jeff King writes: >> diff --git a/path.c b/path.c >> index fe3c4d96c6..9bfaeda207 100644 >> --- a/path.c >> +++ b/path.c >> @@ -24,7 +24,8 @@ static struct strbuf *get_pathname(void) >> STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT >> }; >> static int

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

Stefan Beller writes: > Ok. The first 2 patches are in good shape for this cycle, though. I thought both of you knew we are in agreement on that by now, but yes, the off-by-one fix needs to be in the upcoming release. > So maybe instead of adding !MINGW we rather want to

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

On Tue, Oct 25, 2016 at 11:28:40AM -0700, Junio C Hamano wrote: > OK, here is what I'll queue then. > I assumed that René wants to sign it off ;-). > > -- >8 -- > From: René Scharfe > Date: Sun, 23 Oct 2016 19:57:30 +0200 > Subject: [PATCH] hex: make wraparound of the index into

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

On Mon, Oct 24, 2016 at 06:09:00PM -0700, Junio C Hamano wrote: > - lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto >scaling the default abbreviation length when Git produces a short >object name to adjust to the modern times. Peff noticed one >fallout from it

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

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 signed overflow anymore. >> >>

[PATCH v3 0/3] quick reroll of Lars's git_open() w/ O_CLOEXEC

Here is to make sure everybody is on the same page regarding the series. The patches are adjusted for comments from Eric and Dscho. Lars Schneider (3): sha1_file: rename git_open_noatime() to git_open() sha1_file: open window into packfiles with O_CLOEXEC read-cache: make sure file handles

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

From: Lars Schneider All processes that the Git main process spawns inherit the open file descriptors of the main process. These leaked file descriptors can cause problems. Use the O_CLOEXEC flag similar to 05d1ed61 to fix the leaked file descriptors. Signed-off-by:

[PATCH v3 1/3] sha1_file: rename git_open_noatime() to git_open()

From: Lars Schneider This function is meant to be used when reading from files in the object store, and the original objective was to avoid smudging atime of loose object files too often, hence its name. Because we'll be extending its role in the next commit to also

[PATCH v3 3/3] read-cache: make sure file handles are not inherited by child processes

From: Lars Schneider This fixes "convert: add filter..process option" (edcc8581) on Windows. Consider the case of a file that requires filtering and is present in branch A but not in branch B. If A is the current HEAD and we checkout B then the following happens: 1.

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

On Tue, Oct 25, 2016 at 10:15 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> One of the initial ways to work around the bugfix was to >> >> git clone . root # <- add in this step and it works again. >> git clone root super >> >> but instead

Re: [PATCH] reset: --unmerge

Junio C Hamano writes: > The procedure to resolve a merge conflict typically goes like this: > > - first open the file in the editor, and with the help of conflict >markers come up with a resolution. > > - save the file. > > - look at the output from "git diff" to see

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

Duy Nguyen writes: > ... But those files > people generate manually and refer to them with $GIT_INDEX_FILE, we > can't know where they are. Then we probably should stop doing that, i.e. disable split-index automatically for these temporary ones, perhaps, and even with

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

Stefan Beller writes: > One of the initial ways to work around the bugfix was to > > git clone . root # <- add in this step and it works again. > git clone root super > > but instead I will do the preparation for the 'super' project not > in '.' but in 'root', just

Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes

Johannes Schindelin writes: > That still looks overly complicated, repeatedly ORing cloexec and > recursing without need. How about this instead? > > static int oflags = O_RDONLY | O_CLOEXEC; > int fd = open(ce->name, oflags); > > if ((O_CLOEXEC &

Re: [PATCH v2 1/2] sha1_file: open window into packfiles with CLOEXEC

Johannes Schindelin writes: > The patch series may be a little bit more pleasant to read if you renamed > git_open_noatime() to git_open() first, in a separate commit. Possibly. If this were "we added a new parameter at the same time and each calling site of the

pre-planning for git contributor's summit: Feb 2, 2017, Brussels

GitHub is organizing Git Merge 2017, and is offering space to do another contributor's summit. I want to share what details I have so far, get any input on what we want the event to be like, and see who's interested in coming (for venue planning purposes). The details below are still tentative,

Re: password forgot

On Tue, 2016-10-25 at 12:52 -0300, Luciano Schillagi wrote: > Hi, > > I forgot my password in git, such as resetting? Hi Luciano, Git itself doesn't do any authentication, so I assume you lost the password for an account on a hosted git solution such as gitlab or github. You should contact the

password forgot

Hi, I forgot my password in git, such as resetting? Thank You Luciano

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

From: Gavin Lambert Reusing cached data speeds up git-svn by quite a fair bit. However, if the YAML module is unavailable, the caches are written to disk in an architecture-dependent manner. That leads to problems when upgrading, say, from 32-bit to 64-bit Git for Windows.

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

On Tue, Oct 25, 2016 at 07:38:30PM +0700, Duy Nguyen wrote: > > diff --git a/environment.c b/environment.c > > index cd5aa57..b1743e6 100644 > > --- a/environment.c > > +++ b/environment.c > > @@ -164,8 +164,11 @@ static void setup_git_env(void) > > const char *replace_ref_base; > > > >

Re: Integrating submodules with no side effects

On Wed, Oct 19, 2016 at 2:51 PM, Robert Dailey wrote: > On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller wrote: >> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey >> wrote: >>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller

Re: [PATCH 1/7] read info/{attributes,exclude} only when in repository

On Tue, Oct 25, 2016 at 07:24:50PM +0700, Duy Nguyen wrote: > > Let's detect this situation explicitly and skip reading the > > file (i.e., the same behavior we'd get if we were in a > > repository and the file did not exist). > > On the other hand, if we invoke attr machinery too early by

Re: %C(auto) not working as expected

On Tue, Oct 25, 2016 at 7:58 PM, Jeff King wrote: > On Tue, Oct 25, 2016 at 07:52:21PM +0700, Duy Nguyen wrote: > >> > Yeah, adding a "%C(enable-auto-color)" or something would be backwards >> > compatible and less painful than using "%C(auto)" everywhere. I do >> > wonder if

Re: %C(auto) not working as expected

On Tue, Oct 25, 2016 at 07:52:21PM +0700, Duy Nguyen wrote: > > Yeah, adding a "%C(enable-auto-color)" or something would be backwards > > compatible and less painful than using "%C(auto)" everywhere. I do > > wonder if anybody actually _wants_ the "always show color, even if > > --no-color"

Re: %C(auto) not working as expected

On Mon, Oct 10, 2016 at 9:28 PM, Jeff King wrote: > On Mon, Oct 10, 2016 at 04:26:18PM +0700, Duy Nguyen wrote: > >> > If we do a revamp of the pretty-formats to bring them more in line with >> > ref-filter (e.g., something like "%(color:red)") maybe that would be an >> >

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

On Thu, Oct 20, 2016 at 1:24 PM, Jeff King wrote: > This passes the test suite (after the adjustments in the > previous patches), but there's a risk of regression for any > cases where the fallback usually works fine but the code > isn't exercised by the test suite. So by itself,

Re: [PATCH 1/7] read info/{attributes,exclude} only when in repository

On Thu, Oct 20, 2016 at 1:16 PM, Jeff King wrote: > The low-level attribute and gitignore code will try to look > in $GIT_DIR/info for any repo-level configuration files, > even if we have not actually determined that we are in a > repository (e.g., running "git grep --no-index").

Re: [RFH] limiting ref advertisements

On Mon, Oct 24, 2016 at 8:29 PM, Jeff King wrote: > I'm looking into the oft-discussed idea of reducing the size of ref > advertisements by having the client say "these are the refs I'm > interested in". Let's set aside the protocol complexities for a > moment and imagine we

Re: [PATCH] doc: fix the 'revert a faulty merge' ASCII art tab spacing

Hi Philip, On Mon, 24 Oct 2016, Philip Oakley wrote: > The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' > rule > expectation, particularly for the Git-for-Windows generated html pages. This > follows on from the 'doc: fix merge-base ASCII art tab spacing' fix. > >

Re: [PATCH v2 0/2] Use CLOEXEC to avoid fd leaks

Hi Lars, On Mon, 24 Oct 2016, larsxschnei...@gmail.com wrote: > This mini patch series is necessary to make the "ls/filter-process" topic > work properly for Windows. Right now the topic generates test failures > on Windows as reported by Dscho: >

Re: [PATCH] reset: --unmerge

On Tue, Oct 25, 2016 at 6:06 PM, Duy Nguyen wrote: > On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano wrote: >> The procedure to resolve a merge conflict typically goes like this: >> >> - first open the file in the editor, and with the help of conflict >>

Re: [PATCH] reset: --unmerge

On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano wrote: > The procedure to resolve a merge conflict typically goes like this: > > - first open the file in the editor, and with the help of conflict >markers come up with a resolution. > > - save the file. > > - look at the

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

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > +static int can_delete_shared_index(const char *shared_sha1_hex) > +{ > + struct stat st; > + unsigned long expiration; > + const char *shared_index = git_path("sharedindex.%s", >

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

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > Goal > > > We want to make it possible to use the split-index feature > automatically by just setting a new "core.splitIndex" configuration > variable to true. Thanks. This definitely should help make

Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes

Hi Junio, On Mon, 24 Oct 2016, Junio C Hamano wrote: > Eric Wong writes: > > > larsxschnei...@gmail.com wrote: > >> +++ b/read-cache.c > >> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce, > >> struct stat *st) > >> static int ce_compare_data(const

Re: [PATCH v2 1/2] sha1_file: open window into packfiles with CLOEXEC

Hi Lars, On Mon, 24 Oct 2016, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > All processes that the Git main process spawns inherit the open file > descriptors of the main process. These leaked file descriptors can > cause problems. > > Use the CLOEXEC

Re: [PATCH v1 14/19] read-cache: touch shared index files when used

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > @@ -2268,6 +2268,12 @@ int write_locked_index(struct index_state *istate, > struct lock_file *lock, Doing this in read_index_from() would keep the shared file even more "fresher" since read happens a lot more

Re: [PATCH v1 10/19] read-cache: regenerate shared index if necessary

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > @@ -2233,7 +2263,8 @@ int write_locked_index(struct index_state *istate, > struct lock_file *lock, > if ((v & 15) < 6) > istate->cache_changed |= SPLIT_INDEX_ORDERED; >

Re: [PATCH v1 09/19] config: add git_config_get_max_percent_split_change()

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > This new function will be used in a following commit to get the > +int git_config_get_max_percent_split_change(void) > +{ > + int val = -1; > + > + if

Re: [PATCH v1 05/19] update-index: warn in case of split-index incoherency

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > When users are using `git update-index --(no-)split-index`, they > may expect the split-index feature to be used or not according to > the option they just used, but this might not be the case if the > new

Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions

On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder wrote: > +void remove_split_index(struct index_state *istate) > +{ > + if (istate->split_index) { > + /* > +* can't discard_split_index(_index); because that > +* will

Re: [PATCH 0/4] nd/ita-empty-commit update

On Tue, Oct 25, 2016 at 12:58 AM, Junio C Hamano wrote: >> The name ita-invisible-in-index is not perfect but I could not think >> of any better. Another name could be diff-cached-ignores-ita, but >> that's just half of what it does. The other half is >>

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

On Tue, Oct 25, 2016 at 1:07 AM, Junio C Hamano wrote: >> - splitIndex.sharedIndexExpire >> >> To make sure that old sharedindex files are eventually removed >> when a new one has been created, we "touch" the shared index file >> every time it is used by a new

Re: Reporting Bug in Git Version Control System

Hey Yash, Junio has explained the problem very well. Since you seem to be a beginner (guessing purely by your email) I will tell you how to fix it. Remember when you would have first installed git, you would have done something like `git config --global user.name ` and `git config --global

Re: [PATCH] Allow stashes to be referenced by index only

On Tue, Oct 25, 2016 at 4:11 AM, Jeff King wrote: > On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote: > >> Instead of referencing "stash@{n}" explicitly, it can simply be >> referenced as "n". Most users only reference stashes by their position >> in the stash stask

Re: [PATCH] Allow stashes to be referenced by index only

On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote: > Instead of referencing "stash@{n}" explicitly, it can simply be > referenced as "n". Most users only reference stashes by their position > in the stash stask (what I refer to as the "index"). The syntax for the > typical stash