Re: grep.patternType

2012-10-04 Thread Michal Kiedrowicz
Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. This addition makes git grep -e

Re: Fixing the p4merge launch shell script

2012-10-04 Thread David Aguilar
On Wed, Oct 3, 2012 at 1:34 AM, Jeremy Morton ad...@game-point.net wrote: Junio C Hamano gitster at pobox.com writes: Jeremy Morton admin at game-point.net writes: I've noticed that the p4merge shell script could do with some improvement when it comes to merging. Because p4merge throws

Re: [PATCH 5/6] log: pass rev_info to git_log_config()

2012-10-04 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Call init_revisions() first to prepare the revision traversal parameters and pass it to git_log_config(), so that necessary bits in the traversal parameters can be tweaked before we call the command line parsing infrastructure setup_revisions() from

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Angelo Borsotti
Hi Philip and all, let me explain in full what is the problem that I tried to solve, and how along the way I stumbled in something that seems to me a git bug (at least a documentation one). There is an RD team developing software using a workflow that is similar to the integerator-manager one

[PATCH 0/6] wildmatch part 2

2012-10-04 Thread Nguyễn Thái Ngọc Duy
On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote: Perhaps the wildmatch code may not be what we want X-. When I imported wildmatch I was hoping to make minimum changes to it. But wildmatch is probably the only practical way to support ** even if we later need to change it

[PATCH 1/6] attr: remove the union in struct match_attr

2012-10-04 Thread Nguyễn Thái Ngọc Duy
We're going to add more attributes to u.pattern so it'll become bigger in size than a pointer. There's no point in sharing the same room with u.attr. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- attr.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-)

[PATCH 4/6] attr: more matching optimizations from .gitignore

2012-10-04 Thread Nguyễn Thái Ngọc Duy
.gitattributes and .gitignore share the same pattern syntax but has separate matching implementation. Over the years, ignore's implementation accumulates more optimizations while attr's stays the same. This patch adds those optimizations to .gitattributes. Basically it tries to avoid

[PATCH 5/6] gitignore: do not do basename match with patterns that have '**'

2012-10-04 Thread Nguyễn Thái Ngọc Duy
** can match slashes, not like *. ab**ef should be able to match ab/cd/ef, or ab/c/d/ef and so on. Turn off the EXC_FLAG_NODIR in this case otherwise the pattern is only checked against the base name. This behavior is in sync with rsync. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com ---

[PATCH 6/6] t3001: note about expected ** behavior

2012-10-04 Thread Nguyễn Thái Ngọc Duy
** currently matches any characters including slashes. It's probably too powerful. A more sensible definition may be match any characters that the but the whole match must be wrapped by slashes. So ** can match none, /, /aaa/, /aa/bb/ and so on but not aa/bb. Note it in the test suite.

[PATCH 0/4] optimizing upload-pack ref peeling

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 01:54:47AM +0200, Ævar Arnfjörð Bjarmason wrote: Hmm. It seems like we should not need to open the tags at all. The main reason is to produce the peeled advertisement just after it. But for a packed ref with a modern version of git that supports the peeled

[PATCH 1/4] peel_ref: use faster deref_tag_noverify

2012-10-04 Thread Jeff King
When we are asked to peel a ref to a sha1, we internally call deref_tag, which will recursively parse each tagged object until we reach a non-tag. This has the benefit that we will verify our ability to load and parse the pointed-to object. However, there is a performance downside: we may not

[PATCH 2/4] peel_ref: do not return a null sha1

2012-10-04 Thread Jeff King
The idea of the peel_ref function is to dereference tag objects recursively until we hit a non-tag, and return the sha1. Conceptually, it should return 0 if it is successful (and fill in the sha1), or -1 if there was nothing to peel. However, the current behavior is much more confusing. For a

[PATCH 3/4] peel_ref: check object type before loading

2012-10-04 Thread Jeff King
The point of peel_ref is to dereference tags; if the base object is not a tag, then we can return early without even loading the object into memory. This patch accomplishes that by checking sha1_object_info for the type. For a packed object, we can get away with just looking in the pack index.

[PATCH 4/4] upload-pack: use peel_ref for ref advertisements

2012-10-04 Thread Jeff King
When upload-pack advertises refs, we attempt to peel tags and advertise the peeled version. We currently hand-roll the tag dereferencing, and use as many optimizations as we can to avoid loading non-tag objects into memory. Not only has peel_ref recently learned these optimizations, too, but it

Re: [PATCH 0/4] optimizing upload-pack ref peeling

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote: [1/4]: peel_ref: use faster deref_tag_noverify [2/4]: peel_ref: do not return a null sha1 [3/4]: peel_ref: check object type before loading [4/4]: upload-pack: use peel_ref for ref advertisements I included my own timings in

Re: [PATCH 3/6] log --grep: use the same helper to set -E/-F options as git grep

2012-10-04 Thread Jeff King
On Wed, Oct 03, 2012 at 06:33:36PM -0700, Junio C Hamano wrote: diff --git a/revision.c b/revision.c index a09e60b..7f5e53b 100644 --- a/revision.c +++ b/revision.c @@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg } else if

Re: [PATCH 4/6] log --grep: accept --basic-regexp and --perl-regexp

2012-10-04 Thread Jeff King
On Wed, Oct 03, 2012 at 06:33:37PM -0700, Junio C Hamano wrote: When we added the --perl-regexp option (or -P) to git grep, we should have done the same for the commands in the git log family, but somehow we forgot to do so. This corrects it. Also introduce the --basic-regexp option for

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

2012-10-04 Thread Jeff King
On Wed, Oct 03, 2012 at 06:33:39PM -0700, Junio C Hamano wrote: Read grep.extendedregexp, grep.patterntype, etc. from the configuration so that log --grep='pcre' honors the user preference without an explicit -P from the command line. Now that the callback parameter, which was so far

Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

2012-10-04 Thread David Michael Barr
On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote: * fa/remote-svn (2012-09-19) 16 commits - Add a test script for remote-svn - remote-svn: add marks-file regeneration - Add a svnrdump-simulator replaying a dump file for testing - remote-svn: add incremental import -

Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2))

2012-10-04 Thread Jonathan Nieder
David Michael Barr wrote: On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote: * fa/remote-svn (2012-09-19) 16 commits - Add a test script for remote-svn - remote-svn: add marks-file regeneration - Add a svnrdump-simulator replaying a dump file for testing - remote-svn: add

Re: [PATCH 0/4] optimizing upload-pack ref peeling

2012-10-04 Thread Ævar Arnfjörð Bjarmason
On Thu, Oct 4, 2012 at 10:04 AM, Jeff King p...@peff.net wrote: On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote: [1/4]: peel_ref: use faster deref_tag_noverify [2/4]: peel_ref: do not return a null sha1 [3/4]: peel_ref: check object type before loading [4/4]: upload-pack:

Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

2012-10-04 Thread Michael Haggerty
On 10/03/2012 08:17 PM, Junio C Hamano wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: There's an interesting case: **foo. According to our rules, that pattern does not contain slashes therefore is basename match. But some might find that confusing because ** can match slashes,...

Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

2012-10-04 Thread Nguyen Thai Ngoc Duy
On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Given that there is no obvious interpretation for what a construct like x**y would mean, and many plausible guesses (most of which sound

Re: [PATCH 0/4] optimizing upload-pack ref peeling

2012-10-04 Thread Nazri Ramliy
On Thu, Oct 4, 2012 at 5:01 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: $ time (echo | ~/g/git/git-upload-pack . | pv /dev/null) Totally off-topic, but ... Thanks for making me look up what pv is. I remember checking it out quiet sometime ago and have forgotten about it

Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2))

2012-10-04 Thread Stephen Bash
- Original Message - From: Jonathan Nieder jrnie...@gmail.com Sent: Thursday, October 4, 2012 4:30:01 AM Subject: Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)) * fa/remote-svn (2012-09-19) 16 commits - Add a test script for remote-svn -

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Phil Hord
On Thu, Oct 4, 2012 at 3:07 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: ... The operation that caused problems was nr. 4. In all the cases enlisted above, a git commit creates a brand new and unique commit because either it has a parent that is different from that of any other commit,

git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Markus Trippelsdorf
Hi, with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user 0.26s system 92% cpu 8.743 total git version 1.7.12 is much quicker: markus@x4 linux % time git pull Already up-to-date. git pull 0.10s user 0.02s

git commit --amen

2012-10-04 Thread ®om
Hi, Is it normal that git commit --amen actually works ? (it does like --amend) version 1.7.10.4 ®om -- 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/majordomo-info.html

Re: Bug report

2012-10-04 Thread Phil Hord
On Thu, Oct 4, 2012 at 12:35 AM, John Whitney j...@emsoftware.com wrote: I just ran into a problem that I'm pretty sure is a bug in git. Just read and run this (fairly trivial) shell script to replicate. When you added * text=auto in the .gitattributes file, you changed what git considers to be

Re: git commit --amen

2012-10-04 Thread Phil Hord
Is it normal that git commit --amen actually works ? (it does like --amend) version 1.7.10.4 Yes. From Documentation/technical/api-parse-options.txt: * Long options may be 'abbreviated', as long as the abbreviation is unambiguous. Apparently since 2008-06-22. So 'git commit

Re: git commit --amen

2012-10-04 Thread Erik Faye-Lund
On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) r...@rom1v.com wrote: Great ! Thank you for your answer ;-) It does not seem to work with git diff: git diff --cache #missing d git diff --cumulativ #missing e This is because git-diff doesn't yet use the parse-options API, but instead

Re: Rebase doesn't restore branch pointer back on out of memory

2012-10-04 Thread Andrew Wong
On 10/03/2012 06:35 PM, Alexander Kostikov wrote: That allows you can go back to the pre-rebase state by rebase --abort. rebase --abort command were not available. I guess rebase file was not created. I meant rebase --abort would be available *if* the error was caught by rebase. But in your

Re: Bug report

2012-10-04 Thread John Whitney
Andrew, Thanks for checking this on your machine. This problem occurs on Mac, Windows, and Linux, and with multiple versions of git. Note that in my script a CR is appended to test.txt. On the Mac, you can generate this in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively, just download and

Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

2012-10-04 Thread Junio C Hamano
David Michael Barr b...@rr-dav.id.au writes: On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote: * fa/remote-svn (2012-09-19) 16 commits ... A GSoC project. Waiting for comments from mentors and stakeholders. I have reviewed this topic and am happy with the design and

Re: Bug report

2012-10-04 Thread John Whitney
Andrew, I forgot to say that all of the config settings are not changed from the default. ---John On 10/4/12 11:16 AM, John Whitney wrote: Andrew, Thanks for checking this on your machine. This problem occurs on Mac, Windows, and Linux, and with multiple versions of git. Note that in my

Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2))

2012-10-04 Thread Junio C Hamano
Stephen Bash b...@genarts.com writes: I seemed to have missed the GSoC wrap up conversation... (links happily accepted). I also seem to have missed such conversation, if anything like that happened. It certainly would have been nice for the mentors and the student for each project to give us

Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

2012-10-04 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: On 10/03/2012 08:17 PM, Junio C Hamano wrote: What is the semantics of ** in the first place? Is it described to a reasonable level of detail in the documentation updates? For example does **foo match afoo, a/b/foo, a/bfoo, a/foo/b, a/bfoo/c?

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as plumbing (since rev-list is not as capable). On the other hand, I'd think most internal uses of log --grep

Re: git commit --amen

2012-10-04 Thread Junio C Hamano
Phil Hord phil.h...@gmail.com writes: Is it normal that git commit --amen actually works ? (it does like --amend) version 1.7.10.4 Yes. From Documentation/technical/api-parse-options.txt: * Long options may be 'abbreviated', as long as the abbreviation is unambiguous.

Re: git commit --amen

2012-10-04 Thread Junio C Hamano
Erik Faye-Lund kusmab...@gmail.com writes: On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) r...@rom1v.com wrote: Great ! Thank you for your answer ;-) It does not seem to work with git diff: git diff --cache #missing d git diff --cumulativ #missing e This is because git-diff

Re: Bug report

2012-10-04 Thread Andrew Wong
On 10/04/2012 12:16 PM, John Whitney wrote: This problem occurs on Mac, Windows, and Linux, and with multiple versions of git. Note that in my script a CR is appended to test.txt. On the Mac, you can generate this in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively, just download and run

Re: git commit --amen

2012-10-04 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Phil Hord phil.h...@gmail.com writes: Is it normal that git commit --amen actually works ? (it does like --amend) version 1.7.10.4 Yes. From Documentation/technical/api-parse-options.txt: * Long options may be 'abbreviated', as long as the

Super long branch names corrupt `.git/config`

2012-10-04 Thread Ben Olive
My `.git/config` can be corrupted if I try to get a local branch with an extremely long name to track a remote branch. Here is a (contrived) example to reproduce the issue: $ cd /tmp $ mkdir buggyrepo otherrepo $ cd buggyrepo/ git init cd - $ cd otherrepo/ git init cd -

Re: [PATCH 0/6] wildmatch part 2

2012-10-04 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote: Perhaps the wildmatch code may not be what we want X-. When I imported wildmatch I was hoping to make minimum changes to it. But wildmatch is probably the only practical way

[PATCH] l10n: de.po: fix a few minor typos

2012-10-04 Thread Ralf Thielow
From: Simon Ruderich si...@ruderich.org Signed-off-by: Simon Ruderich si...@ruderich.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 14 +++--- 1 Datei geändert, 7 Zeilen hinzugefügt(+), 7 Zeilen entfernt(-) diff --git a/po/de.po b/po/de.po index a3cf695..9e9f2da

Re: [PATCH 5/6] gitignore: do not do basename match with patterns that have '**'

2012-10-04 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: - if (!strchr(p, '/')) + if (!strchr(p, '/') !strstr(p, **)) Doesn't wildmatch allow these to be quoted, similar to the way usual glob works, e.g. $ ff $ \?f $ echo ?? ?f ff $ echo

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as plumbing (since rev-list is not as

Re: [PATCH 6/6] t3001: note about expected ** behavior

2012-10-04 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: ** currently matches any characters including slashes. It's probably too powerful. A more sensible definition may be match any characters that the but the whole match must be wrapped by slashes. So ** can match none, /, /aaa/, /aa/bb/ and so on

[PATCH] pretty.c: Fix a compiler warning

2012-10-04 Thread Ramsay Jones
In particular, gcc complains thus: CC pretty.o pretty.c: In function 'format_commit_item': pretty.c:1282: warning: 'offset' might be used uninitialized in \ this function In order to suppress the warning we simply initialize the 'offset' variable in it's declarartion.

Re: [PATCH 1/4] peel_ref: use faster deref_tag_noverify

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: When we are asked to peel a ref to a sha1, we internally call deref_tag, which will recursively parse each tagged object until we reach a non-tag. This has the benefit that we will verify our ability to load and parse the pointed-to object. However, there is

Re: Super long branch names corrupt `.git/config`

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 01:15:25PM -0400, Ben Olive wrote: My `.git/config` can be corrupted if I try to get a local branch with an extremely long name to track a remote branch. Here is a (contrived) example to reproduce the issue: $ cd /tmp $ mkdir buggyrepo otherrepo $

Re: [PATCH 2/4] peel_ref: do not return a null sha1

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: The idea of the peel_ref function is to dereference tag objects recursively until we hit a non-tag, and return the sha1. Conceptually, it should return 0 if it is successful (and fill in the sha1), or -1 if there was nothing to peel. However, the current

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user 0.26s system 92% cpu 8.743 total git version 1.7.12 is much quicker:

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Angelo Borsotti
Hi Phil, \ And why is this a problem? Is there a process or person watching the server for a new commit? Is it not enough to notice that the pushed-to branch has a new HEAD? Yes, the developers use the git gui to see the graph of branches and commits. The simpler and uniform it is, the

Re: [PATCH 3/4] peel_ref: check object type before loading

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: The point of peel_ref is to dereference tags; if the base object is not a tag, then we can return early without even loading the object into memory. This patch accomplishes that by checking sha1_object_info for the type. For a packed object, we can get away

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as

Re: Super long branch names corrupt `.git/config`

2012-10-04 Thread Junio C Hamano
Ben Olive sionid...@gmail.com writes: My `.git/config` can be corrupted if I try to get a local branch with an extremely long name to track a remote branch. Here is a (contrived) example to reproduce the issue: Don't do that, then ;-) I think we have a change that is already cooking. Ben

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user 0.26s system 92% cpu 8.743 total git version

Re: [PATCH 3/4] peel_ref: check object type before loading

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 12:06:16PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: The point of peel_ref is to dereference tags; if the base object is not a tag, then we can return early without even loading the object into memory. This patch accomplishes that by

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user 0.26s system 92% cpu 8.743 total git version

Re: Ignore on commit

2012-10-04 Thread Pascal Obry
I'm not sure to follow everything... But looks like: $ git add -p or $ git add -i should do what you want, no? You select the hunks to commit, let over the hacks and then $ git commit -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination

Re: [PATCH 3/4] peel_ref: check object type before loading

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: [1] One thing I've been toying is with external alternates; dumping your large objects in some realtively slow data store (e.g., a RESTful HTTP service). You could cache and cheaply query a list of sha1 / size / type for each object from the store,

Re: [BUG] gitk: clicking on a connecting line produces can't read cflist_top

2012-10-04 Thread Stefan Haller
Sorry, I didn't realize that there is a display mode where the list of files is empty, not even showing a Comments entry. Here's a patch that fixes it, plus another patch that is only related in so far as the bug that it fixes was introduced by the same commit. [PATCH 1/2] gitk: Fix error

[PATCH 1/2] gitk: Fix error message when clicking on a connecting line

2012-10-04 Thread Stefan Haller
When clicking on the line that connects two commit nodes, gitk would bring up an error dialog saying can't read cflist_top: no such variable. This fixes a regression that was introduced with b967135 (gitk: Synchronize highlighting in file view when scrolling diff). Signed-off-by: Stefan Haller

[PATCH 2/2] gitk: When searching, only highlight files when in Patch mode

2012-10-04 Thread Stefan Haller
This fixes another regression that was introduced in b967135 (gitk: Synchronize highlighting in file view when scrolling diff): when searching for a string in tree mode, jumping to the next search hit would highlight the Comments entry in the file list. Signed-off-by: Stefan Haller

Re: Rebase doesn't restore branch pointer back on out of memory

2012-10-04 Thread Alexander Kostikov
Having the last page of that output should give us enough context as to where it's failing. Full script is uploaded to https://dl.dropbox.com/u/10828740/rebase.log Here is the last page: ---[code] if test -s $dotest/rewritten; then git notes copy

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user 0.26s system 92% cpu 8.743 total git version

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull Already up-to-date. git pull 7.84s user

Re: upload-pack is slow with lots of refs

2012-10-04 Thread Sascha Cunz
Am Mittwoch, 3. Oktober 2012, 16:13:16 schrieb Jeff King: On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote: Out of curiosity, how are you thinking about triggering such a new behavior in a backwards-compatible way? Invoke git-upload-pack2, and fall back to reconnecting to

Re: [PATCH 3/4] peel_ref: check object type before loading

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 01:41:40PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: [1] One thing I've been toying is with external alternates; dumping your large objects in some realtively slow data store (e.g., a RESTful HTTP service). You could cache and cheaply

Re: Ignore on commit

2012-10-04 Thread Marco Craveiro
ignore on commit I'm not sure to follow everything... But looks like: $ git add -p or $ git add -i should do what you want, no? You select the hunks to commit, let over the hacks and then $ git commit Similar but not quite; the idea is that you know that there is some code

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Angelo Borsotti
Hi Philip, This has the developers having a full copy/history of the integrators relevant branches, so that when the pull of the developers branch occurs there is a proper link to the integrators history. True. There are other ways to create a branch which has all the developers feature

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Philip Oakley
From: Angelo Borsotti angelo.borso...@gmail.com Sent: Thursday, October 04, 2012 8:07 AM Hi Philip and all, let me explain in full what is the problem that I tried to solve, and how along the way I stumbled in something that seems to me a git bug (at least a documentation one). There is an RD

Re: git pull takes ~8 seconds on up-to-date Linux git tree

2012-10-04 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: with current trunk I get the following on an up-to-date Linux tree: markus@x4 linux % time git pull

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Philip Oakley
From: Angelo Borsotti angelo.borso...@gmail.com Sent: Thursday, October 04, 2012 11:09 PM A reasonable solution. You can also create a sentinel (--root) commit for any time that you need to create the source branch, just so it (the real source code commit) has a different parent when on source

Re: Rebase doesn't restore branch pointer back on out of memory

2012-10-04 Thread Andrew Wong
On 10/04/2012 05:09 PM, Alexander Kostikov wrote: Full script is uploaded to https://dl.dropbox.com/u/10828740/rebase.log Here is the last page: Judging from that log, I'm pretty sure rebase is failing at format-patch. I was able to reproduce the issue you're having: rebase finished and

Re: Ignore on commit

2012-10-04 Thread Andrew Wong
On 10/04/2012 05:20 PM, Marco Craveiro wrote: Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment) which is normally checked in but for a period of time you want it ignored. So you don't want it git

Re: erratic behavior commit --allow-empty

2012-10-04 Thread Angelo Borsotti
Hi Phil, Another technique could be to simply switch to the sources branch, and then use a 'git clean -x' with an updated .gitignore ('reset' the file from the source branch)[or use the exclude file] to remove those now ignored binaries, before doing the commit. Actually, the first time I

Re: Rebase doesn't restore branch pointer back on out of memory

2012-10-04 Thread Alexander Kostikov
Thanks, Andrew! I'm looking forward for the patch. On Thu, Oct 4, 2012 at 3:52 PM, Andrew Wong andrew.k...@gmail.com wrote: On 10/04/2012 05:09 PM, Alexander Kostikov wrote: Full script is uploaded to https://dl.dropbox.com/u/10828740/rebase.log Here is the last page: Judging from that

Re: upload-pack is slow with lots of refs

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 11:52:13PM +0200, Sascha Cunz wrote: Would it be possible to use this workflow: - Every client connects per default to v1 - If server is capable of v2, it sends a flag along with the usual response (A v1 server will obviously not send that flag) That is more or

Re: Super long branch names corrupt `.git/config`

2012-10-04 Thread Jeff King
On Thu, Oct 04, 2012 at 12:28:39PM -0700, Junio C Hamano wrote: Ben Olive sionid...@gmail.com writes: My `.git/config` can be corrupted if I try to get a local branch with an extremely long name to track a remote branch. Here is a (contrived) example to reproduce the issue: Don't do

Re: git reset respect remote repo (make git idiot proof)

2012-10-04 Thread Geoffrey De Smet
Op 03-10-12 18:52, Andreas Schwab schreef: Geoffrey De Smet ge0ffrey.s...@gmail.com writes: Suppose this case: git clone .../blessedRepo.git // do changes git commit -mbad1 // do changes git commit -mbad2 git reset --hard HEAD^4 // Why does it let me do this? Because there is nothing wrong

Re: git reset respect remote repo (make git idiot proof)

2012-10-04 Thread Geoffrey De Smet
Op 03-10-12 18:40, Phil Hord schreef: But I feel your pain. I think the solution lies in relegating 'reset' to the plumbing or the power-user realm of commands since I feel it is quite overloaded and sometimes dangerous. There was a thread some months back heading in this direction, but I

Re: Ignore on commit

2012-10-04 Thread demerphq
On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote: On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment)

Re: Ignore on commit

2012-10-04 Thread Sitaram Chamarty
On Fri, Oct 5, 2012 at 7:05 AM, demerphq demer...@gmail.com wrote: On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote: On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but not quite; the idea is that you know that there is some code (I'm

Re: Ignore on commit

2012-10-04 Thread Junio C Hamano
Sitaram Chamarty sitar...@gmail.com writes: Git ignore doesn't ignore tracked files. would 'git update-index --assume-unchanged' work in this case? Didn't see it mentioned in any of the replies so far (but I have never used it myself) The assume-unchanged bit is *not* an instruction to

Re: Ignore on commit

2012-10-04 Thread Andrew Ardill
On 5 October 2012 12:20, Sitaram Chamarty sitar...@gmail.com wrote: On Fri, Oct 5, 2012 at 7:05 AM, demerphq demer...@gmail.com wrote: On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote: On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but

Re: git reset respect remote repo (make git idiot proof)

2012-10-04 Thread Junio C Hamano
Geoffrey De Smet ge0ffrey.s...@gmail.com writes: Op 03-10-12 18:40, Phil Hord schreef: But I feel your pain. I think the solution lies in relegating 'reset' to the plumbing or the power-user realm of commands since I feel it is quite overloaded and sometimes dangerous. There was a thread