tiffany jewellery can be mastered immediately

tiffany jewellery possesses currently employed brand names you'll find singular person in be anxious in addition to build a a lot of unique a number of earrings just as usual sterling silver armlet to help sterling silver necklaces earrings. For anyone who

Re: [PATCH] tag: --force is quiet about new tags

On Tue, Mar 12, 2013 at 11:33 PM, Junio C Hamano wrote: > Phil Hord writes: > >> git tag --force is used to replace an existing tag with >> a new reference. Git helpfully tells the user the old >> ref when this happens. But if the tag name is new and does >> not exist, git tells the user the ol

[PATCH 2/2] add: respect add.updateroot config option

The `git add -u` command operates on the current subdir of the repository, but is transitioning to operate on the whole repository (see commit 0fa2eb5 for details). During the transition period, we issue a warning. For users who have read and accepted the warning, there is no way to jump directly t

[PATCH 1/2] t2200: check that "add -u" limits itself to subdirectory

This behavior is due to change in the future, but let's test it anyway. That helps make sure we do not accidentally switch the behavior too soon while we are working in the area, and it means that we can easily verify the change when we do make it. Signed-off-by: Jeff King --- We didn't seem to b

Re: [PATCH 1/2] require pathspec for "git add -u/-A"

On Tue, Mar 12, 2013 at 02:58:44PM +0100, Matthieu Moy wrote: > > I guess we already rejected the idea of being able to shut off the > > warning and just get the new behavior, in favor of having people > > specify it manually each time? > > Somehow, but we may find a way to do so, as long as it t

Re: [PATCH] tag: --force is quiet about new tags

Phil Hord writes: > git tag --force is used to replace an existing tag with > a new reference. Git helpfully tells the user the old > ref when this happens. But if the tag name is new and does > not exist, git tells the user the old ref anyway (00). > > Teach git to ignore --force if the ta

Re: linux-next: unneeded merge in the security tree

Theodore Ts'o writes: > On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote: >> Theodore Ts'o writes: >> >> > [remote "origin"] >> >url = >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> >fetch = +refs/heads/master:refs/heads/master >> >mergeo

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote: > Theodore Ts'o writes: > > > [remote "origin"] > > url = > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > fetch = +refs/heads/master:refs/heads/master > > mergeoptions = --ff-only > > > > Is

Re: [PATCH v3 1/3] mergetools/p4merge: swap LOCAL and REMOTE

On Tue, Mar 12, 2013 at 6:12 PM, Kevin Bracey wrote: > Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that > the incoming branch is now in the left-hand, blue triangle pane, and the > current branch is in the right-hand, green circle pane. > > This change makes use of P4Merge co

Nike Free Damen

Der müde Nike Free Run 4.0 Nacht ohne Lanna, wie Bohnen Randeng. Smoke verschwommenes Monaten Yu Xuefei micro. Ich stand Xianting Central, Rauch Januar weiß gefärbt frost sehen, hören den Schnee von der Schulter, die Brise in eine Blume Blüte im Ohr, wie ei

[PATCH v3 1/3] mergetools/p4merge: swap LOCAL and REMOTE

Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that the incoming branch is now in the left-hand, blue triangle pane, and the current branch is in the right-hand, green circle pane. This change makes use of P4Merge consistent with its built-in help, its reference documentation, a

Re: [PATCH v3 05/13] match_{base,path}name: replace strncmp_icase with memequal_icase

On Tue, Mar 12, 2013 at 8:04 PM, Nguyễn Thái Ngọc Duy wrote: > +static inline int memequal_icase(const char *a, const char *b, int n) > +{ > + if (!memcmp(a, b, n)) > + return 1; > + > + if (!ignore_case) > + return 0; > + > + /* > +* This assu

[PATCH v3 3/3] git-merge-one-file: revise merge error reporting

Commit 718135e improved the merge error reporting for the resolve strategy's merge conflict and permission conflict cases, but led to a malformed "ERROR: in myfile.c" message in the case of a file added differently. This commit reverts that change, and uses an alternative approach without this fl

[PATCH v3 2/3] mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED" Commit 0a0ec7bd changed this to: p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED" to avoid the problem of being unable to save in some circumstances with similar inputs. Unfo

Re: [PATCH v2 3/6] match_basename: use strncmp instead of strcmp

On Wed, Mar 13, 2013 at 3:59 AM, Junio C Hamano wrote: >>> strncmp is provided length information which could be taken advantage >>> by the underlying implementation. > > After all, strcmp() could also be optimized to fetch word-at-a-time > while being careful about not overstepping the page bound

Re: [PATCH v3 04/13] match_basename: use strncmp instead of strcmp

On Wed, Mar 13, 2013 at 12:40 AM, Antoine Pelisse wrote: >> --- a/dir.c >> +++ b/dir.c >> @@ -636,12 +636,14 @@ int match_basename(const char *basename, int >> basenamelen, >>int flags) >> { >> if (prefix == patternlen) { >> - if (!strcmp_icase(pattern,

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees wrote: > Hmmm...I don't see how filesystem changes since last invocation can solve the > problem, or am I missing something? I think what you mean to say is that the > daemon should keep track of the filesystem *state* of the working copy, or > alt

Re: [PATCH] difftool: Make directory diff symlink work tree

On Tue, Mar 12, 2013 at 3:24 PM, John Keeping wrote: > When I tried this I got the expected behaviour even without this patch. > > It turns out that an uncommitted, but *staged* change emits the SHA1 of > the blob rather than the null SHA1. Do you get the desired behaviour if > you "git reset" be

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 04:48:16PM -0600, Matt McClure wrote: > On Mar 12, 2013, at 4:16 PM, Junio C Hamano wrote: > > > Matt McClure writes: > > > > * If you are comparing two trees, and especially if your RHS is not > > HEAD, you will send everything to a temporary without > > symlinks. An

Re: [PATCH 14/19] Document pull-all and push-all

On Tue, Mar 12, 2013 at 3:12 PM, Holger Hellmuth (IKS) wrote: > Am 09.03.2013 20:28, schrieb Paul Campbell: > >> From 7dcd40ab8687a588b7b0c6ff914a7cfb601b6774 Mon Sep 17 00:00:00 2001 >> From: Herman van Rink >> Date: Tue, 27 Mar 2012 13:59:16 +0200 >> Subject: [PATCH 14/19] Document pull-all an

Re: Questions/investigations on git-subtree and tags

On Tue, Mar 12, 2013 at 10:02 AM, Jeremy Rosen wrote: > Paul, I'm not quite sure where I should go from here... > > should I send you a patch so you make it a V3 of your patch ? should I > send a patch superseeding yours ? > > I have also found a similar problem in git-subtree pull, which needs >

Re: [PATCH] difftool: Make directory diff symlink work tree

On Tue, Mar 12, 2013 at 05:12:28PM -0600, Matt McClure wrote: > On Mar 12, 2013, at 1:25 PM, John Keeping wrote: > > > When I tried this I got the expected behaviour even without this patch. > > git diff --raw commit > > emits the null SHA1 if the working tree file's stat differs from the >

[PATCH] tag: --force is quiet about new tags

git tag --force is used to replace an existing tag with a new reference. Git helpfully tells the user the old ref when this happens. But if the tag name is new and does not exist, git tells the user the old ref anyway (00). Teach git to ignore --force if the tag is new. Add a test for this

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

Am 10.03.2013 21:17, schrieb Ramkumar Ramachandra: > git operations are slow on repositories with lots of files, and lots > of tiny filesystem calls like lstat(), getdents(), open() are > reposible for this. On the linux-2.6 repository, for instance, the > numbers for "git status" look like this:

Re: [PATCH v3 09/13] exclude: filter out patterns not applicable to the current directory

On Tue, Mar 12, 2013 at 9:04 AM, Nguyễn Thái Ngọc Duy wrote: > The algorithm implemented here is a naive one. Patterns can be either > active or passive: > > - When we enter a new directory (e.g. from root to foo), currently >active patterns may no longer be applicable and can be turned to >

Re: [PATCH] difftool: Make directory diff symlink work tree

On Mar 12, 2013, at 1:25 PM, John Keeping wrote: > When I tried this I got the expected behaviour even without this patch. git diff --raw commit emits the null SHA1 if the working tree file's stat differs from the blob corresponding to commit. Is that the case you observed? -- To unsubscrib

Re: difftool -d symlinks, under what conditions

On Mar 12, 2013, at 4:16 PM, Junio C Hamano wrote: > Matt McClure writes: > >> An alternative approach would be to reuse git-diff's option parsing > > I do not think you want to go there. That wouldn't solve the third > case in my previous message, no? I think I don't fully understand your thi

Re: [PATCH v8 2/5] blame: introduce $ as "end of file" in -L syntax

Junio C Hamano writes: > Thomas Rast writes: > >> To save the user a lookup of the last line number, introduce $ as a >> shorthand for the last line. This is mostly useful to spell "until >> the end of the file" as '-L,$'. > > Doesn't "-L " or "-L ," do that already? If it were > to introduce

Re: difftool -d symlinks, under what conditions

Matt McClure writes: > An alternative approach would be to reuse git-diff's option parsing > and make it tell git-difftool when git-diff sees the working tree > case. At this point, I haven't seen an obvious place in the source > where git-diff makes that choice, but if someone could point me in

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 5:43 PM, Matt McClure wrote: > On Tue, Mar 12, 2013 at 5:06 PM, John Keeping wrote: >> >> is it sufficient to say >> "there is no more than one non-option to the left of '--' and '--cached' >> is not among the options"? > > An alternative approach would be to reuse git-dif

Re: linux-next: unneeded merge in the security tree

Linus Torvalds writes: > That said, adding the signature from an upstream tag doesn't really > seem to be hugely useful. I'm not seeing much of an upside, in other > words. I'd *expect* that people would pick up upstream tags > regardless, no? Yes, their "git fetch" will auto-follow, but mergeta

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano wrote: > > I agree that "--ff-only" thing is too strict and sometimes you would > want to allow back-merges, but when you do allow such a back-merge, > is there a reason you want it to be --no-signatures merge? When a > subtree maintainer decides to

Re: linux-next: unneeded merge in the security tree

Linus Torvalds writes: > - I do think that we might want a "--no-signatures" for the specific > case of merging signed tags without actually taking the signature > (because it's a "upstream" repo). The "--ff-only" thing is *too* > strict. Sometimes you really do want to merge in new code, disall

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 5:06 PM, John Keeping wrote: > On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote: >> >> What is the situation when you do not want symbolic links? > > When you're not comparing the working tree. > > If we can reliably say "the RHS is the working tree" then it c

Re: linux-next: unneeded merge in the security tree

Theodore Ts'o writes: > What if we added the ability to do something like this: > > [remote "origin"] > url = > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > fetch = +refs/heads/master:refs/heads/master > mergeoptions = --ff-only > > This would be an an

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o wrote: > What if we added the ability to do something like this: > > [remote "origin"] > url = > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > fetch = +refs/heads/master:refs/heads/master > mergeoption

Re: difftool -d symlinks, under what conditions

John Keeping writes: >> Does it even have to be conditional? What is the situation when you >> do not want symbolic links? > > When you're not comparing the working tree. OK, so what you want is essentially: * If you see 0{40} in "diff --raw", you *know* you are showing the working tree fi

Re: linux-next: unneeded merge in the security tree

What if we added the ability to do something like this: [remote "origin"] url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git fetch = +refs/heads/master:refs/heads/master mergeoptions = --ff-only This would be an analog to branch..mergeoptions, but

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote: > John Keeping writes: > > > How about something like "--symlink-all" where the everything in the > > right-hand tree is symlink'd? > > Does it even have to be conditional? What is the situation when you > do not want symbolic link

Re: [PATCH v2 3/6] match_basename: use strncmp instead of strcmp

Duy Nguyen writes: > glibc's C strncmp version does 4-byte comparison at a time when n >=4, > then fall back to 1-byte for the rest. I don't know if it's faster > than a plain always 1-byte comparison though. There's also the hand > written assembly version that compares n from 1..16, not exactly

Re: difftool -d symlinks, under what conditions

John Keeping writes: > How about something like "--symlink-all" where the everything in the > right-hand tree is symlink'd? Does it even have to be conditional? What is the situation when you do not want symbolic links? -- To unsubscribe from this list: send the line "unsubscribe git" in the bo

Re: difftool -d symlinks, under what conditions

David Aguilar writes: > Interesting approach. While this does get the intended behavior > for difftool, I'm afraid this would be a grave regression for > existing "git diff --raw" users who cannot have such behavior. The 0{40} in RHS of --raw output is to say that we do not know what object nam

Re: linux-next: unneeded merge in the security tree

Junio C Hamano writes: > Then under the "--no-ff activates the magic" rule: > > git merge v3.9-rc2 > > will fast-forward, but this > > git merge --no-ff v3.9-rc2 > > creates a real merge with the "mergetag" signature block. The one > that caused trouble in the "security tree", i.e. >

Re: linux-next: unneeded merge in the security tree

Linus Torvalds writes: > One is simple: > > git config alias.sync="pull --ff-only" Heh, I just wrote that myself after reading the early part of this message ;-) > which works fine, but forces submaintainers to be careful when doing > things like this, and using a special command to do back

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 12:23:52PM -0700, David Aguilar wrote: > I don't think we could do this without adding an additional flag > to trigger this change in behavior (e.g. --null-sha1-for-?) > so that existing users are unaffected by the change. > > It feels like forcing the null SHA-1 is hea

Re: [PATCH v2 4/4] teach config parsing to read from strbuf

On Tue, Mar 12, 2013 at 05:42:54PM +0100, Heiko Voigt wrote: > > Your series does not actually add any callers of the new function. The > > obvious "patch 5/4" would be to plumb it into "git config --blob", and > > then we can just directly test it there (there could be other callers > > besides r

Re: [PATCH v2 3/4] config: make parsing stack struct independent from actual data source

On Tue, Mar 12, 2013 at 05:27:35PM +0100, Heiko Voigt wrote: > > Would a union be more appropriate here? We do not ever have to pass it > > directly as a parameter, since we pass the "struct config_source" to the > > method functions. > > > > It's still possible to screw up using a union, but it'

Re: [PATCH v2 2/4] config: drop file pointer validity check in get_next_char()

On Tue, Mar 12, 2013 at 05:16:20PM +0100, Heiko Voigt wrote: > > Ok if you say so I will do that :-). I was thinking about adding a patch > > that would remove cf as a global variable and explicitely pass it down > > to get_next_char. That makes it more obvious that it actually is != NULL. > > Loo

Re: [PATCH] difftool: Make directory diff symlink work tree

> difftool -d formerly knew how to symlink to the work tree when the work > tree contains uncommitted changes. In practice, prior to this change, it > would not symlink to the work tree in case there were no uncommitted > changes, even when the user invoked difftool with the form: > > git diff

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 12:09 PM, John Keeping wrote: > On Tue, Mar 12, 2013 at 02:12:29PM -0400, Matt McClure wrote: >> On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure >> wrote: >> Your thoughts on the change? > > Please include the patch in your message so that interested parties can > comment o

Re: [PATCH v2 2/4] config: drop file pointer validity check in get_next_char()

On Tue, Mar 12, 2013 at 05:00:56PM +0100, Heiko Voigt wrote: > > That is, every path to get_next_char happens while we are in > > git_config_from_file, and that function guarantees that cf = &top, and > > that top.f != NULL. We do not have to even do any analysis of the > > conditions for each ca

Re: difftool -d symlinks, under what conditions

On Tue, Mar 12, 2013 at 02:12:29PM -0400, Matt McClure wrote: > On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure > wrote: > Your thoughts on the change? Please include the patch in your message so that interested parties can comment on it here, especially since the compare view on GitHub seems to m

Re: [PATCH v2 1/4] config: factor out config file stack management

On Tue, Mar 12, 2013 at 04:44:35PM +0100, Heiko Voigt wrote: > > Can we throw in a comment at the top here with the expected usage? In > > particular, do_config_from is expecting the caller to have filled in > > certain fields (at this point, top->f and top->name), but there is > > nothing to make

Re: difftool -d symlinks, under what conditions

On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure wrote: > > On Tuesday, November 27, 2012, David Aguilar wrote: >> >> It seems that there is an edge case here that we are not >> accounting for: unmodified worktree paths, when checked out >> into the temporary directory, can be edited by the tool when

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds wrote: >> Why not just force the head of the security tree to be v3.9-rc2? Then >> you don't end up creating a completely unnecessary merge commit, and >> users who were at the previous head of the security tree will >> experience a fast forward whe

Re: [PATCH v3 04/13] match_basename: use strncmp instead of strcmp

> --- a/dir.c > +++ b/dir.c > @@ -636,12 +636,14 @@ int match_basename(const char *basename, int > basenamelen, >int flags) > { > if (prefix == patternlen) { > - if (!strcmp_icase(pattern, basename)) > + if (patternlen == basenamelen && > +

Re: linux-next: unneeded merge in the security tree

[ Added Junio and git to the recipients, and leaving a lot of stuff quoted due to that... ] On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o wrote: > On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote: >> On Tue, 12 Mar 2013, Stephen Rothwell wrote: >> > The top commit in the security tre

Re: [PATCH v2 4/4] teach config parsing to read from strbuf

On Tue, Mar 12, 2013 at 07:18:06AM -0400, Jeff King wrote: > On Sun, Mar 10, 2013 at 06:00:52PM +0100, Heiko Voigt wrote: > > > This can be used to read configuration values directly from gits > > database. > > > > Signed-off-by: Heiko Voigt > > This is lacking motivation. IIRC, the rest of the

Re: [PATCH v2 3/4] config: make parsing stack struct independent from actual data source

On Tue, Mar 12, 2013 at 07:03:55AM -0400, Jeff King wrote: > On Sun, Mar 10, 2013 at 05:59:40PM +0100, Heiko Voigt wrote: > > > diff --git a/config.c b/config.c > > index f55c43d..fe1c0e5 100644 > > --- a/config.c > > +++ b/config.c > > @@ -10,20 +10,42 @@ > > #include "strbuf.h" > > #include "q

Re: [PATCH v4] submodule: add 'deinit' command

Phil Hord writes: > I think this would be clearer if 'git deinit' said > > rm 'submodule/*' > > or maybe > > Removed workdir for 'submodule' > > Is it just me? The latter may probably be better. After cloning the superproject, you show interest in individual submodules by saying "git

Re: [PATCH v2 2/4] config: drop file pointer validity check in get_next_char()

On Tue, Mar 12, 2013 at 05:00:56PM +0100, Heiko Voigt wrote: > On Tue, Mar 12, 2013 at 07:00:03AM -0400, Jeff King wrote: > > On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote: > > > > > The only location where cf is set in this file is in do_config_from(). > > > This function has only o

Re: Updating not actual branch

Jan Pešta writes: > I have following situation: > > A - B - C - I - J master >\ - D - E - F feature 1 > \ G - H feature 2 (working copy) > > I would like tu update whole tree with latest changes in master > >

Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

On Sat, Mar 9, 2013 at 1:18 PM, Jens Lehmann wrote: > Am 05.03.2013 22:17, schrieb Phil Hord: >> On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann wrote: >>> Am 05.03.2013 19:34, schrieb Junio C Hamano: Eric Cousineau writes: > ... I am not entirely convinced we would want --include-sup

Re: [PATCH v2 2/4] config: drop file pointer validity check in get_next_char()

On Tue, Mar 12, 2013 at 07:00:03AM -0400, Jeff King wrote: > On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote: > > > The only location where cf is set in this file is in do_config_from(). > > This function has only one callsite which is config_from_file(). In > > config_from_file() its

Re: [PATCH v2 1/4] config: factor out config file stack management

On Tue, Mar 12, 2013 at 06:52:00AM -0400, Jeff King wrote: > On Sun, Mar 10, 2013 at 05:57:53PM +0100, Heiko Voigt wrote: > > > Because a config callback may start parsing a new file, the > > global context regarding the current config file is stored > > as a stack. Currently we only need to manag

Re: [PATCH v4] submodule: add 'deinit' command

On Wed, Feb 6, 2013 at 4:11 PM, Jens Lehmann wrote: > With "git submodule init" the user is able to tell git he cares about one > or more submodules and wants to have it populated on the next call to "git > submodule update". But currently there is no easy way he could tell git he > does not care

Re: [PATCH 14/19] Document pull-all and push-all

Am 09.03.2013 20:28, schrieb Paul Campbell: From 7dcd40ab8687a588b7b0c6ff914a7cfb601b6774 Mon Sep 17 00:00:00 2001 From: Herman van Rink Date: Tue, 27 Mar 2012 13:59:16 +0200 Subject: [PATCH 14/19] Document pull-all and push-all --- contrib/subtree/git-subtree.txt | 8 +++- 1 file chang

Re: Updating not actual branch

On Tue, 12 Mar 2013 14:22:00 +0100 Jan Pešta wrote: > I have a question if there is a posibility tu update a branch which > is not actual working copy. > > I have following situation: > > A - B - C - I - J master >\ - D - E - F feature 1 >

Re: [PATCH 1/2] require pathspec for "git add -u/-A"

Jeff King writes: > PS I wonder how others are finding the warning? I'm finding it slightly >annoying. Perhaps I just haven't retrained my fingers yet. But one >problem with that retraining is that I type "git add -u" from the >root _most_ of the time, and it just works. But occasiona

Updating not actual branch

Hi All, I have a question if there is a posibility tu update a branch which is not actual working copy. I have following situation: A - B - C - I - J master \ - D - E - F feature 1 \ G - H feature 2 (working

[PATCH v3 13/13] read_directory: calculate name hashes incrementally

Instead of index_name_exists() calculating a hash for full pathname for every entry, we calculate partial hash per directory, use it as a seed. The number of characters that icase_hash has to chew will reduce. treat_leading_path: 0.000 0.000 read_directory: 1.296 1.235 +treat_one_path:

[PATCH v3 12/13] name-hash: allow to lookup a name with precalculated base hash

index_name_exists_base() differs from index_name_exists() in how the hash is calculated. It uses the base hash as the seed and skips the baselen part. The intention is to reduce hashing cost during directory traversal, where the hash of the directory is calculated once, and used as base hash for a

[PATCH v3 11/13] Preallocate hash tables when the number of inserts are known in advance

This avoids unnecessary allocations and reinsertions. On webkit.git (i.e. about 100k inserts to the name hash table), this reduces about 100ms out of 3s user time. treat_leading_path: 0.000 0.000 read_directory: 1.299 1.305 +treat_one_path: 0.599 0.599 ++is_excluded:0.103

[PATCH v3 10/13] read_directory: avoid invoking exclude machinery on tracked files

read_directory() (and its friendly wrapper fill_directory) collects untracked/ignored files by traversing through the whole worktree, feeding every entry to treat_one_path(), where each entry is checked against .gitignore patterns. One may see that tracked files can't be excluded and we do not nee

[PATCH v3 09/13] exclude: filter out patterns not applicable to the current directory

.gitignore files are spread over directories (*) so that when we check for ignored files at foo, we are not bothered by foo/bar/.gitignore, which contains ignore rules for foo/bar only. This is not enough. foo/.gitignore can contain the pattern "foo/bar/*.c". When we stay at foo, we know that the

[PATCH v3 08/13] exclude: record baselen in the pattern

Signed-off-by: Nguyễn Thái Ngọc Duy --- attr.c | 4 +++- dir.c | 19 ++- dir.h | 6 +- 3 files changed, 22 insertions(+), 7 deletions(-) diff --git a/attr.c b/attr.c index 1818ba5..b89da33 100644 --- a/attr.c +++ b/attr.c @@ -249,12 +249,14 @@ static struct match_attr *p

[PATCH v3 07/13] exclude: avoid calling prep_exclude on entries of the same directory

prep_exclude is only necessary when we enter or leave a directory. Now it's called for every entry in a directory. With this patch, the number of prep_exclude calls in webkit.git goes from 188k down to 11k. This patch does not make exclude any faster, but it prepares for making prep_exclude heavier

[PATCH v3 06/13] dir: pass pathname length to last_exclude_matching

Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/dir.c b/dir.c index 26c3b3a..58739f3 100644 --- a/dir.c +++ b/dir.c @@ -794,9 +794,9 @@ int is_excluded_from_list(const char *pathname, */ static struct exclude *l

[PATCH v3 05/13] match_{base,path}name: replace strncmp_icase with memequal_icase

treat_leading_path: 0.000 0.000 read_directory: 3.578 3.501 +treat_one_path: 2.323 2.257 ++is_excluded:2.117 2.056 +++prep_exclude: 0.224 0.216 +++matching: 1.544 1.493 ++dir_exist: 0.035 0.035 ++index_name_exists: 0.290 0.292 lazy_init_name_hash

[PATCH v3 04/13] match_basename: use strncmp instead of strcmp

strncmp provides length information, compared to strcmp, which could be taken advantage by the implementation. Even better, we could check if the lengths are equal before calling strncmp, eliminating a bit of strncmp calls. treat_leading_path: 0.000 0.000 read_directory: 3.558 3.578 +tre

[PATCH v3 03/13] dir.c: inline convenient *_icase helpers

Like the previous patch, this cuts down the number of str*cmp calls in read_directory (which does _a lot_). Again sorted results on webkit.git: treat_leading_path: 0.000 0.000 read_directory: 3.674 3.558 +treat_one_path: 2.427 2.305 ++is_excluded:2.221 2.098 +++prep_exclud

[PATCH v3 00/13] Exclude optimizations

Result of today. I cherry-picked nd/read-directory-recursive-optim to see how far I can get after pulling all the tricks. This is a slower machine so time is longer. Anyway, read_directory time is reduced about 70% in the end. function before after -- t

[PATCH v3 02/13] match_pathname: avoid calling strncmp if baselen is 0

This reduces "git status" user time by a little bit. This is the sorted results of 10 consecutive runs of "git ls-files --exclude-standard -o" on webkit.git, compiled with gcc -O2: treat_leading_path: 0.000 0.000 read_directory: 4.102 3.674 +treat_one_path: 2.843 2.427 ++is_exclude

[PATCH v3 01/13] dir.c: add MEASURE_EXCLUDE code for tracking exclude performance

Hot read_directory() codepaths are tracked. This could be helpful to see how changes affect read_directory() performance. Results are printed when environment variable GIT_MEASURE_EXCLUDE is set. Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 109 +++

Re: [PATCH 1/2] require pathspec for "git add -u/-A"

On Sun, Mar 10, 2013 at 04:49:09PM +0100, Matthieu Moy wrote: > Junio C Hamano writes: > > > As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without > > pathspec, 2013-01-28), "git add -u/-A" that is run without pathspec > > in a subdirectory will stop working sometime before Git 2.

Re: [PATCH v2 4/4] teach config parsing to read from strbuf

On Sun, Mar 10, 2013 at 06:00:52PM +0100, Heiko Voigt wrote: > This can be used to read configuration values directly from gits > database. > > Signed-off-by: Heiko Voigt This is lacking motivation. IIRC, the rest of the story is something like "...so we can read .gitmodules directly from the r

Re: [PATCH v2 3/4] config: make parsing stack struct independent from actual data source

On Sun, Mar 10, 2013 at 05:59:40PM +0100, Heiko Voigt wrote: > diff --git a/config.c b/config.c > index f55c43d..fe1c0e5 100644 > --- a/config.c > +++ b/config.c > @@ -10,20 +10,42 @@ > #include "strbuf.h" > #include "quote.h" > > -typedef struct config_file { > - struct config_file *prev;

Re: [PATCH v2 2/4] config: drop file pointer validity check in get_next_char()

On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote: > The only location where cf is set in this file is in do_config_from(). > This function has only one callsite which is config_from_file(). In > config_from_file() its ensured that the f member is set to non-zero. > [...] > - if (cf

Re: [PATCH v2 1/4] config: factor out config file stack management

On Sun, Mar 10, 2013 at 05:57:53PM +0100, Heiko Voigt wrote: > Because a config callback may start parsing a new file, the > global context regarding the current config file is stored > as a stack. Currently we only need to manage that stack from > git_config_from_file. Let's factor it out to allo

Re: [PATCH v3 0/2] shell: allow 'no-interactive-login' command to disable interactive shell

On Sat, Mar 09, 2013 at 01:52:37PM -0800, Jonathan Nieder wrote: > Here's a reroll along the lines described at > http://thread.gmane.org/gmane.comp.version-control.git/216229 > > As before, this series is meant to give users of basic 'git shell' > setups a chance to imitate some nice behaviors t

Re: Questions/investigations on git-subtree and tags

Paul, I'm not quite sure where I should go from here... should I send you a patch so you make it a V3 of your patch ? should I send a patch superseeding yours ? I have also found a similar problem in git-subtree pull, which needs the same fix. in the mean time, attached is the current version

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

On Tue, Mar 12, 2013 at 03:13:39PM +0530, Ramkumar Ramachandra wrote: > Heiko Voigt wrote: > > While talking about platform independence. How about Windows? AFAIK > > there are no file based sockets. How about using shared memory, thats > > available, instead? It would greatly reduce the needed po

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

On Tue, Mar 12, 2013 at 10:43 AM, Ramkumar Ramachandra wrote: > Heiko Voigt wrote: >> While talking about platform independence. How about Windows? AFAIK >> there are no file based sockets. How about using shared memory, thats >> available, instead? It would greatly reduce the needed porting effor

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

Heiko Voigt wrote: > While talking about platform independence. How about Windows? AFAIK > there are no file based sockets. How about using shared memory, thats > available, instead? It would greatly reduce the needed porting effort. What about the git credential helper: it uses UNIX sockets, no?

Re: Proposal: sharing .git/config

On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote: > > But it was pointed out that you could also just do: > > > > $ git config include.ref upstream-config > > $ git show origin/config ;# make sure it looks reasonable > > $ git show origin/config >.git/upstream-config > >

Re: rebase: strange failures to apply patc 3-way

On Mon, Mar 11, 2013 at 09:10:04PM -0400, Jeff King wrote: > On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote: > > > On 03/11/13 21:01, Jeff King wrote: > > > From "git help config": > > > > > > core.trustctime > > > If false, the ctime differences between the index and the workin

Re: ZSH segmentation fault while completing "git mv dir/"

Jeff Epler writes: > If it's dependent on eval "`dircolors`", it suggests it might be > dependent on the size of the environment. Maybe try with FOO=`perl -e > 'print "x"x1000'` for various values of 1000... It's not this, but I could reduce the problem to a slightly simpler .zshrc: --