Re: [wish] Revert changes in git gui

Christoph Grüninger wrote: > While browsing the changes, it is very easy to add (or remove) lines or > hunks for commit via the context menu. I would like to revert the > changes of a line or a hunk in a similar way. I have often white-space > or formatting changes I don't want to commit but wan

Re: [wish] Revert changes in git gui

On Tue, Dec 9, 2014 at 9:21 PM, Johannes Sixt wrote: > Am 09.12.2014 um 20:49 schrieb Christoph Grüninger: >> While browsing the changes, it is very easy to add (or remove) lines or >> hunks for commit via the context menu. I would like to revert the >> changes of a line or a hunk in a similar way

[PATCH v3] pkt-line: allow writing of LARGE_PACKET_MAX buffers

On Tue, Dec 09, 2014 at 02:41:51PM -0800, Junio C Hamano wrote: > >> Another option would be to use a static strbuf. Then we're only wasting > >> heap, and even then only as much as we need (we'd still manually cap it > >> at LARGE_PACKET_MAX since that's what the protocol dictates). This would >

Re: Blobs not referenced by file (anymore) are not removed by GC

On Tue, Dec 09, 2014 at 10:15:31PM +, Roberto Tyley wrote: > > Not that I expect you to want to work on filter-branch. :) But maybe > > food for thought for a BFG feature. > > I haven't heard much demand for a recover/restore feature on the BFG > (I think by the time people get to the BFG, th

Re: Poor push performance with large number of refs

On Tue, Dec 9, 2014 at 4:37 PM, brian m. carlson wrote: > I have a repository that's just under 2 GiB in size and contains over > 2 refs, with a copy of it on a server. Both sides are using Git > 2.1.2. If I push a branch that contains a single commit, it takes about > 15 seconds to push. H

Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes

On 12/09/2014 11:53 PM, Duy Nguyen wrote: On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson wrote: On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote: If the user enables untracked cache, then - move worktree to an unsupported filesystem - or simply upgrade OS - or move

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

On Tue, Dec 9, 2014 at 2:41 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote: >> >>> Another option would be to use a static strbuf. Then we're only wasting >>> heap, and even then only as much as we need (we'd still manually cap it >>>

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

On Ter, 2014-12-09 at 16:44 -0800, Junio C Hamano wrote: > Sérgio Basto writes: > > > Also don't understand why --assumed-untracked shouldn't deal with > > changed files instead fallback in "the user promises not to change the > > file" and sometimes works others not. > > > > Also if this is th

Re: [PATCH] gitignore.txt: do not suggest assume-unchanged

Michael J Gruber wrote: > git-update-index --assume-unchanged was never meant to ignore changes > to tracked files (only to spare some stats). So do not suggest it > as a means to achieve that. [...] > +++ b/Documentation/gitignore.txt > @@ -138,9 +138,6 @@ NOTES > The purpose of gitignore files

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

Sérgio Basto writes: > Also don't understand why --assumed-untracked shouldn't deal with > changed files instead fallback in "the user promises not to change the > file" and sometimes works others not. > > Also if this is the contract when a file is different from commit, > should warning the us

Poor push performance with large number of refs

I have a repository that's just under 2 GiB in size and contains over 2 refs, with a copy of it on a server. Both sides are using Git 2.1.2. If I push a branch that contains a single commit, it takes about 15 seconds to push. However, if everything is up-to-date, it completes within 2 second

Re: [PATCH v3 10/23] untracked cache: save to an index extension

On Mon, Dec 8, 2014 at 9:04 PM, Nguyễn Thái Ngọc Duy wrote: > +void write_untracked_extension(struct strbuf *out, struct untracked_cache > *untracked) > +{ > + struct ondisk_untracked_cache *ouc; > + struct write_data wd; > + unsigned char varbuf[16]; > + int len = 0, vari

Re: [PATCH/RFC 4/4] attr: avoid heavy work when we know the specified attr is not defined

Nguyễn Thái Ngọc Duy writes: > +static void collect_selected_attrs(const char *path, int num, > +struct git_attr_check *check) > +{ > + struct attr_stack *stk; > + int i, pathlen, rem, dirlen; > + int basename_offset; > + > + pathlen = split_path(p

Re: [PATCH/RFC 3/4] attr: do not attempt to expand when we know it's not a macro

Nguyễn Thái Ngọc Duy writes: > Keep track of all recognized macros in the new "maybe_macro" field. > This this field is true, it _may_ be a macro (depending on what's in > the current attr stack). But if the field is false, it's definitely > not a macro, no need to go through the whole attr stac

Re: [PATCH 1/4] attr.c: rename global var attr_nr to git_attr_nr

Nguyễn Thái Ngọc Duy writes: > This name "attr_nr" is used elsewhere as local variable, shadowing the > global one. Let's rename the global one into something else to avoid > accidents due to shadow in future. Even though I do not think I would reject a patch to add this entire file if the vari

Re: [PATCH v3 10/23] untracked cache: save to an index extension

On Mon, Dec 8, 2014 at 9:04 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/Documentation/technical/index-format.txt > b/Documentation/technical/index-format.txt > index fe6f316..b97ac8d 100644 > --- a/Documentation/technical/index-format.txt > +++ b/Do

Re: [PATCH/RFC 3/4] attr: do not attempt to expand when we know it's not a macro

On Tue, Dec 9, 2014 at 8:53 AM, Nguyễn Thái Ngọc Duy wrote: > Keep track of all recognized macros in the new "maybe_macro" field. > This this field is true, it _may_ be a macro (depending on what's in s/This this/If this/ > the current attr stack). But if the field is false, it's definitely > no

Re: [PATCH] document string_list_clear

Jonathan Nieder writes: > Jeff King wrote: > >> Elsewhere I mentioned a tool to extract comments and format them. But do >> people actually care about the formatting step? > > If formatting means "convert to a straightforward text document that I > can read through", then I do. If the result bec

Re: [PATCH] document string_list_clear

Stefan Beller wrote: > On Tue, Dec 09, 2014 at 02:49:50PM -0800, Jonathan Nieder wrote: >> And another: > > this goes on top or replaces the previous one? (This applies cleanly on > origin/master) They're independent. :) [...] >> Reported-by: Stefan Beller >> Signed-off-by: Jonathan Nieder >

Re: [PATCH] document string_list_clear

On Tue, Dec 09, 2014 at 02:49:50PM -0800, Jonathan Nieder wrote: > Jonathan Nieder wrote: > > Stefan Beller wrote: > >> On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano wrote: > > >>> Perhaps the API doc that currently says "Free" is the only thing > >>> that needs fixing? And perhaps add "See $d

Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes

On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson wrote: > On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote: >> If the user enables untracked cache, then >> >> - move worktree to an unsupported filesystem >> - or simply upgrade OS >> - or move the whole (portable) disk from o

Re: [PATCH] document string_list_clear

Jonathan Nieder wrote: > Stefan Beller wrote: >> On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano wrote: >>> Perhaps the API doc that currently says "Free" is the only thing >>> that needs fixing? And perhaps add "See $doc" at the beginning of >>> the header and remove duplicated comments we alre

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

Jeff King writes: > On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote: > >> Another option would be to use a static strbuf. Then we're only wasting >> heap, and even then only as much as we need (we'd still manually cap it >> at LARGE_PACKET_MAX since that's what the protocol dictates). T

Re: [PATCH] document string_list_clear

Jeff King wrote: > Elsewhere I mentioned a tool to extract comments and format them. But do > people actually care about the formatting step? If formatting means "convert to a straightforward text document that I can read through", then I do. > Doe

Re: Blobs not referenced by file (anymore) are not removed by GC

On Tuesday, 9 December 2014, Jeff King wrote: > I actually think filter-branch's "refs/original" is a bit outdated at > this point. The information is there in the reflogs already, and > dealing with refs/original often causes confusion in my experience. It > could probably use a "git filter-branc

Re: [PATCH 4/7] parse_color: refactor color storage

On Tue, Dec 09, 2014 at 09:52:10PM +0100, Johannes Sixt wrote: > This patch would actually be my personal preference. The comment near > the literal makes it all clear. Thanks. Here it is ready to be applied. Junio, this goes on top of the jk/colors topic. -- >8 -- Subject: [PATCH] parse_color:

Re: [PATCH 4/7] parse_color: refactor color storage

On Tue, Dec 9, 2014 at 3:14 PM, Johannes Sixt wrote: > Am 20.11.2014 um 16:17 schrieb Jeff King: >> +#define COLOR_FOREGROUND '3' >> +#define COLOR_BACKGROUND '4' > > This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows, > because we inherit a definition from a Windows header. Ho

Re: [PATCH 4/7] parse_color: refactor color storage

Am 09.12.2014 um 21:21 schrieb Jeff King: > On Tue, Dec 09, 2014 at 09:14:29PM +0100, Johannes Sixt wrote: > >> Am 20.11.2014 um 16:17 schrieb Jeff King: >>> +#define COLOR_FOREGROUND '3' >>> +#define COLOR_BACKGROUND '4' >> >> This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows

Re: [PATCH] document string_list_clear

On Tue, Dec 09, 2014 at 12:32:15PM -0800, Stefan Beller wrote: > As said above the Documentation/technical would only serve a purpose to > explain very high level concepts. So racy-git.txt or > pack-heuristics.txt will fit > in there very good. Yeah, I think we would leave anything that isn't api

Re: diff: use built-in patterns by default via git attributes

On Tue, Dec 09, 2014 at 09:18:30PM +0100, Daniel Hahler wrote: > I'm wondering why the built-in patterns (defined in userdiff.c) are not > being applied by default, e.g. what you would normally do in > core.attributesfile via: > > *.py diff=python > > Wouldn't it make sense to provide certai

Re: [PATCH] document string_list_clear

On Tue, Dec 9, 2014 at 12:27 PM, Jeff King wrote: > > In which case can we simply start migrating api-strbuf.txt into > in-header comments, without worrying about a parsing tool? > > -Peff That would be my preference as well. Putting the API documentation into the header files. Optionally if you

Re: [PATCH] document string_list_clear

On Tue, Dec 09, 2014 at 12:17:13PM -0800, Jonathan Nieder wrote: > Stefan Beller wrote: > > On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano wrote: > > >> Perhaps the API doc that currently says "Free" is the only thing > >> that needs fixing? And perhaps add "See $doc" at the beginning of > >>

Re: [PATCH] git-am.txt: --ignore-date flag is not passed to git-apply

Ronald Wampler writes: > --- > Documentation/git-am.txt | 1 - > 1 file changed, 1 deletion(-) Of course ;-) "git apply" does not care about dates as it does not make the commit. Thanks. > > diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt > index 9adce37..d4ef16c 100644 > --

Re: [RFD/PATCH] Documentation: mention category

Michael J Gruber writes: > Rather than changing git-foo.txt, we could do the substitution magic > from Documentation/Makefile, of course, to keep man pages and command-list > in sync. Although this would keep me from submitting the final series > with 1 patch per file :) I do not get that smiley

diff: use built-in patterns by default via git attributes

Hi, I'm wondering why the built-in patterns (defined in userdiff.c) are not being applied by default, e.g. what you would normally do in core.attributesfile via: *.py diff=python Wouldn't it make sense to provide certain defaults for attributes, where Git provides enhanced patterns? Regard

Re: [PATCH] document string_list_clear

Jeff King wrote: > On Tue, Dec 09, 2014 at 11:41:44AM -0800, Junio C Hamano wrote: >> Yeah, that is a thought. >> >> Some existing documentation pages like allocation-growing may not be >> a good match for this strategy, though; cache.h has a lot more than >> just alloc-grow, and there needs to be

Re: [PATCH 4/7] parse_color: refactor color storage

On Tue, Dec 09, 2014 at 09:14:29PM +0100, Johannes Sixt wrote: > Am 20.11.2014 um 16:17 schrieb Jeff King: > > +#define COLOR_FOREGROUND '3' > > +#define COLOR_BACKGROUND '4' > > This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows, > because we inherit a definition from a Windo

Re: [wish] Revert changes in git gui

Am 09.12.2014 um 20:49 schrieb Christoph Grüninger: > While browsing the changes, it is very easy to add (or remove) lines or > hunks for commit via the context menu. I would like to revert the > changes of a line or a hunk in a similar way. I have often white-space > or formatting changes I don't

Re: fast-import should not care about core.ignorecase

Joshua Jensen writes: > Jonathan Nieder wrote on 12/8/2014 6:31 PM: >> Joshua Jensen wrote: >>> I think it has been discussed before, but maybe Git needs a >>> core.casefold in addition to core.ignorecase.) >> Would it work for --casefold to be a commandline flag to fast-import, >> instead of a g

Re: [PATCH] document string_list_clear

Stefan Beller wrote: > On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano wrote: >> Perhaps the API doc that currently says "Free" is the only thing >> that needs fixing? And perhaps add "See $doc" at the beginning of >> the header and remove duplicated comments we already have in the >> file? > >

Re: [PATCH] document string_list_clear

On Tue, Dec 09, 2014 at 11:41:44AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Also, I forgot to mention: if we consistently put the API docs into the > > header files and extracted it automatically into standalone documents, > > we would not need to have two places. > > > > This is s

Re: [PATCH 4/7] parse_color: refactor color storage

Am 20.11.2014 um 16:17 schrieb Jeff King: > +#define COLOR_FOREGROUND '3' > +#define COLOR_BACKGROUND '4' This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows, because we inherit a definition from a Windows header. How would you like it fixed? A different name or #undef in front

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

On Tue, Dec 09, 2014 at 08:58:26PM +0100, Johannes Sixt wrote: > Am 09.12.2014 um 18:49 schrieb Jeff King: > > +test_expect_success 'create repo with absurdly long refname' ' > > + ref240=$_z40/$_z40/$_z40/$_z40/$_z40/$_z40 > > + ref1440=$ref240/$ref240/$ref240/$ref240/$ref240/$ref240 && > > +

Re: [PATCH] document string_list_clear

Junio C Hamano wrote: > Jonathan Nieder writes: >>> +/* >>> + * Clears the string list, so it has zero items. All former items are >>> freed. >>> + * If free_util is true, all util pointers are also freed. >>> + */ >>> void string_list_clear(struct string_list *list, int free_util); >> >> The a

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

Am 09.12.2014 um 18:49 schrieb Jeff King: > +test_expect_success 'create repo with absurdly long refname' ' > + ref240=$_z40/$_z40/$_z40/$_z40/$_z40/$_z40 > + ref1440=$ref240/$ref240/$ref240/$ref240/$ref240/$ref240 && > + git init long && > + ( > + cd long && > +

[wish] Revert changes in git gui

Hi Git devs, I have a feature request for git gui: While browsing the changes, it is very easy to add (or remove) lines or hunks for commit via the context menu. I would like to revert the changes of a line or a hunk in a similar way. I have often white-space or formatting changes I don't want

Re: [PATCH] document string_list_clear

On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano wrote: > > Perhaps the API doc that currently says "Free" is the only thing > that needs fixing? And perhaps add "See $doc" at the beginning of > the header and remove duplicated comments we already have in the > file? The reason I wrote this patch

Re: no-xmailer tests fail under Mac OS

Michael Blume writes: > Failures start from > > commit d2384abff7a6181fd7b9a51af7e780aa21e5cb8d (refs/bisect/bad) > Author: Luis Henriques > Date: Thu Dec 4 19:11:30 2014 + > > test/send-email: --[no-]xmailer tests > > Add tests for the --[no-]xmailer option. > > Signed-off-by:

Re: [PATCH] document string_list_clear

Jeff King writes: > Also, I forgot to mention: if we consistently put the API docs into the > header files and extracted it automatically into standalone documents, > we would not need to have two places. > > This is something I've been meaning to look at for a long time, but it > never quite mak

Re: [PATCH] document string_list_clear

Jonathan Nieder writes: >> +/* >> + * Clears the string list, so it has zero items. All former items are freed. >> + * If free_util is true, all util pointers are also freed. >> + */ >> void string_list_clear(struct string_list *list, int free_util); > > The api doc says > > Free a string_

Re: [PATCH] Show number of commits being rebased interactively

Onno Kortmann writes: > Hi, > >> These lines above "---" will become the only log message text, which >> is probably not what you intended. Use "-- >8 --" marker instead >> (that is a perforation line with a pair of scissors on it)? > Thanks, hopefully fixed below. > >>> +commitcount=$(git strip

Re: filter-branch performance

On Tue, Dec 09, 2014 at 07:52:33PM +0100, Henning Moll wrote: > i am runningthis command > > git filter-branch --env-filter 'export > GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" > GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"' > --prune-empty --tag-name-filter cat -- --a

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

On Tue, Dec 09, 2014 at 10:47:24AM -0800, Junio C Hamano wrote: > Michael Haggerty writes: > > > This isn't documented very well. I thought I saw a comment somewhere in > > the code that stated it explicitly, but I can't find it now. In any > > case, my understanding of the locking protocol for

filter-branch performance

Hi, i am runningthis command git filter-branch --env-filter 'export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"' --prune-empty --tag-name-filter cat -- --all in a repository which i copied to /dev/shm before. Accordin

Re: [PATCH/RFC] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)

On Tue, Dec 09, 2014 at 10:43:52AM -0800, Junio C Hamano wrote: > > Unless we can do something clever with a set of global error strbufs or > > something (i.e., that expand as needed, but the caller does not have to > > free themselves, as they will get recycled eventually). That has its own > > c

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

Michael Haggerty writes: > This isn't documented very well. I thought I saw a comment somewhere in > the code that stated it explicitly, but I can't find it now. In any > case, my understanding of the locking protocol for reflogs is: > > The reflog for "$refname", which is stored at > "$G

Re: [PATCH/RFC] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)

Jeff King writes: > On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote: > >> I am more worried about variable length part pushing the information >> that is given later out to the right, e.g. "error: missing file '%s' >> prevents us from doing X". Chomping to [1024] is not a good >>

[PATCH v2] git-am.txt: --ignore-date flag is not passed to git-apply

Signed-off-by: Ronald Wampler --- I forgot to add the sign-off in the previous patch. Sorry for the additional noise. Documentation/git-am.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 9adce37..d4ef16c 100644 --- a/Documentation

Re: [PATCH] introduce git root

Jeff King writes: > But the one place I do not agree is: > >> I think "sequence.editor" and "core.editor" are better because: >> >> - they use the same syntax as the config variables, so they are easier >> to remember and to discover, and > > I really don't like using "core.editor" here, because

Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote: > Another option would be to use a static strbuf. Then we're only wasting > heap, and even then only as much as we need (we'd still manually cap it > at LARGE_PACKET_MAX since that's what the protocol dictates). This would > also make pack

[RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

When we send out pkt-lines with refnames, we use a static 1000-byte buffer. This means that the maximum size of a ref over the git protocol is around 950 bytes (the exact size depends on the protocol line being written, but figure on a sha1 plus some boilerplate). This is enough for any sane workf

[PATCH] git-am.txt: --ignore-date flag is not passed to git-apply

--- Documentation/git-am.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 9adce37..d4ef16c 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -83,7 +83,6 @@ default. You can use `--no-utf8` to override this.

Re: [PATCH] doc: add some crossrefs between manual pages

Junio C Hamano wrote: > So I am OK to special case fast-import and single it out as a > notable implementation technology, which is what your patch does. More importantly, helpers implementing the "import" or "export" capability are indicating that they grok the fast-import format. What they use

[no subject]

You have a cash grant of $2,000.000.00 USD from Mrs Patricia Chandler, contact her on: patriciachandlerca...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordom

Re: Blobs not referenced by file (anymore) are not removed by GC

On Tue, Dec 09, 2014 at 04:01:50PM +, Roberto Tyley wrote: > > I also don't know if BFG keeps backup refs around (filter-branch, for > > example, writes a copy of the original refs into refs/original; you > > would want to delete that if you're trying to slim down the repo). > > The BFG repor

Re: Blobs not referenced by file (anymore) are not removed by GC

On 9 December 2014 at 14:14, Jeff King wrote: > On Mon, Dec 08, 2014 at 05:22:23PM +0100, Martin Scherer wrote: > >> # invoke bfg --delete-folders something multiple times with different >> pattern. >> >> # try to cleanup >> >> git gc --aggressive --prune=now # big blobs still in history >> git fs

Re: Blobs not referenced by file (anymore) are not removed by GC

On Mon, Dec 08, 2014 at 05:22:23PM +0100, Martin Scherer wrote: > # invoke bfg --delete-folders something multiple times with different > pattern. > > # try to cleanup > > git gc --aggressive --prune=now # big blobs still in history > git fsck # no results > git fsck --full --unreachable --dang

[PATCH/RFC 4/4] attr: avoid heavy work when we know the specified attr is not defined

If we have never seen attr 'X' in any .gitattributes file we have examined so far, we can be sure that 'X' is not defined. So no need to go over all the attr stack to look for attr 'X'. This is the purpose behind this new field maybe_real. This optimization breaks down if macros are involved becau

[PATCH 2/4] attr.c: split path processing code out of collect_all_attrs()

Signed-off-by: Nguyễn Thái Ngọc Duy --- attr.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/attr.c b/attr.c index 583d36a..def09c7 100644 --- a/attr.c +++ b/attr.c @@ -705,14 +705,9 @@ static int macroexpand_one(int attr_nr, int rem) return

[PATCH/RFC 3/4] attr: do not attempt to expand when we know it's not a macro

Keep track of all recognized macros in the new "maybe_macro" field. This this field is true, it _may_ be a macro (depending on what's in the current attr stack). But if the field is false, it's definitely not a macro, no need to go through the whole attr stack in macroexpand_one() to search for one

[PATCH 1/4] attr.c: rename global var attr_nr to git_attr_nr

This name "attr_nr" is used elsewhere as local variable, shadowing the global one. Let's rename the global one into something else to avoid accidents due to shadow in future. Signed-off-by: Nguyễn Thái Ngọc Duy --- attr.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff

[PATCH/RFC 0/4] some attr optimizations

I wondered if I could mark some untracked files but 'precious' using git attributes. Then I worried that the majority of people who don't care about this precious thing will have to pay for git_check_attr() just because some people want it. Which led me to try to optimize the attr machinery so tha

my private

My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust you with a business worth $8.3M USD? Please reply ONLY to my private email: mga...@rogers.com for more information -- To unsubscribe from this list: send the line "unsubscribe git" in the

[RFD/PATCH] Documentation: mention category

Quite a few users seem to get confused about which commands to use as the main git interface. While `git --help' gives an overview, users seem to discover commands from the man page which does not tell them to stay away from plumbing commands first. Introduce a category section in each man page wh

[PATCH] gitignore.txt: do not suggest assume-unchanged

git-update-index --assume-unchanged was never meant to ignore changes to tracked files (only to spare some stats). So do not suggest it as a means to achieve that. Signed-off-by: Michael J Gruber --- Documentation/gitignore.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation

Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes

On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote: > If the user enables untracked cache, then > > - move worktree to an unsupported filesystem > - or simply upgrade OS > - or move the whole (portable) disk from one machine to another > - or access a shared fs from another m

Re: [PATCH] Avoid gcc compiler warning

Hi Peff, On Tue, 9 Dec 2014, Jeff King wrote: > On Mon, Dec 08, 2014 at 05:38:59PM +0100, Johannes Schindelin wrote: > > > At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC prints > > a warning that 'hash' may be used uninitialized when compiling > > test-hashmap that 'hash' may

Re: [PATCH] Avoid gcc compiler warning

On Mon, Dec 08, 2014 at 05:38:59PM +0100, Johannes Schindelin wrote: > At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC prints > a warning that 'hash' may be used uninitialized when compiling > test-hashmap that 'hash' may be used uninitialized (but GCC 4.6.3 on this > developer'

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

Sérgio Basto schrieb am 09.12.2014 um 04:43: > On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote: >> Many users misunderstand the --assume-unchanged contract, believing >> it means Git won't look at the flagged file. >> >> Be explicit that the --assume-unchanged contract is by the user that >

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

From: "Philip Oakley" From: "Sérgio Basto" On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote: Many users misunderstand the --assume-unchanged contract, believing it means Git won't look at the flagged file. [...] retrospect, so my patch seeks to clarify the existing situation. That is

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

From: "Sérgio Basto" On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote: Many users misunderstand the --assume-unchanged contract, believing it means Git won't look at the flagged file. Be explicit that the --assume-unchanged contract is by the user that they will NOT change the file so th