* Re: Git, Builds, and Filesystem Type
From: Martin Fick @ 2012-02-09 23:34 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi387-bimYEG4bjFOjaCwhPeDyLRj7wOJgyuKSCrZ9kBFg@mail.gmail.com>
On Thursday, February 09, 2012 04:24:47 pm Hilco Wijbenga
wrote:
> On 9 February 2012 13:53, Martin Fick
<mfick@codeaurora.org> wrote:
> > On Thursday, February 09, 2012 02:23:18 pm Hilco
> > Wijbenga
> >
> > wrote:
> >> For the record, our (Java) project is quite small.
> >> It's 43MB (source and images) and the entire
> >> directory tree after building is about 1.6GB (this
> >> includes all JARs downloaded by Maven). So we're not
> >> talking TBs of data.
> >>
> >> Any thoughts on which FSs to include in my tests? Or
> >> simply which FS might be more appropriate?
> >
> > tmpfs is probably fastest hands down if you can use it
> > (even if you have to back it by swap).
>
> I don't have quite that much RAM. :-)
But I am sure that you have that much disk space which you
can allocate to swap, if not you already couldn't build it.
And tmpfs swapping is still likely faster than a persistent
FS (it will not need to block on syncs). If you are
benchmarking, it is likely worth you effort since that will
probably mark the upper performance bound,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-09 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nuzvbnr.fsf@alter.siamese.dyndns.org>
On Fri, 10 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> The lack of any real use of @fill_only in this patch also makes it hard to
>>> judge if the new API gives a useful semantics. I would, without looking
>>> at the real usage in 2/5 patch, naïvely expect that such a lazy filling
>>> scheme would say "I am going to use A, B and C; I want to know if any of
>>> them is missing, because I need values for all of them and I am going to
>>> call a helper function to fill them if any of them is missing. Having A
>>> and B is not enough for the purpose of this query, because I still need to
>>> know C and I would call the helper function that computes all of them in
>>> such a case. Even though it might be wasteful to recompute A and B,
>>> computing all three at once is the only helper function available to me".
>>>
>>> So for a person who does not have access to the real usage of the new API,
>>> being able to give only a single $key *appears* make no sense at all, and
>>> also the meaning of the @fill_only parameter is unclear, especially the
>>> part that checks if that single $key appears in @fill_only.
>>
>> ...
>> information that is not already present. If @fill_only is nonempty, it
>> fills only selected information, again only if it is not already present.
>> @fill_only empty means no restrictions... which probably is not very obvious,
>> but is documented.
>>
>> project_info_needs_filling() returns true if $key is not filled and is
>> interesting.
>
> That still does not answer the fundamental issues I had with the presented
> API: why does it take only a single $key (please re-read my "A, B and C"
> example), and what does that single $key intersecting with @fill_only have
> anything to do with "needs-filling"?
project_info_needs_filling() in absence of @fill_only is just a thin
wrapper around "!defined $pr->{$key}", it checks for each key if it needs
to be filled.
It is used like this
if (project_info_needs_filled("A", "A, B, C")) {
fill A
}
if (project_info_needs_filled("B", "A, B, C")) {
fill B
}
...
> After all, that 'age' check actually wants to fill 'age' and 'age_string'
> in the project. Even if some other codepath starts filling 'age' in the
> project with a later change, the current callers of fill_project_list_info
> expects _both_ to be filled. So "I know the current implementation fills
> both at the same time, so checking 'age' alone is sufficient" is not an
> answer that shows good taste in the API design.
It is not as much matter of API, as the use of checks in loop in
fill_project_list_info().
What is now
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
should be
if (!defined $pr->{'age'} ||
!defined $pr->{'age_string'}) {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
which would translate to
if (project_info_needs_filled($pr, 'age') ||
project_info_needs_filled($pr, 'age_string') {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
and then with @fill_only
if (project_info_needs_filled($pr, 'age', @fill_only) ||
project_info_needs_filled($pr, 'age_string', @fill_only) {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
The same should be done for 'descr_long' and 'descr' which are also
always filled together.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-09 23:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202100052.26399.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Fri, 10 Feb 2012, Junio C Hamano wrote:
> ...
>> That still does not answer the fundamental issues I had with the presented
>> API: why does it take only a single $key (please re-read my "A, B and C"
>> example), and what does that single $key intersecting with @fill_only have
>> anything to do with "needs-filling"?
>
> project_info_needs_filling() in absence of @fill_only is just a thin
> wrapper around "!defined $pr->{$key}", it checks for each key if it needs
> to be filled.
>
> It is used like this
>
> if (project_info_needs_filled("A", "A, B, C")) {
> fill A
> }
> if (project_info_needs_filled("B", "A, B, C")) {
> fill B
> }
> ...
>
>> After all, that 'age' check actually wants to fill 'age' and 'age_string'
>> in the project. Even if some other codepath starts filling 'age' in the
>> project with a later change, the current callers of fill_project_list_info
>> expects _both_ to be filled. So "I know the current implementation fills
>> both at the same time, so checking 'age' alone is sufficient" is not an
>> answer that shows good taste in the API design.
>
> It is not as much matter of API, as the use of checks in loop in
> fill_project_list_info().
>
> What is now
>
> my (@activity) = git_get_last_activity($pr->{'path'});
> unless (@activity) {
> next PROJECT;
> }
> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
>
> should be
>
> if (!defined $pr->{'age'} ||
> !defined $pr->{'age_string'}) {
> my (@activity) = git_get_last_activity($pr->{'path'});
> unless (@activity) {
> next PROJECT;
> }
> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
> }
Huh? Compare that with what you wrote above "It is used like this". This
is *NOT* using the API like that. The caller knows it wants both age and
age-string, and if even one of them is missing, do the work to fill both.
So why isn't the info-needs-filled API not checking _both_ with a single
call? It is only because you designed the API to accept only a single $key
instead of list of "here are what I care about".
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-10 0:00 UTC (permalink / raw)
To: git; +Cc: gitster, peff
In-Reply-To: <1328816616-18124-2-git-send-email-tmgrennan@gmail.com>
On Thu, Feb 09, 2012 at 11:43:36AM -0800, Tom Grennan wrote:
>Use the "!" prefix to ignore tags of the given pattern.
>This has precedence over other matching patterns.
>For example,
...
> static int match_pattern(const char **patterns, const char *ref)
> {
>+ int ret;
>+
> /* no pattern means match everything */
> if (!*patterns)
> return 1;
>- for (; *patterns; patterns++)
>- if (!fnmatch(*patterns, ref, 0))
>- return 1;
>- return 0;
>+ for (ret = 0; *patterns; patterns++)
>+ if (**patterns == '!') {
>+ if (!fnmatch(*patterns+1, ref, 0))
>+ return 0;
>+ } else if (!fnmatch(*patterns, ref, 0))
>+ ret = 1;
>+ return ret;
> }
Correction, match_pattern() needs to be as follows to support all these cases,
$ git tag -l
$ git tag -l \!*-rc?
$ git tag -l \!*-rc? v1.7.8*
$ git tag -l v1.7.8* \!*-rc?
$ git tag -l v1.7.8*
--
TomG
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..e99be5c 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -32,13 +32,16 @@ struct tag_filter {
static int match_pattern(const char **patterns, const char *ref)
{
- /* no pattern means match everything */
- if (!*patterns)
- return 1;
+ int had_match_pattern = 0, had_match = 0;
+
for (; *patterns; patterns++)
- if (!fnmatch(*patterns, ref, 0))
- return 1;
- return 0;
+ if (**patterns != '!') {
+ had_match_pattern = 1;
+ if (!fnmatch(*patterns, ref, 0))
+ had_match = 1;
+ } else if (!fnmatch(*patterns+1, ref, 0))
+ return 0;
+ return had_match_pattern ? had_match : 1;
}
static int in_commit_list(const struct commit_list *want, struct commit *c)
^ permalink raw reply related
* What's cooking in git.git (Feb 2012, #03; Thu, 9)
From: Junio C Hamano @ 2012-02-10 0:15 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2012, #03; Thu, 9)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
Compared to the recent activity level on discussions of new features on
the list, some people may be wondering if the rate of advancement of the
'master' and 'next' branches is getting throttled.
That is because it is.
Now the obviously good bits that have been cooking during the feature
freeze are pushed out to 'master', I'd want to make sure we can have a
timely release of v1.7.9.1 so that people can start benefiting from the
features and fixes introduced in v1.7.9 more smoothly and sooner, and that
is where my focus lies at this moment. I've been picking up new topics and
adding them to 'pu' only "as time and attention permit" basis, and this
mode of operation probably will continue throughout the second week of the
post v1.7.9 cycle (cf. http://tinyurl.com/gitcal).
I would like to see more people test the tip of 'pu' as soon as possible
to make sure the fixes to 'git merge' give more pleasant user experience
than stock 1.7.9 release. Things to expect are:
* "git merge --ff-only v3.2" that should fast-forward to the commit that
is tagged should fast-forward, without creating the merge commit that
records the contents taken from v3.2 tag (the topic
jc/merge-ff-only-stronger-than-signed-merge in 'next' should take care
of this issue);
* "git merge --no-edit v3.2" does not spawn an editor, but does create
the merge commit to record the contents taken from v3.2 tag (the topic
jn/merge-no-edit-fix in 'pu' should take care of this issue).
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* bl/gitweb-project-filter (2012-02-01) 8 commits
(merged to 'next' on 2012-02-01 at 2c96ce7)
+ gitweb: Make project search respect project_filter
+ gitweb: improve usability of projects search form
+ gitweb: place links to parent directories in page header
+ gitweb: show active project_filter in project_list page header
+ gitweb: limit links to alternate forms of project_list to active project_filter
+ gitweb: add project_filter to limit project list to a subdirectory
+ gitweb: prepare git_get_projects_list for use outside 'forks'.
+ gitweb: move hard coded .git suffix out of git_get_projects_list
"gitweb" allows intermediate entries in the directory hierarchy that leads
to a projects to be clicked, which in turn shows the list of projects
inside that directory.
* jc/maint-request-pull-for-tag (2012-01-31) 1 commit
(merged to 'next' on 2012-02-01 at 7649f18)
+ request-pull: explicitly ask tags/$name to be pulled
When asking for a tag to be pulled, "request-pull" shows the name of the
tag prefixed with "tags/"
* jn/svn-fe (2012-02-02) 47 commits
(merged to 'next' on 2012-02-05 at e9d3917)
+ vcs-svn: suppress a -Wtype-limits warning
+ vcs-svn: allow import of > 4GiB files
+ vcs-svn: rename check_overflow arguments for clarity
(merged to 'next' on 2012-02-01 at 9288c95)
+ vcs-svn/svndiff.c: squelch false "unused" warning from gcc
+ Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
+ vcs-svn: reset first_commit_done in fast_export_init
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: do not initialize report_buffer twice
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: avoid hangs from corrupt deltas
+ vcs-svn: guard against overflow when computing preimage length
+ Merge branch 'db/delta-applier' into db/text-delta
+ vcs-svn: implement text-delta handling
+ Merge branch 'db/delta-applier' into db/text-delta
+ Merge branch 'db/delta-applier' into svn-fe
+ vcs-svn: cap number of bytes read from sliding view
+ test-svn-fe: split off "test-svn-fe -d" into a separate function
+ vcs-svn: let deltas use data from preimage
+ vcs-svn: let deltas use data from postimage
+ vcs-svn: verify that deltas consume all inline data
+ vcs-svn: implement copyfrom_data delta instruction
+ vcs-svn: read instructions from deltas
+ vcs-svn: read inline data from deltas
+ vcs-svn: read the preimage when applying deltas
+ vcs-svn: parse svndiff0 window header
+ vcs-svn: skeleton of an svn delta parser
+ vcs-svn: make buffer_read_binary API more convenient
+ vcs-svn: learn to maintain a sliding view of a file
+ Makefile: list one vcs-svn/xdiff object or header per line
+ Merge branch 'db/svn-fe-code-purge' into svn-fe
+ vcs-svn: drop obj_pool
+ vcs-svn: drop treap
+ vcs-svn: drop string_pool
+ vcs-svn: pass paths through to fast-import
+ Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
+ Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
+ Merge branch 'db/vcs-svn-incremental' into svn-fe
+ vcs-svn: avoid using ls command twice
+ vcs-svn: use mark from previous import for parent commit
+ vcs-svn: handle filenames with dq correctly
+ vcs-svn: quote paths correctly for ls command
+ vcs-svn: eliminate repo_tree structure
+ vcs-svn: add a comment before each commit
+ vcs-svn: save marks for imported commits
+ vcs-svn: use higher mark numbers for blobs
+ vcs-svn: set up channel to read fast-import cat-blob response
+ Merge commit 'v1.7.5' into svn-fe
Originally merged to 'next' on 2012-01-29.
"vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support
incremental imports.
* jx/i18n-more-marking (2012-02-01) 2 commits
(merged to 'next' on 2012-02-05 at 44e8cf6)
+ i18n: format_tracking_info "Your branch is behind" message
+ i18n: git-commit whence_s "merge/cherry-pick" message
Marks a few more messages we forgot to mark for i18n.
* rt/completion-branch-edit-desc (2012-01-29) 1 commit
(merged to 'next' on 2012-02-01 at 0627ebf)
+ completion: --edit-description option for git-branch
Originally merged to 'next' on 2012-01-31.
--------------------------------------------------
[New Topics]
* jk/config-include (2012-02-06) 2 commits
- config: add include directive
- docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
* jk/maint-tag-show-fixes (2012-02-08) 3 commits
(merged to 'next' on 2012-02-08 at 18459c4)
+ tag: do not show non-tag contents with "-n"
+ tag: die when listing missing or corrupt objects
+ tag: fix output of "tag -n" when errors occur
Bugfixes to "git tag -n" that lacked much error checking.
* mm/empty-loose-error-message (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at f119cac)
+ fsck: give accurate error message on empty loose object files
Updates the error message emitted when we see an empty loose object.
* nd/columns (2012-02-08) 15 commits
- column: Fix some compiler and sparse warnings
- column: add a corner-case test to t3200
- columns: minimum coding style fixes
- tag: add --column
- column: support piping stdout to external git-column process
- status: add --column
- branch: add --column
- help: reuse print_columns() for help -a
- column: add column.ui for default column output settings
- column: support columns with different widths
- column: add columnar layout
- Stop starting pager recursively
- Add git-column and column mode parsing
- column: add API to print items in columns
- Save terminal width before setting up pager
The "show list of ..." mode of a handful of commands learn to produce
column-oriented output.
Expecting a reroll.
* jc/maint-commit-ignore-i-t-a (2012-02-07) 1 commit
- commit: ignore intent-to-add entries instead of refusing
Replaces the nd/commit-ignore-i-t-a series that was made unnecessary
complicated by bad suggestions I made earlier.
* jk/userdiff-config-simplify (2012-02-07) 1 commit
- drop odd return value semantics from userdiff_config
Code cleanup.
* js/add-e-submodule-fix (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at c8e2d28)
+ add -e: do not show difference in a submodule that is merely dirty
"add -e" learned not to show a diff for an otherwise unmodified submodule
that only has uncommitted local changes in the patch prepared by for the
user to edit.
* nd/cache-tree-api-refactor (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at a9abbca)
+ cache-tree: update API to take abitrary flags
Code cleanup.
* tg/tag-points-at (2012-02-08) 1 commit
- tag: add --points-at list option
Will merge to 'next'.
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
* jn/merge-no-edit-fix (2012-02-09) 1 commit
- merge: do not launch an editor on "--no-edit $tag"
(this branch uses jc/merge-ff-only-stronger-than-signed-merge.)
* ld/git-p4-expanded-keywords (2012-02-09) 2 commits
- git-p4: initial demonstration of possible RCS keyword fixup
- git-p4: add test case for RCS keywords
* mp/make-cleanse-x-for-exe (2012-02-09) 1 commit
(merged to 'next' on 2012-02-09 at 35cc89d)
+ Explicitly set X to avoid potential build breakage
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
--------------------------------------------------
[Cooking]
* bw/inet-pton-ntop-compat (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 61303e6)
+ Drop system includes from inet_pton/inet_ntop compatibility wrappers
The inclusion order of header files bites Solaris again and this fixes it.
* jc/branch-desc-typoavoidance (2012-02-05) 2 commits
(merged to 'next' on 2012-02-06 at 9fb0568)
+ branch --edit-description: protect against mistyped branch name
+ tests: add write_script helper function
(this branch is tangled with jk/tests-write-script.)
Typo in "git branch --edit-description my-tpoic" was not diagnosed.
* jc/checkout-out-of-unborn (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at 60eb328)
+ git checkout -b: allow switching out of an unborn branch
I was fairly negative on this one, but Michael Haggerty and Peff convinced
me that selling this as "'checkout -b' that lack the <start point> is
about creating a new branch from my current state" is perfectly fine.
* jc/maint-mailmap-output (2012-02-06) 1 commit
(merged to 'next' on 2012-02-06 at 0a21425)
+ mailmap: always return a plain mail address from map_user()
map_user() was not rewriting its output correctly, which resulted in the
user visible symptom that "git blame -e" sometimes showed excess '>' at
the end of email addresses.
* jc/merge-ff-only-stronger-than-signed-merge (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 0fabf12)
+ merge: do not create a signed tag merge under --ff-only option
(this branch is used by jn/merge-no-edit-fix.)
"git merge --ff-only $tag" failed because it cannot record the required
mergetag without creating a merge, but this is so common operation for
branch that is used _only_ to follow the upstream, so it is allowed to
fast-forward without recording the mergetag.
* tt/profile-build-fix (2012-02-09) 2 commits
(merged to 'next' on 2012-02-09 at 1c183af)
+ Makefile: fix syntax for older make
(merged to 'next' on 2012-02-07 at c8c5f3f)
+ Fix build problems related to profile-directed optimization
* nd/diffstat-gramnum (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 7335ecc)
+ Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
* jk/grep-binary-attribute (2012-02-02) 9 commits
(merged to 'next' on 2012-02-05 at 9dffa7e)
+ grep: pre-load userdiff drivers when threaded
+ grep: load file data after checking binary-ness
+ grep: respect diff attributes for binary-ness
+ grep: cache userdiff_driver in grep_source
+ grep: drop grep_buffer's "name" parameter
+ convert git-grep to use grep_source interface
+ grep: refactor the concept of "grep source" into an object
+ grep: move sha1-reading mutex into low-level code
+ grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
* jc/parse-date-raw (2012-02-03) 2 commits
(merged to 'next' on 2012-02-07 at 486ae6e)
+ parse_date(): '@' prefix forces git-timestamp
+ parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
* jk/git-dir-lookup (2012-02-02) 1 commit
(merged to 'next' on 2012-02-05 at 1856d74)
+ standardize and improve lookup rules for external local repos
When you have both .../foo and .../foo.git, "git clone .../foo" did not
favor the former but the latter.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
(merged to 'next' on 2012-02-06 at c0c995a)
+ prompt: fall back to terminal if askpass fails
+ prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jk/tests-write-script (2012-02-03) 2 commits
(merged to 'next' on 2012-02-05 at 4264ffa)
+ t0300: use write_script helper
+ tests: add write_script helper function
(this branch is tangled with jc/branch-desc-typoavoidance.)
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 055e446)
+ gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
* jn/rpm-spec (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at dba940b)
+ git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
* fc/zsh-completion (2012-02-06) 3 commits
(merged to 'next' on 2012-02-06 at c94dd12)
+ completion: simplify __gitcomp and __gitcomp_nl implementations
+ completion: use ls -1 instead of rolling a loop to do that ourselves
+ completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
(merged to 'next' on 2012-02-05 at d0dc25d)
+ pack-objects: convert to use parse_options()
+ pack-objects: remove bogus comment
+ pack-objects: do not accept "--index-version=version,"
"pack-objects" learned use parse-options, losing custom command line
parsing code.
--------------------------------------------------
[Discarded]
* nd/commit-ignore-i-t-a (2012-02-06) 4 commits
. commit: remove commit.ignoreIntentToAdd, assume it's always true
. commit: turn commit.ignoreIntentToAdd to true by default
. commit: introduce a config key to allow as-is commit with i-t-a entries
. cache-tree: update API to take abitrary flags
Instead of using configuration to selectively delay bugfixes like this
series does, let's sell it as a pure bugfix.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 0:23 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: ftpadmin, Petr Onderka, git
In-Reply-To: <20120208213410.GA5768@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Please restore access to the following files when possible. Some sites
> are referencing those, including kernel.org itself:
>
> http://www.kernel.org/pub/software/scm/git/docs/git.html
The pages reachable from this used to be living documents in that every
time the 'master' branch was updated at k.org, automatically a server side
hook script generated a new set of HTML pages and updated them.
My understanding is that we do not want to run such random server side
hooks at k.org, so it no longer can be a living document anymore.
It might be a workable short term workaround to redirect
http://www.kernel.org/pub/software/scm/git/docs/$anything
to
http://schacon.github.com/git/$anything
although that would not give you an access to the list of documentations
for older releases, e.g.
http://www.kernel.org/pub/software/scm/git/docs/v1.6.0/git.html
> Also, it would be great if the git wiki could be made editable again.
Amen.
^ permalink raw reply
* [PATCH 3/4] diff --stat: use the real terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Some projects (especially in Java), have long filename paths, with
nested directories or long individual filenames. When files are
renamed, the stat output can be almost useless. If the middle part
between { and } is long (because the file was moved to a completely
different directory), then most of the path would be truncated.
It makes sense to use the full terminal width.
The output is still not optimal, because too many columns are devoted
to +- output, and not enough to filenames, but this is a policy
question, changed in next commit.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
diff.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 7e15426..8406a0d 100644
--- a/diff.c
+++ b/diff.c
@@ -7,6 +7,7 @@
#include "diffcore.h"
#include "delta.h"
#include "xdiff-interface.h"
+#include "help.h"
#include "color.h"
#include "attr.h"
#include "run-command.h"
@@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
line_prefix = msg->buf;
}
- width = options->stat_width ? options->stat_width : 80;
+ width = options->stat_width ? options->stat_width : term_columns();
name_width = options->stat_name_width ? options->stat_name_width : 50;
count = options->stat_count ? options->stat_count : data->nr;
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 2/4] help.c: make term_columns() cached and export it
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Since term_columns() will usually fail, when a pager is installed,
the cache is primed before the pager is installed. If a pager is not
installed, then the cache will be set on first use.
Conforms to The Single UNIX Specification, Version 2
(http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html#tag_002_003).
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
help.c | 31 +++++++++++++++++++++++--------
help.h | 2 ++
| 5 +++++
3 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index bc15066..75b8d4b 100644
--- a/help.c
+++ b/help.c
@@ -5,26 +5,41 @@
#include "help.h"
#include "common-cmds.h"
-/* most GUI terminals set COLUMNS (although some don't export it) */
-static int term_columns(void)
+/* cache for term_columns() value. Set on first use or when
+ * installing a pager and replacing stdout.
+ */
+static int term_columns_cache;
+
+/* Return cached value (iff set) or $COLUMNS (iff set and positive) or
+ * ioctl(1, TIOCGWINSZ).ws_col (if positive) or 80.
+ *
+ * $COLUMNS even if set, is usually not exported, so
+ * the variable can be used to override autodection.
+ */
+int term_columns(void)
{
- char *col_string = getenv("COLUMNS");
- int n_cols;
+ if (term_columns_cache)
+ return term_columns_cache;
- if (col_string && (n_cols = atoi(col_string)) > 0)
- return n_cols;
+ {
+ char *col_string = getenv("COLUMNS");
+ int n_cols;
+
+ if (col_string && (n_cols = atoi(col_string)) > 0)
+ return (term_columns_cache = n_cols);
+ }
#ifdef TIOCGWINSZ
{
struct winsize ws;
if (!ioctl(1, TIOCGWINSZ, &ws)) {
if (ws.ws_col)
- return ws.ws_col;
+ return (term_columns_cache = ws.ws_col);
}
}
#endif
- return 80;
+ return (term_columns_cache = 80);
}
void add_cmdname(struct cmdnames *cmds, const char *name, int len)
diff --git a/help.h b/help.h
index b6b12d5..880a4b4 100644
--- a/help.h
+++ b/help.h
@@ -29,4 +29,6 @@ extern void list_commands(const char *title,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern int term_columns(void);
+
#endif /* HELP_H */
--git a/pager.c b/pager.c
index 975955b..e7032de 100644
--- a/pager.c
+++ b/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include "help.h"
#ifndef DEFAULT_PAGER
#define DEFAULT_PAGER "less"
@@ -76,6 +77,10 @@ void setup_pager(void)
if (!pager)
return;
+ /* prime the term_columns() cache before it is too
+ * late and stdout is replaced */
+ (void) term_columns();
+
setenv("GIT_PAGER_IN_USE", "true", 1);
/* spawn the pager */
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 4/4] diff --stat: use most of the space for file names
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
diff.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 8406a0d..6220190 100644
--- a/diff.c
+++ b/diff.c
@@ -1343,7 +1343,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
}
width = options->stat_width ? options->stat_width : term_columns();
- name_width = options->stat_name_width ? options->stat_name_width : 50;
+ name_width = options->stat_name_width ? options->stat_name_width
+ : term_columns() - 20; /* the graph defaults to 20 columns */
count = options->stat_count ? options->stat_count : data->nr;
/* Sanity: give at least 5 columns to the graph,
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 1/4] Move git_version_string to help.c in preparation for diff changes
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
git_version_string is declared in builtins.h, but lived in git.c.
When diff.c starts to use functions from help.c, linking against
libgit.a will fail, unless git.o containing git_version_string is
linked too. This variable is only used in a couple of places, help.c
being one of them. git.o is biggish, so it let's move
git_version_string to help.c.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
Makefile | 5 +++--
git.c | 2 --
help.c | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..264fe4f 100644
--- a/Makefile
+++ b/Makefile
@@ -1851,7 +1851,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
git.o: common-cmds.h
-git.sp git.s git.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"' \
+git.sp git.s git.o: EXTRA_CPPFLAGS = \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
'-DGIT_INFO_PATH="$(infodir_SQ)"'
@@ -1860,7 +1860,8 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.sp help.o: common-cmds.h
+help.o: common-cmds.h
+help.sp help.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"'
builtin/help.sp builtin/help.o: common-cmds.h
builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
diff --git a/git.c b/git.c
index 3805616..a24a0fd 100644
--- a/git.c
+++ b/git.c
@@ -256,8 +256,6 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
-const char git_version_string[] = GIT_VERSION;
-
#define RUN_SETUP (1<<0)
#define RUN_SETUP_GENTLY (1<<1)
#define USE_PAGER (1<<2)
diff --git a/help.c b/help.c
index cbbe966..bc15066 100644
--- a/help.c
+++ b/help.c
@@ -409,6 +409,8 @@ const char *help_unknown_cmd(const char *cmd)
exit(1);
}
+const char git_version_string[] = GIT_VERSION;
+
int cmd_version(int argc, const char **argv, const char *prefix)
{
printf("git version %s\n", git_version_string);
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* (unknown),
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber
Hi,
this is a patch series to make 'git diff --stat' use full terminal
width instead of hard-coded 80 columns.
This is quite useful when working on projects with nested directory
structure, e.g. Java:
.../{ => workspace/tasks}/GetTaskResultAction.java | 10 +-
.../tasks}/RemoveAllAbortedTasksAction.java | 7 +-
.../tasks}/RemoveAllFailedTasksAction.java | 7 +-
is changed to display full paths if the terminal window is wide
enough.
Git usually uses the full terminal width automatically, so it should
do so with --stat too.
The "big" functional change in the patch series is s/80/term_columns()/
in show_stats(). The fourth patch also changes the partitioning of
available columns to dedicate more space to file names.
^ permalink raw reply
* Re: fatal: Unable to find remote helper for 'https'
From: Tay Ray Chuan @ 2012-02-10 0:25 UTC (permalink / raw)
To: Nickolai Leschov; +Cc: git
In-Reply-To: <loom.20120209T224147-400@post.gmane.org>
Have you installed libcurl4-(gnutls|openssl)-dev? You'll need to
choose between gnutls and openssl for the underlying ssl
implementation.
--
Cheers,
Ray Chuan
On Fri, Feb 10, 2012 at 5:51 AM, Nickolai Leschov <nleschov@gmail.com> wrote:
> Hello,
>
> I have compiled git 1.7.9 from source on Ubuntu 9.04 and I get the following
> message when cloning a git repo:
>
> fatal: Unable to find remote helper for 'https'
>
> I get this message when I try to use https; or similar one for http. Only
> cloning via git:// protocol works. My system is Ubuntu 9.04 i386. git 1.7.9 and
> two previous versions I tried all exhibit this problem. I have uninstalled the
> git that comes in Ubuntu repositories and build from source instead because I
> need a newer version.
>
> How can I make git work on that system?
>
> I have another system with Ubuntu 11.04 i386 and it there git 1.7.4.1 (from
> repositories) doesn't exhibit such problem.
>
> Best regards,
>
> Nickolai Leschov
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] Move git_version_string to help.c in preparation for diff changes
From: Junio C Hamano @ 2012-02-10 0:46 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, Michael J Gruber
In-Reply-To: <1328831921-27272-2-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git_version_string is declared in builtins.h, but lived in git.c.
>
> When diff.c starts to use functions from help.c, linking against
> libgit.a will fail, unless git.o containing git_version_string is
> linked too.
Sorry, it is unclear what you mean by the above, nor why you need this
change in the first place. The resulting diff.o will certainly linked to
git.o as it does not have its own "main()" at all. And builtins.h is a
perfect place to declare things that are for the use of built-in commands
like implementations of diff family of commands, as they all are linked
into git.o (namely the commands[] array in handle_internal_command()) to
be usable.
What am I missing from between the lines of your log message?
^ permalink raw reply
* Re: [PATCH 2/4] help.c: make term_columns() cached and export it
From: Junio C Hamano @ 2012-02-10 0:50 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-3-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> diff --git a/help.c b/help.c
> index bc15066..75b8d4b 100644
> --- a/help.c
> +++ b/help.c
> @@ -5,26 +5,41 @@
> #include "help.h"
> #include "common-cmds.h"
>
> -/* most GUI terminals set COLUMNS (although some don't export it) */
> -static int term_columns(void)
> +/* cache for term_columns() value. Set on first use or when
> + * installing a pager and replacing stdout.
> + */
Just a style.
/*
* We format multi-line
* comment block like
* this.
*/
> +static int term_columns_cache;
> +
> +/* Return cached value (iff set) or $COLUMNS (iff set and positive) or
> + * ioctl(1, TIOCGWINSZ).ws_col (if positive) or 80.
> + *
> + * $COLUMNS even if set, is usually not exported, so
> + * the variable can be used to override autodection.
> + */
> +int term_columns(void)
> {
> - char *col_string = getenv("COLUMNS");
> - int n_cols;
> + if (term_columns_cache)
> + return term_columns_cache;
>
> - if (col_string && (n_cols = atoi(col_string)) > 0)
> - return n_cols;
> + {
> + char *col_string = getenv("COLUMNS");
> + int n_cols;
> +
> + if (col_string && (n_cols = atoi(col_string)) > 0)
> + return (term_columns_cache = n_cols);
> + }
I can see the justification for the existing one inside the #ifdef below,
but why do you need the extra scope above?
We tend to avoid assignment as a part of another expression. The old code
already violates that convention, but please do not make it worse by
introducing three new ones.
^ permalink raw reply
* Re: Merging only a subdirectory from one branch to the other
From: Neal Kreitzinger @ 2012-02-10 0:51 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <CAHVO_90MQamw7oB8ry5YBEWSnRnxDZvQ4ApVuuv4AYR6VRuXSw@mail.gmail.com>
On 2/7/2012 3:38 AM, Howard Miller wrote:
> I have a branch with a particular subdirectory tree. The tree has a
> lot of history. However, all the history for that subdirectory is
> exclusive to it (no commits changed anything outside it). I now need
> to merge that subdirectory into a completely different branch without
> loosing any history. I think git-read-tree might have something to do
> with it but I don't understand the help file at all. Any help
> appreciated.
>
Does the 'subtree merge' described in this link do what you want:
http://progit.org/book/ch6-7.html
(I can't say I've actually tried it myself, yet.)
v/r,
neal
^ permalink raw reply
* Re: [PATCH 3/4] diff --stat: use the real terminal width
From: Junio C Hamano @ 2012-02-10 0:54 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-4-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> Some projects (especially in Java), have long filename paths, with
> nested directories or long individual filenames. When files are
> renamed, the stat output can be almost useless. If the middle part
> between { and } is long (because the file was moved to a completely
> different directory), then most of the path would be truncated.
>
> It makes sense to use the full terminal width.
>
> The output is still not optimal, because too many columns are devoted
> to +- output, and not enough to filenames, but this is a policy
> question, changed in next commit.
>
> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> ---
> diff.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 7e15426..8406a0d 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -7,6 +7,7 @@
> #include "diffcore.h"
> #include "delta.h"
> #include "xdiff-interface.h"
> +#include "help.h"
> #include "color.h"
> #include "attr.h"
> #include "run-command.h"
> @@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
> line_prefix = msg->buf;
> }
>
> - width = options->stat_width ? options->stat_width : 80;
> + width = options->stat_width ? options->stat_width : term_columns();
The output from "git format-patch" shouldn't be affected at all by the
width of the terminal the patch sender happened to have used when the
command was run when the user did not explicitly ask a custom width by
giving a --stat-width command line option.
How do you prevent regression to the command in this series?
^ permalink raw reply
* Re: [PATCH 4/4] diff --stat: use most of the space for file names
From: Junio C Hamano @ 2012-02-10 0:55 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-5-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> ---
> diff.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 8406a0d..6220190 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1343,7 +1343,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
> }
>
> width = options->stat_width ? options->stat_width : term_columns();
> - name_width = options->stat_name_width ? options->stat_name_width : 50;
> + name_width = options->stat_name_width ? options->stat_name_width
> + : term_columns() - 20; /* the graph defaults to 20 columns */
Why? Isn't 80-50 = 30?
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Neal Kreitzinger @ 2012-02-10 1:04 UTC (permalink / raw)
To: Petr Onderka; +Cc: git
In-Reply-To: <CAPyqok3USqMxm0gNf_T9vnCoicp9XSwpWUCYJ8jh79h=V_UuOA@mail.gmail.com>
On 2/7/2012 6:28 AM, Petr Onderka wrote:
> since the hacking of kernel.org, the online version of git
> documentation [1] is not available. I realize that I can use local
> version of the documentation and there is also at least one mirror
> [2]. But I think it's very useful to have an "official" version of the
> documentation online. And, more importantly, there is now lots of dead
> links all over the Internet to the kernel.org version of the
> documentation.
>
> Can someone with the ability to do so restore the documentation at the
> old location?
>
Additional info:
http://article.gmane.org/gmane.comp.version-control.git/185302
v/r,
neal
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-10 1:11 UTC (permalink / raw)
To: Luke Diamand; +Cc: Git Users
In-Reply-To: <CAE5ih7_NkyJ6vGbyoKvQy65LFK3-zkXi79Xd6+3Si8DyUi47JQ@mail.gmail.com>
On 9 February 2012 15:24, Luke Diamand <luke@diamand.org> wrote:
> On Thu, Feb 9, 2012 at 9:23 PM, Hilco Wijbenga <hilco.wijbenga@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> I'm thinking about trying out different filesystems over the weekend
>> to see if, say, BTRFS or XFS is faster when using Git and running our
>> build.
>>
>> Currently, I'm using ReiserFS and it's not like it's not working. I'm
>> very pleased with ReiserFS but after seeing talks about BTRFS and XFS
>> I'm curious if another (newer) FS is better suited to our specific
>> environment. Anything to make the build a little faster. :-)
>>
>> For the record, our (Java) project is quite small. It's 43MB (source
>> and images) and the entire directory tree after building is about
>> 1.6GB (this includes all JARs downloaded by Maven). So we're not
>> talking TBs of data.
>>
>> Any thoughts on which FSs to include in my tests? Or simply which FS
>> might be more appropriate?
>
>
> Do people still use reiserfs? I thought development on that pretty much
> stopped years ago. And reiser4 never made it into the kernel. Read the wiki
> page for why.
As I said, reiserfs works fine so I see no need to replace it. I'm not
a big fan of ext3 (I've run out of inodes too many times) and I simply
haven't tried ext4. Apparently, it has some architectural problems but
I'm no expert.
> ext4, FTW!
>
> But whatever you use, you might find that the core.preloadindex config
> option helps. It certainly does for NFS.
I would like to think that my local hard drive has no latency issues?
Would this really be worthwhile even if I do not use some sort of
distributed FS?
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-10 1:25 UTC (permalink / raw)
To: Martin Fick; +Cc: Git Users
In-Reply-To: <201202091634.36563.mfick@codeaurora.org>
On 9 February 2012 15:34, Martin Fick <mfick@codeaurora.org> wrote:
> On Thursday, February 09, 2012 04:24:47 pm Hilco Wijbenga
> wrote:
>> On 9 February 2012 13:53, Martin Fick
> <mfick@codeaurora.org> wrote:
>> > On Thursday, February 09, 2012 02:23:18 pm Hilco
>> > Wijbenga
>> >
>> > wrote:
>> >> For the record, our (Java) project is quite small.
>> >> It's 43MB (source and images) and the entire
>> >> directory tree after building is about 1.6GB (this
>> >> includes all JARs downloaded by Maven). So we're not
>> >> talking TBs of data.
>> >>
>> >> Any thoughts on which FSs to include in my tests? Or
>> >> simply which FS might be more appropriate?
>> >
>> > tmpfs is probably fastest hands down if you can use it
>> > (even if you have to back it by swap).
>>
>> I don't have quite that much RAM. :-)
>
> But I am sure that you have that much disk space which you
> can allocate to swap, if not you already couldn't build it.
> And tmpfs swapping is still likely faster than a persistent
> FS (it will not need to block on syncs). If you are
> benchmarking, it is likely worth you effort since that will
> probably mark the upper performance bound,
I found [1]. Is that sort of what you had in mind? That would be quite
tricky. I have a group of some 60 projects, each with their own
"target" directory which would have to be mounted on tmpfs. And the
"target" directory is created by Maven, not by me. Not to mention that
I shut down my computer at the end of the day. :-)
I think I would prefer a somewhat more persistent solution. I
certainly have enough space for a very big swap partition. So the
whole of ~/my-project would fit on tmpfs. I'm just not sure about
making it persistent at the end of the day.
[1] http://code.google.com/p/chromium/wiki/LinuxFasterBuilds
^ permalink raw reply
* 1.7.9, libcharset missing from EXTLIBS
From: Дилян Палаузов @ 2012-02-10 1:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
Hello,
git 1.7.9 makes use of libcharset and /Makefile contains:
ifdef HAVE_LIBCHARSET_H
BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
endif
when building git-daemon., the compiler reports
make V=1
cc -I. -DUSE_LIBPCRE -pthread -DHAVE_PATHS_H -DHAVE_LIBCHARSET_H
-DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o
git-daemon -L/usr/lib64 -L/lib64 daemon.o libgit.a xdiff/lib.a -lpcre
-lz -liconv -lcrypto -pthread
/tmp/ccvPEthi.ltrans0.ltrans.o: In function `main':
ccvPEthi.ltrans0.o:(.text.startup+0x59): undefined reference to
`locale_charset'
collect2: ld returned 1 exit status
make: *** [git-daemon] Error 1
and the problem is, that libcharset is not used when linking. To solve
this, please replace the above extract from /Makefile with
ifdef HAVE_LIBCHARSET_H
BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
EXTLIBS += -lcharset
endif
Със здраве
Дилян
[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]
begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Martin Fick @ 2012-02-10 2:08 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi1O10XeROv+sQRwAAVQ0PneMZTOaEfny-Oz2Sp+=z+aiA@mail.gmail.com>
>I found [1]. Is that sort of what you had in mind
yes
>That would be quite
>tricky. I have a group of some 60 projects, each with their own
>"target" directory which would have to be mounted on tmpfs. And the
>"target" directory is created by Maven, not by me. Not to mention that
>I shut down my computer at the end of the day. :-)
Sounds like a laptop? Hibernate?
>I think I would prefer a somewhat more persistent solution. I
>certainly have enough space for a very big swap partition. So the
>whole of ~/my-project would fit on tmpfs. I'm just not sure about
>making it persistent at the end of the day.
Link your .git dir to a persistent location.
Benchmark it first so you know how much hassle it may be worth. If it isn't worth it, xfs or brtfs will likely not be worth it either,
-Martin
Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
^ permalink raw reply
* [PATCH 1/2] ctype.c only wants git-compat-util.h
From: Namhyung Kim @ 2012-02-10 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The implementation of sane ctype macros only depends on symbols in
git-compat-util.h not cache.h
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
---
ctype.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ctype.c b/ctype.c
index b5d856f..af722f9 100644
--- a/ctype.c
+++ b/ctype.c
@@ -3,7 +3,7 @@
*
* No surprises, and works with signed and unsigned chars.
*/
-#include "cache.h"
+#include "git-compat-util.h"
enum {
S = GIT_SPACE,
--
1.7.9
^ permalink raw reply related
* [PATCH 2/2] ctype: implement islower/isupper macro
From: Namhyung Kim @ 2012-02-10 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1328840011-19028-1-git-send-email-namhyung.kim@lge.com>
The git-compat-util.h provides various ctype macros but lacks those two
(along with others). Add them.
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
---
git-compat-util.h | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 8f3972c..d3f8f17 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -463,6 +463,8 @@ static inline int has_extension(const char *filename, const char *ext)
#undef isdigit
#undef isalpha
#undef isalnum
+#undef islower
+#undef isupper
#undef tolower
#undef toupper
extern unsigned char sane_ctype[256];
@@ -478,6 +480,8 @@ extern unsigned char sane_ctype[256];
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
+#define islower(x) sane_iscase(x, 1)
+#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
@@ -491,6 +495,17 @@ static inline int sane_case(int x, int high)
return x;
}
+static inline int sane_iscase(int x, int lower)
+{
+ if (!sane_istest(x, GIT_ALPHA))
+ return 0;
+
+ if (lower)
+ return (x & 0x20) != 0;
+ else
+ return (x & 0x20) == 0;
+}
+
static inline int strtoul_ui(char const *s, int base, unsigned int *result)
{
unsigned long ul;
--
1.7.9
^ permalink raw reply related
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 2:13 UTC (permalink / raw)
To: Дилян Палаузов
Cc: git
In-Reply-To: <4F3472F4.4060605@aegee.org>
Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
> Hello,
>
> git 1.7.9 makes use of libcharset and /Makefile contains:
>
> ifdef HAVE_LIBCHARSET_H
> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> endif
> ...
> and the problem is, that libcharset is not used when linking. To
> solve this, please replace the above extract from /Makefile with
>
> ifdef HAVE_LIBCHARSET_H
> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> EXTLIBS += -lcharset
> endif
Thanks.
What platform is this? Is there a guarantee that any and all system that
use "#include <libcharset.h>" has to link with "-lcharset"?
What I am wondering is there are systems that need to include the header,
but locale_charset() does not live in /lib/libcharset.a, in which case we
cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox