[PATCH v2] improve git svn performance

From: manjian2006 * perl/Git/SVN.pm Modified according to Eric Wong >Hi, I'm interested in this. How much did performance improve by >(and how many revisions is the repository)> Our svn server are built in a LAN,15152 revisions.Not optimized git-svn used 10 hours or more to accomplish, whi

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

From: "Junio C Hamano" "Philip Oakley" writes: I already have a local patch that creates a stalenote.txt file, and includes that in a "release-notes(7)" man page, but it still leaves the actual release notes in a separate plain text file, linked from the man page, rather than being right at h

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote: > On 13-12-18 11:04 AM, Marc Branchaud wrote: > > Users often find that "next" and "prev" do the opposite of what they > > expect. For example, "next" moves to the next match down the list, but > > that is almost always backwards in t

Re: [PATCH v2] gitk: Comply with XDG base directory specification

On Tue, Jan 21, 2014 at 07:10:16PM +, Astril Hayato wrote: > Write the gitk config data to $XDG_CONFIG_HOME/git/gitk > ($HOME/.config/git/gitk > by default) in line with the XDG specification. This makes it consistent with > git which also follows the spec. > > If $HOME/.gitk already exists u

Anomalous AUTHOR and DOCUMENTATION sections in manpages

I just noticed that there are exactly four Git manpages with an "AUTHOR" section and five with a "DOCUMENTATION" section: $ make doc $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9] Documentation/git-column.1:80:.SH "AUTHOR" Documentation/git-for-each-ref.1:272:.

[PATCH] Add cross-references between docs for for-each-ref and show-ref

Add cross-references between the manpages for git-for-each-ref(1) and git-show-ref(1). Signed-off-by: Michael Haggerty --- There is a lot of overlap between the functionality of these two commands. It might be handy to give the user some hints about when to use one command vs. the other, but hon

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty wrote: > These sections are inconsistent with the other manpages and seem > superfluous in a project that has, on the one hand, a public history > and, on the other hand, hundreds of contributors. Would the mentioned > authors (CCed) consent to th

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

On Wed, Jan 22, 2014 at 12:39 PM, Duy Nguyen wrote: > On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty > wrote: >> These sections are inconsistent with the other manpages and seem >> superfluous in a project that has, on the one hand, a public history >> and, on the other hand, hundreds of cont

Re: [ANNOUNCE] Git v1.9-rc0

Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Cheers Javier Domingo Cansino [1] Google Code download service change announcement: http://google-opensource.blogspot.se/2013/05/a-change-to-google

Conceptual Question for git usage ...

Hi, I want to install git onto my home network - in fact, truth be told, it's already on my server, but I have some questions as to its implementation. First of all, my network. At the 'centre' (practically, if not logically) is my Mac. I consider this my 'central repository' of everything. Mai

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

Hi Michael, On Wed, 22 Jan 2014, Michael Haggerty wrote: > Would the mentioned authors (CCed) consent to the removal of these > sections? Fine by me! Dscho P.S.: Congrats on your new job! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vge

Re: Conceptual Question for git usage ...

On Jan 22, 2014, at 9:20 AM, John McIntyre wrote: > … > > So basically, what I'd like to do is this. I want to write code, > write blg posts, write essays for university, whatever. And I want to > use git to maintain revisions, but where do I store them? Do I make > the Mac my hub? I have a

Re: Conceptual Question for git usage ...

Thank you for that, Andrew. I'm going to follow your advice and just set up a test repository, which won't be a disaster, if it gets damaged or erased. I backup my /Users/john/Documents from my Mac to /home/john/Documents on the Linux server. Except for my mail directory, which comes from $HOME/

Re: Workflow on git with 2 branch with specifc code

On 01/22/2014 12:23 PM, Gordon Freeman wrote: On 01/22/2014 12:16 PM, Gordon Freeman wrote: Oh, sorry if i misunderstand you. My english is not so good. it will be a pleasure if you could explain that. I did some research about topic branchs, and get a lot of useful info of workflows on the wa

Re: [ANNOUNCE] Git v1.9-rc0

Javier Domingo Cansino writes: > Will there be any change on how tarballs are distributed, taking into > account that Google will be shutting down Google Code Downloads > section[1][2]? Aside from the obvious "we won't be able to use something that is no longer offered"? They are not the only d

Re: [ANNOUNCE] Git v1.9-rc0

Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: > Will there be any change on how tarballs are distributed, taking into > account that Google will be shutting down Google Code Downloads > section[1][2]? > Am I missing something or what's wrong with this: https://github.com/gitster/git/arc

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

Michael Haggerty writes: > I just noticed that there are exactly four Git manpages with an "AUTHOR" > section and five with a "DOCUMENTATION" section: > > $ make doc > $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9] > Documentation/git-column.1:80:.SH "AUTHOR" >

Re: [PATCH] Add cross-references between docs for for-each-ref and show-ref

Michael Haggerty writes: > Add cross-references between the manpages for git-for-each-ref(1) and > git-show-ref(1). > > Signed-off-by: Michael Haggerty > --- > There is a lot of overlap between the functionality of these two > commands. Two differences I most often use (i.e. take advantage of)

libz and RHEL 5.9 compile of Git

Hello, I have a RHEL system that I am not the admin of. I needed to install git and got the source. Everything is okay until I got to this point below. I downloaded and installed the latest libz (1.2.8) but i installed it under a local directory under my user name (i.e. /home/ssheikh/local). The p

Re: [ANNOUNCE] Git v1.9-rc0

Stefan Näwe writes: > Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: >> Will there be any change on how tarballs are distributed, taking into >> account that Google will be shutting down Google Code Downloads >> section[1][2]? >> > > Am I missing something or what's wrong with this: > >

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Johannes Sixt writes: > [Cc Pat, who added git.rc] > > Am 1/22/2014 0:48, schrieb Junio C Hamano: >> Ramsay Jones writes: >> Note that I am merely guessing that "short-digit" version numbers are acceptable by now after seeing https://sourceware.org/ml/binutils/2012-07/ms

Re: libz and RHEL 5.9 compile of Git

Hi, salmansheikh wrote: > I > downloaded and installed the latest libz (1.2.8) but i installed it under a > local directory under my user name (i.e. /home/ssheikh/local). The problem > is that git only looks in the locations belo

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Am 1/22/2014 17:12, schrieb Junio C Hamano: > Johannes Sixt writes: > >> [Cc Pat, who added git.rc] >> >> Am 1/22/2014 0:48, schrieb Junio C Hamano: >>> Ramsay Jones writes: >>> > Note that I am merely guessing that "short-digit" version numbers > are acceptable by now after seeing >

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano wrote: > Stefan Näwe writes: > >> Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: >>> Will there be any change on how tarballs are distributed, taking into >>> account that Google will be shutting down Google Code Downloads >>> section[1][2]? >

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Johannes Sixt writes: > The numbers defined in {FILE,PRODUCT}VERSION statements are intended for > machine consumption and are always 4 positions (if the source contains > fewer, they are padded with zeros). They can be used by installers to > decide whether a file that already exists in the syst

Re: [ANNOUNCE] Git v1.9-rc0

Vicent Martí writes: >> Do these consume CPU every time somebody asks for a tarball? That >> might be considered "wrong" depending on the view. > > No, our infrastructure caches frequently requested tarballs so they > don't have to be regenerated on the fly. Thanks. That is certainly good enou

Re: Problem importing from SVN repository with branches/tags at multiple levels using git-svn

On 01/15/2014 02:10 PM, Robert Hancock wrote: > We have an SVN repository that has a structure for tags (likewise for > branches) like this: > > tags/tag1 > tags/tag2 > tags/tag3/ > tags/subdir/tag4 > tags/subdir/tag5 > > The idea is that I want to have git-svn import everything inside subdir > a

Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull

Has this patch been released yet? -- View this message in context: http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-tp7586671p7602383.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

On Wed, Jan 22, 2014 at 3:22 AM, Michael Haggerty wrote: > I just noticed that there are exactly four Git manpages with an "AUTHOR" > section and five with a "DOCUMENTATION" section: > > $ make doc > $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9] > Documentation/gi

[PATCH v2 2/2] repack: accept larger window-memory and max-pack-size

These quantities can be larger than an int. Use ulong to express them like the underlying pack-objects does, and also parse them with the human-friendly unit suffixes. Signed-off-by: Junio C Hamano --- builtin/repack.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --g

[PATCH v2 1/2] parse-options: refactor human-friendly-integer parser out of pack-objects

We only had code to understand unit suffixes such as g/m/k (as in 2g/400m/8k) in the configuration parser but not in the command line option parser. "git pack-objects" worked it around by having a custom extension to the parse-options API; make it available to other callers. The new macro is not

[PATCH v2 0/2] Fix "repack --window-memory=4g" regression in 1.8.4

The command line parser was broken when the command was reimplemented in C in two ways. It incorrectly limited the value range of window-memory and max-pack-size to "int", and also stopped grokking the unit suffixes like 2g/400m/8k. These two patches apply on top of 35c14176 (Reword repack docume

Re: libz and RHEL 5.9 compile of Git

On 2014-01-22 16.59, salmansheikh wrote: > Hello, > > I have a RHEL system that I am not the admin of. I needed to install git and > got the source. Everything is okay until I got to this point below. I > downloaded and installed the latest libz (1.2.8) but i installed it under a > local directory

Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file

Junio C Hamano writes: > Johannes Sixt writes: > ... >> ..., I suggest that we just punt (as per >> my patch). That should work out nicely because we can fairly safely assume >> that there are no installers around that look at these particular version >> numbers. OK. I do not think we care too

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

On Wed, Jan 22, 2014 at 12:22:23PM +0100, Michael Haggerty wrote: > I just noticed that there are exactly four Git manpages with an "AUTHOR" > section and five with a "DOCUMENTATION" section: > > These sections are inconsistent with the other manpages and seem > superfluous in a project that has,

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

Paul Mackerras writes: > On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote: >> On 13-12-18 11:04 AM, Marc Branchaud wrote: >> > Users often find that "next" and "prev" do the opposite of what they >> > expect. For example, "next" moves to the next match down the list, but >> > that

[PATCH] t3030-merge-recursive: Test known breakage with empty work tree

Add test cases that use 'merge-recursive' plumbing with a temporary index and empty work tree. Populate the index using 'read-tree' and 'update-index --ignore-missing --refresh' to prepare for merge without actually checking all files out to disk. Verify that each merge produces its expected tree

Re: [PATCH v2] improve git svn performance

manjian2...@gmail.com wrote: > * perl/Git/SVN.pm > Modified according to Eric Wong > > >Hi, I'm interested in this. How much did performance improve by > >(and how many revisions is the repository)> > Our svn server are built in a LAN,15152 revisions.Not optimized > git-svn used 10 hours or m

Re: problematic git log submodule-dir/

Am 20.01.2014 19:25, schrieb Paweł Sikora: > i've noticed that 'git log submodule-dir' and 'git log submodule-dir/' > return different results (module's head changes vs. nothing). is it a bug? > looks like a trailing slash is a problem for git-log. I think this is a bug, and for example "git diff"

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote: > Vicent Martí writes: > > >> Do these consume CPU every time somebody asks for a tarball? That > >> might be considered "wrong" depending on the view. > > > > No, our infrastructure caches frequently requested tarballs so they > >

Re: [PATCH v2 3/4] Speed up is_git_command() by checking early for internal commands

On 05.01.2014 14:42, Sebastian Schuberth wrote: Since 2dce956 is_git_command() is a bit slow as it does file I/O in the call to list_commands_in_dir(). Avoid the file I/O by adding an early check for internal commands. Considering the purpose of the series is it better to say "builtin" instead

Re: [ANNOUNCE] Git v1.9-rc0

Ken Moffat writes: > I note that all of these *are* still available at googlecode for > the moment : https://code.google.com/p/git-core/downloads/list As I said, Cgc is not the ony download site. The end of http://git-blame.blogspot.com/p/git-public-repositories.html lists the two sites

Re: [PATCH v2 1/4] Consistently use the term "builtin" instead of "internal command"

On 02.01.2014 22:05, Sebastian Schuberth wrote: would just leave me wondering "I never claimed it was built-in; what's going on?" I think it would be simplest to keep it as $ git whatever fatal: cannot handle "whatever" internally which at least makes it clear that this is a

[RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

From: Linus Torvalds Date: Wed, 22 Jan 2014 12:32:30 -0800 Subject: [PATCH] Make 'git request-pull' more strict about matching local/remote branches The current 'request-pull' will try to find matching commit on the given remote, and rewrite the "please pull" line to match that remote ref. Th

RE: Problem importing from SVN repository with branches/tags at multiple levels using git-svn

> -Original Message- > Behalf Of Robert Hancock > Sent: Wednesday, January 22, 2014 11:03 AM > Subject: Re: Problem importing from SVN repository with branches/tags at > multiple levels using git-svn > > On 01/15/2014 02:10 PM, Robert Hancock wrote: > > We have an SVN repository that has a

Re: libz and RHEL 5.9 compile of Git

Got it working but then I had some issues with the perl portions of the install and I subsequently thought I could eliminate those portions and tried setting export NO_PERL=1 and that installed everything else...and got pass this error but when I tried to checkout a git repository as follows, I get

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

On 01/22/2014 12:22 PM, Michael Haggerty wrote: > I just noticed that there are exactly four Git manpages with an "AUTHOR" > section and five with a "DOCUMENTATION" section: > > $ make doc > $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9] > Documentation/git-column.

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

Linus Torvalds writes: > This means that git request-pull will never rewrite the ref-name you gave > it. If the local branch name is "xyzzy", that is the only branch name > that request-pull will ask the other side to fetch. > > If the remote has that branch under a different name, that's your

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano wrote: >> >> The new "find local ref" code will also complain loudly if you give an >> ambiguous refname (eg you have both a tag and a branch with that same >> name, and you don't specify "heads/name" or "tags/name"). > > But this part might be a bit

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds wrote: > > Any ideas? The hacky way is to do "| head -1" to take the first > show-ref output, and then check if you get a different result if you > re-do it using "show-ref --tags". But that sounds really excessively > hacky. Is there a good way to d

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

Linus Torvalds writes: > That may be very helpful if your local tree doesn't match the layout of > the remote branches, but for the common case it's been a recurring > disaster, when "request-pull" is done against a delayed remote update, and > it rewrites the target branch randomly to some ot

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano wrote: > > I looked at 5150.4 and found that what it attempts to do is halfway > sensible. I agree that it is "half-way sensible". The important bit being the HALF part. The half part is why we have the semantics we have. There's no question about

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

Junio C Hamano writes: > ... there is no 'for-linus' branch locally, so there is no way for > him to say > > git request-pull initial origin for-linus > > unless he creates it locally first. In real life on the kernel list, for-linus may have to be a signed tag, and pushed out 1-to-1 nam

Re: [PATCH v2 0/2] Fix "repack --window-memory=4g" regression in 1.8.4

On 22.01.2014 20:58, Junio C Hamano wrote: > The command line parser was broken when the command was > reimplemented in C in two ways. It incorrectly limited the value > range of window-memory and max-pack-size to "int", and also stopped > grokking the unit suffixes like 2g/400m/8k. > > These two

Re: [PATCH 00/11] git p4 tests and a few bug fixes

gits...@pobox.com wrote on Tue, 21 Jan 2014 16:03 -0800: > Pete Wyckoff writes: [..] > > Patch 03 is a regression fix, found and narrowed down thanks to > > much work by Damien Gérard. But it is obscure enough that I'm > > not proposing it for a maintenance release. > > Thanks. > > I am incline

[PATCHv2 01/11] git p4 test: wildcards are supported

Since 9d57c4a (git p4: implement view spec wildcards with "p4 where", 2013-08-30), all the wildcard types should be supported. Change must-fail tests to mark that they now pass. Signed-off-by: Pete Wyckoff --- t/t9809-git-p4-client-view.sh | 16 1 file changed, 8 insertions(+),

[PATCHv2 02/11] git p4 test: ensure p4 symlink parsing works

While this happens to work, there was no test to make sure that the basic importing of a symlink from p4 to git functioned. Add a simple test to create a symlink in p4 and import it into git, then verify that the symlink exists and has the correct target. Signed-off-by: Pete Wyckoff --- t/t9802

[PATCHv2 04/11] git p4 test: explicitly check p4 wildcard delete

There was no test where p4 deleted a file with a wildcard character. Make sure git p4 applies the wildcard decoding properly when importing a delete that includes a wildcard. Signed-off-by: Pete Wyckoff --- t/t9812-git-p4-wildcards.sh | 27 +++ 1 file changed, 27 inserti

[PATCHv2 03/11] git p4: work around p4 bug that causes empty symlinks

Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist. The effect in git p4 is that "p4 print" on the symlink returns an empty string, confusing the curret

[PATCHv2 05/11] git p4 test: is_cli_file_writeable succeeds

Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only, 2013-01-26) fixed a problem with "test -w" on cygwin, but mistakenly marked the new test as failing. Fix this. Signed-off-by: Pete Wyckoff --- t/t9807-git-p4-submit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

[PATCHv2 06/11] git p4 test: run as user "author"

The tests use aut...@example.com as the canonical submitter, but he does not have an entry in the p4 users database. This causes the generated change description to complain that the git and p4 users disagree. The complaint message is still valid, just isn't useful in tests. It was introduced in

[PATCHv2 08/11] git p4: handle files with wildcards when doing RCS scrubbing

Commit 9d7d446 (git p4: submit files with wildcards, 2012-04-29) fixed problems with handling files that had p4 wildcard characters, like "@" and "*". But it missed one case, that of RCS keyword scrubbing, which uses "p4 fstat" to extract type information. Fix it by calling wildcard_encode() on t

[PATCHv2 07/11] git p4 test: do not pollute /tmp

Generating the submit template for p4 uses tempfile.mkstemp(), which by default puts files in /tmp. For a test that fails, possibly on purpose, this is not cleaned up. Run with TMPDIR pointing into the trash directory so the temp files go away with the test results. To do this required some othe

[PATCHv2 10/11] git p4 test: examine behavior with locked (+l) files

The p4 server can enforce file locking, so that only one user can edit a file at a time. Git p4 is unable to submit changes to locked files. Currently it exits poorly. Ideally it would notice the locked condition and clean up nicely. Add a bunch of tests that describe the problem, hoping that f

[PATCHv2 09/11] git p4: fix an error message when "p4 where" fails

When "p4 where" fails, for whatever reason, the error message tries to show an undefined variable. This minor bug applies only when using a client spec, and was introduced recently in 9d57c4a (git p4: implement view spec wildcards with "p4 where", 2013-08-30). Signed-off-by: Pete Wyckoff --- gi

[PATCHv2 11/11] git p4 doc: use two-line style for options with multiple spellings

Thomas Rast noticed the docs have a mix of styles when it comes to options with multiple spellings. Standardize the couple in git-p4.txt that are odd. Instead of: -n, --dry-run:: Do this: -n:: --dry-run:: See http://thread.gmane.org/gmane.comp.version-control.git/219936/focus=219945 Sign

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote: > Ken Moffat writes: > > > I note that all of these *are* still available at googlecode for > > the moment : https://code.google.com/p/git-core/downloads/list > > As I said, Cgc is not the ony download site. The end of > > ht

What's cooking in git.git (Jan 2014, #04; Wed, 22)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-publi

Re: problematic git log submodule-dir/

On Thu, Jan 23, 2014 at 3:35 AM, Jens Lehmann wrote: > Am 20.01.2014 19:25, schrieb Paweł Sikora: >> i've noticed that 'git log submodule-dir' and 'git log submodule-dir/' >> return different results (module's head changes vs. nothing). is it a bug? >> looks like a trailing slash is a problem for

[RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

From: Linus Torvalds Date: Wed, 22 Jan 2014 15:23:48 -0800 Subject: [PATCH] Make request-pull able to take a refspec of form local:remote This allows a user to say that a local branch has a different name on the remote server, using the same syntax that "git push" uses to create that situation.

Re: [PATCH v2 2/2] repack: accept larger window-memory and max-pack-size

On Wed, Jan 22, 2014 at 11:58:05AM -0800, Junio C Hamano wrote: > These quantities can be larger than an int. Use ulong to express > them like the underlying pack-objects does, and also parse them with > the human-friendly unit suffixes. Hrm. I think that is a valid strategy, but... > - int

Re: [PATCH v2 2/2] repack: accept larger window-memory and max-pack-size

On Wed, Jan 22, 2014 at 08:06:42PM -0500, Jeff King wrote: > But I think there is a subtle problem. Here (and elsewhere) we use the > parsed value of "0" as a sentinel. I think that is OK for > --max-pack-size, where "0" is not a reasonable value. But git-repack(1) > says: > > --window-memory=0

[PATCH 1/3] repack: fix typo in max-pack-size option

When we see "--max-pack-size", we accidentally propagated this to pack-objects as "--max_pack_size", which does not work at all. Signed-off-by: Jeff King --- builtin/repack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/repack.c b/builtin/repack.c index ba66c6e..52

[PATCH 2/3] repack: make parsed string options const-correct

When we use OPT_STRING to parse an option, we get back a pointer into the argv array, which should be "const char *". The compiler doesn't notice because it gets passed through a "void *" in the option struct. Signed-off-by: Jeff King --- Not a big deal, but just for consistency with the next pat

[PATCH 3/3] repack: propagate pack-objects options as strings

In the original shell version of git-repack, any options destined for pack-objects were left as strings, and passed as a whole. Since the C rewrite in commit a1bbc6c (repack: rewrite the shell script in C, 2013-09-15), we now parse these values to integers internally, then reformat the integers whe

Re: [PATCH 3/3] repack: propagate pack-objects options as strings

On Wed, Jan 22, 2014 at 08:30:13PM -0500, Jeff King wrote: > - OPT_INTEGER(0, "window", &window, > + OPT_STRING(0, "window", &window, N_("n"), > N_("size of the window used for delta > compression")), By the way, the old code with OPT_INTEGER

Re: libz and RHEL 5.9 compile of Git

On Wed, Jan 22, 2014 at 01:27:09PM -0800, salmansheikh wrote: > Got it working but then I had some issues with the perl portions of the > install and I subsequently thought I could eliminate those portions and > tried setting export NO_PERL=1 and that installed everything else...and got > pass thi

Re: [PATCH v4 08/23] ewah: compressed bitmap implementation

Hi, Jeff King wrote: > EWAH is a word-aligned compressed variant of a bitset (i.e. a data > structure that acts as a 0-indexed boolean array for many entries). I suspect that for some callers it's not word-aligned. Without the following squashed in, commits 212f2ffb and later fail t5310 on some

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote: > Two questions: Does regenerating (e.g. if the tarball has dropped > out of the cache) change its sums (md5sum or similar) ? In (beyond) > linuxfromscratch we use md5sums to verify that a tarball has not > changed. The tarballs we aut

Re: [PATCH 2/3] setup_pager: set MORE=R

On Tue, Jan 21, 2014 at 12:42:58AM -0800, Kyle J. McKay wrote: > This attempts to show colors but doesn't work properly: > > LESS=-+R git -c color.ui=auto -c color.pager=true log --oneline --graph > > but this does > > LESS=-R git -c color.ui=auto -c color.pager=true log --oneline --graph >

[PATCH v3] git-svn: memoize _rev_list and rebuild

From: lin zuojian According to profile data, _rev_list and rebuild consume a large portion of time. Memoize the results of _rev_list and memoize rebuild internals to avoid subprocess invocation. When importing 15152 revisions on a LAN, time improved from 10 hours to 3-4 hours. Signed-off-by: l

WIth git-next, writing bitmaps fails when keep files are present

Running git-next, writing bitmap indexes fails if a keep file is present from an earlier pack. With git at b139ac2, the following commands demonstrate the problem: git init test cd test touch a git add a git commit -m "a" git repack -ad # generate a pack file for f in .git/objects/pack/*.pack

bug with git-diff --quiet

I found "git-diff --quiet" returns a zero exit status even if there's a change. The following sequence reproduces the bug: $ mkdir foo $ cd foo $ git init $ echo a > a.txt $ echo b >b.txt $ git add ?.txt $ git commit $ echo b >> b.txt $ touch a.txt $ git diff --quiet; echo $?

Re: [PATCH v3] git-svn: memoize _rev_list and rebuild

manjian2...@gmail.com wrote: > According to profile data, _rev_list and rebuild consume a large > portion of time. Memoize the results of _rev_list and memoize > rebuild internals to avoid subprocess invocation. > > When importing 15152 revisions on a LAN, time improved from 10 > hours to 3-4 hou

Re: [PATCH 1/4] subtree: support split --rejoin --squash

On Wed, Jan 22, 2014 at 03:58:28PM +0100, Pierre Penninckx wrote: > 2013/12/7 Matthew Ogilvie > > Subject: [PATCH 1/4] subtree: support split --rejoin --squash > > > > Allow using --squash with "git subtree split --rejoin". It > > will still split off (and save to --branch) the complete > > subtr

Nike Footwear Fulfill Distinct Desires involving Consumers

For Nike, that likes a worldwide celebrity. These days, you'll find innumerable forms of goods manufactured by Nike Provider, on the other hand, in terms of the most popular kinds, that really should become nike free damen

[PATCH v2] Makefile: Fix compilation of Windows resource file

From: Johannes Sixt If the git version number consists of less than three period separated numbers, then the Windows resource file compilation issues a syntax error: $ touch git.rc $ make V=1 git.res GIT_VERSION = 1.9.rc0 windres -O coff \ -DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \