Re: can we prevent reflog deletion when branch is deleted?

On Sat, Jun 01, 2013 at 05:00:07AM +0200, Michael Haggerty wrote: > This is a known problem. The technical reason that this is not trivial > to solve is the possibility of a directory/file conflict between old > reflog files and references that might be created subsequently (which in > turn is a

Re: can we prevent reflog deletion when branch is deleted?

On 06/01/2013 03:31 AM, Sitaram Chamarty wrote: > Is there a way to prevent reflog deletion when the branch is deleted? > The last entry could simply be a line where the second SHA is all 0's. This is a known problem. The technical reason that this is not trivial to solve is the possibility of a

can we prevent reflog deletion when branch is deleted?

Hi, Is there a way to prevent reflog deletion when the branch is deleted? The last entry could simply be a line where the second SHA is all 0's. -- Sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info a

Re: ls-files -i & directories

On Fri, May 31, 2013 at 04:22:37PM -0400, Roland Schulz wrote: > Hi, > > the gitignore rules work so that if a directory is ignored, all files > in that directory are ignored. While that behavior isn't clearly > documented in gitignore, this behavior is consistent across all git > tools (status, l

ls-files -i & directories

Hi, the gitignore rules work so that if a directory is ignored, all files in that directory are ignored. While that behavior isn't clearly documented in gitignore, this behavior is consistent across all git tools (status, ls-files, ...). An exception is that listing the ignored files using "ls-fi

git daemon --access-hook problem

Hi, I'm trying to test this new feature and having problems getting any results in the following scenario: i have a repo in local folder /home/users/myuser/repos/projectA/.git i start the daemon with the following: git daemon --export-all --base-path=/home/users/myuser/repos --enable=receive-p

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote: > Am 30.05.2013 01:58, schrieb Junio C Hamano: > > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits > > (merged to 'next' on 2013-04-24 at 6306b29) > > + submodule: fix quoting in relative_path() > > (merged to 'next' on 2013-0

Re: Poor performance of git describe in big repos

On Fri, May 31, 2013 at 12:27:11PM +0200, Thomas Rast wrote: > Thomas Rast writes: > > > However, if that turns out to be the culprit, it's not fixable > > currently[1]. Having commits with insanely long messages is just, well, > > insane. > > > > [1] unless we do a major rework of the loading

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

On Fri, May 31, 2013 at 10:08:06AM +0200, Thomas Rast wrote: > > Have you measured the impact of this on normal operations? During a > > traversal, we spend a measurable amount of time looking up commits in > > packfiles, and this would presumably double it. > > I don't think so, but admittedly I

contributing to git-mediawiki

Hello, We are another team from Ensimag (Célestin MATTE & Benoit PERSON) who will contribute to Git and more specifically to Git-Mediawiki for our one-month school project - and possibly more. We already have a couple of basic patches in local and will submit them in the upcoming days. After that,

Re: [PATCH v3 5/7] add tests for rebasing merged history

Am 31.05.2013 08:49, schrieb Martin von Zweigbergk: > +# f > +# / > +# a---b---c---g---h > +# \ > +# d---G---i > +#\ \ > +# e---u > +# > +# uppercase = cherry-picked > +# h = reverted g ... > +test_expect_success "rebase -p --onto in merged history dr

[PATCH v4 0/2] Improve diffcore-pickaxe documentation

Junio had some suggestions in the previous round. The inter-diff follows. Yeah, word-diff is a bit messy. Which brings me to: is it possible to turn on word-diff only where heuristically appropriate? word-diff applied on the rewrite of the first paragraph of gitdiffcore.txt is a disaster, but o

[PATCH 2/2] diffcore-pickaxe doc: document -S and -G properly

The documentation of -S and -G is very sketchy. Completely rewrite the sections in Documentation/diff-options.txt and Documentation/gitdiffcore.txt. References: 52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".) f506b8e (git log/diff: add -G that greps in the patch text) Inpu

[PATCH 1/2] diffcore-pickaxe: make error messages more consistent

Currently, diffcore-pickaxe reports two distinct errors for the same user error: $ git log --pickaxe-regex -S'\1' fatal: invalid pickaxe regex: Invalid back reference $ git log -G'\1' # --pickaxe-regex is implied fatal: invalid log-grep regex: Invalid back reference Since the err

Re: [PATCH 2/2] diffcore-pickaxe doc: document -S and -G properly

Junio C Hamano wrote: > [...] I agree with everything else, and made changes accordingly. > This transformation limits the set of filepairs to those > that change specified strings between the preimage and the > postimage in a certain way. Definitely good. > -S a

Re: Poor performance of git describe in big repos

Thomas Rast writes: > However, if that turns out to be the culprit, it's not fixable > currently[1]. Having commits with insanely long messages is just, well, > insane. > > [1] unless we do a major rework of the loading infrastructure, so that > we can teach it to load only the beginning of a c

Re: Poor performance of git describe in big repos

On 31 May 2013 09:46, Thomas Rast wrote: > Alex Bennée writes: > >> I think you are right. I was brave (well I assumed the tags would come >> back from the upstream repo) and ran: >> >> git for-each-ref | grep "refs/tags" | grep "commit" | cut -d '/' -f 3 >> | xargs git tag -d > > So that deleted

Re: Poor performance of git describe in big repos

On Fri, May 31, 2013 at 09:49:57AM +0100, Alex Bennée wrote: > On 31 May 2013 09:32, John Keeping wrote: > > Thomas is suggesting that you might have a tag that does not point at a > > commit but instead points to a blob object. > > It's looking like I just have some very heavy commits. One data

Re: Poor performance of git describe in big repos

On 31 May 2013 09:32, John Keeping wrote: > On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote: >> On 30 May 2013 20:30, John Keeping wrote: >> > On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: >> >> Alex Bennée writes: >> >> >> >> > On 30 May 2013 16:33, Thomas Rast wrote

Re: Poor performance of git describe in big repos

Alex Bennée writes: > I think you are right. I was brave (well I assumed the tags would come > back from the upstream repo) and ran: > > git for-each-ref | grep "refs/tags" | grep "commit" | cut -d '/' -f 3 > | xargs git tag -d So that deleted all unannotated tags pointing at commits, and then i

Re: Poor performance of git describe in big repos

On 31 May 2013 09:24, Thomas Rast wrote: > Alex Bennée writes: >> On 30 May 2013 20:30, John Keeping wrote: >>> On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: Alex Bennée writes: > On 30 May 2013 16:33, Thomas Rast wrote: > No, my theory is that you tagged *the bl

Re: Poor performance of git describe in big repos

On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote: > On 30 May 2013 20:30, John Keeping wrote: > > On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: > >> Alex Bennée writes: > >> > >> > On 30 May 2013 16:33, Thomas Rast wrote: > >> >> Alex Bennée writes: > > > >> > Will it

Re: [PATCH v7] Add new git-related helper to contrib

Felipe Contreras wrote: > When a reviewer reaches that point, (s)he usually says: other than > cosmetic preferences: Reviewed-by: me. Yes, you can have a Reviewed-by from me if you want. And yes, it is appropriate not to CC me on v8 and v9, since I have no further comments. -- To unsubscribe from

[PATCH] submodule: remove unnecessary check

read_cache() already does that check. Signed-off-by: Felipe Contreras --- submodule.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/submodule.c b/submodule.c index e728025..1821a5b 100644 --- a/submodule.c +++ b/submodule.c @@ -603,9 +603,8 @@ int fetch_populated_submo

Re: Poor performance of git describe in big repos

Alex Bennée writes: > On 30 May 2013 20:30, John Keeping wrote: >> On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: >>> Alex Bennée writes: >>> >>> > On 30 May 2013 16:33, Thomas Rast wrote: >>> >> Alex Bennée writes: >> >>> > Will it be loading the blob for every commit it trave

Re: [PATCH v2 1/3] read-cache: plug a few leaks

On Thu, May 30, 2013 at 10:13 AM, René Scharfe wrote: > Am 30.05.2013 15:34, schrieb Felipe Contreras: >> We don't free 'istate->cache' properly. >> >> Apparently 'initialized' doesn't really mean initialized, but loaded, or >> rather 'not-empty', and the cache can be used even if it's not >> 'ini

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

Ramkumar Ramachandra writes: > Thomas Rast wrote: >> + struct object *obj; >> + int type = sha1_object_info(sha1, NULL); >> + /* If it's neither tag nor commit, parsing the object is wasted >> effort */ >> + if (type != OBJ_TAG && type != OBJ_COMMIT) >> + re

Re: Poor performance of git describe in big repos

On 30 May 2013 20:30, John Keeping wrote: > On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: >> Alex Bennée writes: >> >> > On 30 May 2013 16:33, Thomas Rast wrote: >> >> Alex Bennée writes: > >> > Will it be loading the blob for every commit it traverses or just ones >> > that hi

Re: [PATCH v7] Add new git-related helper to contrib

On Fri, May 31, 2013 at 3:03 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> I was going to make these stylistic changes to make you happy, but >> then I realized the only that does really make sense is to change msg >> = nil to msg = false, and it's not even worth to waste a thought

Re: [PATCH 2/2] lookup_commit_reference_gently: do not read non-{tag,commit}

Jeff King writes: > On Thu, May 30, 2013 at 10:00:23PM +0200, Thomas Rast wrote: > >> lookup_commit_reference_gently unconditionally parses the object given >> to it. This slows down git-describe a lot if you have a repository >> with large tagged blobs in it: parse_object() will read the entire

Re: [PATCH v7] Add new git-related helper to contrib

Felipe Contreras wrote: > I was going to make these stylistic changes to make you happy, but > then I realized the only that does really make sense is to change msg > = nil to msg = false, and it's not even worth to waste a thought on > changes like that. We don't have existing Ruby code in git.gi

Re: [PATCH v7] Add new git-related helper to contrib

On Thu, May 30, 2013 at 6:31 AM, Felipe Contreras wrote: > On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra > Not a single one of these comments makes a difference at all, all of > them can wait until after the patch is merged, many of them are a > matter of preferences, and some of them hav

Re: [PATCH v8 0/6] New git-related helper

On Fri, May 31, 2013 at 2:37 AM, Felipe Contreras wrote: > Since there hasn't been any comments of importance this is basically the same > as v7, plus a few other patches to make it actually usable (for me). > > Unfortunately it turns out Ruby's optparse is not suitable for our needs, so I > impl

[PATCH v9 4/4] contrib: related: parse committish like format-patch

Signed-off-by: Felipe Contreras --- contrib/related/git-related | 15 +++ 1 file changed, 15 insertions(+) diff --git a/contrib/related/git-related b/contrib/related/git-related index 20eb456..bded6f6 100755 --- a/contrib/related/git-related +++ b/contrib/related/git-related @@ -105,

[PATCH v9 1/4] Add new git-related helper to contrib

This script find people that might be interested in a patch, by going back through the history for each single hunk modified, and finding people that reviewed, acknowledge, signed, or authored the code the patch is modifying. It does this by running 'git blame' incrementally on each hunk, and then

[PATCH v9 3/4] contrib: related: add option to parse from committish

For example master..feature-a. Signed-off-by: Felipe Contreras --- contrib/related/git-related | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index 3379982..20eb456 100755 --- a

[PATCH v9 2/4] contrib: related: add support for multiple patches

Signed-off-by: Felipe Contreras --- contrib/related/git-related | 35 +++ 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index 1b9b1e7..3379982 100755 --- a/contrib/related/git-related +++ b

[PATCH v9 0/4] New git-related helper

Hi, I changed my mind, this is the same as v9 but minus some potentially controversial changes. Felipe Contreras (4): Add new git-related helper to contrib contrib: related: add support for multiple patches contrib: related: add option to parse from committish contrib: related: parse comm

[PATCH v8 5/6] contrib: related: parse committish like format-patch

Signed-off-by: Felipe Contreras --- contrib/related/git-related | 15 +++ 1 file changed, 15 insertions(+) diff --git a/contrib/related/git-related b/contrib/related/git-related index 3573237..585572b 100755 --- a/contrib/related/git-related +++ b/contrib/related/git-related @@ -121,

[PATCH v8 0/6] New git-related helper

Hi, Since there hasn't been any comments of importance this is basically the same as v7, plus a few other patches to make it actually usable (for me). Unfortunately it turns out Ruby's optparse is not suitable for our needs, so I implemented a very small parser that is. Felipe Contreras (6): A

[PATCH v8 1/6] Add new git-related helper to contrib

This script find people that might be interested in a patch, by going back through the history for each single hunk modified, and finding people that reviewed, acknowledge, signed, or authored the code the patch is modifying. It does this by running 'git blame' incrementally on each hunk, and then

[PATCH v8 6/6] contrib: related: implement custom option parser

Ruby's option parser is not extensible enough to keep unknown options. Signed-off-by: Felipe Contreras --- contrib/related/git-related | 83 ++--- 1 file changed, 71 insertions(+), 12 deletions(-) diff --git a/contrib/related/git-related b/contrib/related

[PATCH v8 3/6] contrib: related: add support for multiple patches

Signed-off-by: Felipe Contreras --- contrib/related/git-related | 35 +++ 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index bde5b99..0de1c6c 100755 --- a/contrib/related/git-related +++ b

[PATCH v8 4/6] contrib: related: add option to parse from committish

For example master..feature-a. Signed-off-by: Felipe Contreras --- contrib/related/git-related | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index 0de1c6c..3573237 100755 --- a

[PATCH v8 2/6] contrib: related: add option parsing

Signed-off-by: Felipe Contreras --- contrib/related/git-related | 16 1 file changed, 16 insertions(+) diff --git a/contrib/related/git-related b/contrib/related/git-related index 1b9b1e7..bde5b99 100755 --- a/contrib/related/git-related +++ b/contrib/related/git-related @@ -3,9