[regression] Re: git-cat-file --batch reversion; cannot query filenames with spaces
Hi Joey, Joey Hess wrote[1]: > Commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac caused a reversion in > git-cat-file --batch. > > With an older version: > > joey@gnu:~/tmp/rrr>git cat-file --batch > :file name > e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 blob 0 > > With the new version: > > joey@wren:~/tmp/r>git cat-file --batch > :file name > :file missing > > This has broken git-annex's support for operating on files/directories > containing whitespace. I cannot see a way to query such a filename using > the new interface. Oh dear. Luckily you caught this before the final 1.8.4 release. I wonder if we should just revert c334b87b (cat-file: split --batch input lines on whitespace, 2013-07-11) for now. Thanks, Jonathan [1] http://bugs.debian.org/718517 -- 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: [PATCH v2] Provide some linguistic guidance for the documentation.
Junio C Hamano wrote: > Is that accurate? My impression has been: > > The documentation liberally mixes US and UK English (en_US/UK) > norms for spelling and grammar, which is somewhat unfortunate. > In an ideal world, it would have been better if it consistently > used only one and not the other, and we would have picked en_US. I'm not convinced that would be better, even in an ideal world. It's certainly useful to have a consistent spelling of each term to make searching with "grep" easier. But searches with "grep" do not work well with line breaks anyway, and search engines for larger collections of documents seem to know about the usual spelling variants (along with knowing about stemming, etc). Unless we are planning to provide a separate en_GB translation, it seems unfortunate to consistently have everything spelled in the natural way for one group of people and in an unnatural way for another, just in the name of having a convention. I am not sure it makes sense for the documentation to say "A huge disruptive patch of such-and-such specific kind of no immediate benefit is unwelcome". Isn't there some more general principle that implies that? Or the CodingGuidelines could simply say The documentation uses a mixture of U.S. and British English. My two cents, Jonathan -- 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
[PATCH v3] sha1_file: introduce close_one_pack() to close packs on fd pressure
When the number of open packs exceeds pack_max_fds, unuse_one_window()
is called repeatedly to attempt to release the least-recently-used
pack windows, which, as a side-effect, will also close a pack file
after closing its last open window. If a pack file has been opened,
but no windows have been allocated into it, it will never be selected
by unuse_one_window() and hence its file descriptor will not be
closed. When this happens, git may exceed the number of file
descriptors permitted by the system.
This latter situation can occur in show-ref or receive-pack during ref
advertisement. During ref advertisement, receive-pack will iterate
over every ref in the repository and advertise it to the client after
ensuring that the ref exists in the local repository. If the ref is
located inside a pack, then the pack is opened to ensure that it
exists, but since the object is not actually read from the pack, no
mmap windows are allocated. When the number of open packs exceeds
pack_max_fds, unuse_one_window() will not be able to find any windows to
free and will not be able to close any packs. Once the per-process
file descriptor limit is exceeded, receive-pack will produce a warning,
not an error, for each pack it cannot open, and will then most likely
fail with an error to spawn rev-list or index-pack like:
error: cannot create standard input pipe for rev-list: Too many open files
error: Could not run 'git rev-list'
This may also occur during upload-pack when refs are packed (in the
packed-refs file) and the number of packs that must be opened to
verify that these packed refs exist exceeds the file descriptor
limit. If the refs are loose, then upload-pack will read each ref
from the object database (if the object is in a pack, allocating one
or more mmap windows for it) in order to peel tags and advertise the
underlying object. But when the refs are packed and peeled,
upload-pack will use the peeled sha1 in the packed-refs file and
will not need to read from the pack files, so no mmap windows will
be allocated and just like with receive-pack, unuse_one_window()
will never select these opened packs to close.
When we have file descriptor pressure, we just need to find an open
pack to close. We can leave the existing mmap windows open. If
additional windows need to be mapped into the pack file, it will be
reopened when necessary. If the pack file has been rewritten in the
mean time, open_packed_git_1() should notice when it compares the file
size or the pack's sha1 checksum to what was previously read from the
pack index, and reject it.
Let's introduce a new function close_one_pack() designed specifically
for this purpose to search for and close the least-recently-used pack,
where LRU is defined as (in order of preference):
* pack with oldest mtime and no allocated mmap windows
* pack with the least-recently-used windows, i.e. the pack
with the oldest most-recently-used window, where none of
the windows are in use
* pack with the least-recently-used windows
Signed-off-by: Brandon Casey
---
Here's the version that leaves the mmap windows open after closing
the pack file descriptor.
-Brandon
sha1_file.c | 79 -
1 file changed, 78 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..263cf71 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -673,6 +673,83 @@ void close_pack_windows(struct packed_git *p)
}
}
+/*
+ * The LRU pack is the one with the oldest MRU window, preferring packs
+ * with no used windows, or the oldest mtime if it has no windows allocated.
+ */
+static void find_lru_pack(struct packed_git *p, struct packed_git **lru_p,
struct pack_window **mru_w, int *accept_windows_inuse)
+{
+ struct pack_window *w, *this_mru_w;
+ int has_windows_inuse = 0;
+
+ /*
+* Reject this pack if it has windows and the previously selected
+* one does not. If this pack does not have windows, reject
+* it if the pack file is newer than the previously selected one.
+*/
+ if (*lru_p && !*mru_w && (p->windows || p->mtime > (*lru_p)->mtime))
+ return;
+
+ for (w = this_mru_w = p->windows; w; w = w->next) {
+ /*
+* Reject this pack if any of its windows are in use,
+* but the previously selected pack did not have any
+* inuse windows. Otherwise, record that this pack
+* has windows in use.
+*/
+ if (w->inuse_cnt) {
+ if (*accept_windows_inuse)
+ has_windows_inuse = 1;
+ else
+ return;
+ }
+
+ if (w->last_used > this_mru_w->last_used)
+ this_mru_w = w;
+
+ /*
+* Reject this pack if it has windows that have been
+*
Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)
Am 01.08.2013 09:28, schrieb Jakub Narebski: > There is also TopGit, which is feature-branch management tools (which > seems like what you want, from what you written below). Indeed, thank you very much for pointing me to it. I have not read the whole documentation, but it sounds promising enough that I will try it out with some real patches I have flying around and need to combine and do further development on. Jens -- 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: [TIG][PATCH] Scroll diff with arrow keys in log view
On Thu, Aug 01, 2013 at 10:01:58PM -0400, Jonas Fonseca wrote: > On Wed, Jul 31, 2013 at 11:11 PM, Kumar Appaiah > wrote: > > This commit introduces the VIEW_NO_PARENT_NAV flag and adds it to the > > log view. This allows the scrolling commands to fall through from the > > pager to the diff when the diff is viewed in the log mode. > > Thanks, works like a charm. > > BTW, please remember to label tig related patches by adding '[TIG]' or > something similar in the subject so people on this list won't get > confused. Noted, and thanks! Kumar -- Kumar Appaiah -- 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: [TIG][PATCH] Scroll diff with arrow keys in log view
On Wed, Jul 31, 2013 at 11:11 PM, Kumar Appaiah wrote: > This commit introduces the VIEW_NO_PARENT_NAV flag and adds it to the > log view. This allows the scrolling commands to fall through from the > pager to the diff when the diff is viewed in the log mode. Thanks, works like a charm. BTW, please remember to label tig related patches by adding '[TIG]' or something similar in the subject so people on this list won't get confused. -- Jonas Fonseca -- 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: Difficulty adding a symbolic link, part 3
On Thu, Aug 1, 2013 at 10:00 PM, Dale R. Worley wrote:
>> From: Duy Nguyen
>
>> > Can someone give me advice on what this code *should* do?
>>
>> It does as the function name says: given cwd, a prefix (i.e. a
>> relative path with no ".." components) and a path relative to
>> cwd+prefix, convert 'path' to something relative to cwd. In the
>> simplest case, prepending the prefix to 'path' is enough. cwd is also
>> get_git_work_tree().
>>
>> I agree with you that this code should not resolve anything in the
>> components after 'cwd', after rebasing the path to 'cwd' (not just the
>> final component). Not sure how to do it correctly though because we do
>> need to resolve symlinks before cwd. Maybe a new variant of real_path
>> that stops at 'cwd'?
>>
>> We may also have problems with resolve symlinks before cwd when 'path'
>> is relative, as normalize_path_copy() does not resolve symlinks. We
>> just found out emacs has this bug [1] but did not realize we also have
>> one :-P.
>
> Thanks for the detailed information. It seems to me that the minimum
> needed change is that the handling of relative and absolute paths
> should be made consistent.
Agreed.
>
>> [1] http://thread.gmane.org/gmane.comp.version-control.git/231268
>
> That problem isn't so much a matter of not resolving symlinks but
> rather the question of what ".." means. In the case shown in that
> message, the current directory *is* {topdir}/z/b, but it was entered
> with "cd {topdir}/b" -- and the shell records the latter as the value
> of $PWD. (Actually, the bash shell can handle symbolic-linked
> directories *either* way, depending on whether it is given the "-P"
> option.)
>
> When Emacs is given the file name "../a/file", does the ".." mean to
> go up one directory *textually* in the pathspec based on $PWD
>
> "{topdir}/b/../a/file" -> "{topdir}/a/file" (which does not exist)
>
> or according to the directory linkage on the disk (where the ".."
> entry in the current directory goes to the directory named {topdir}/z,
> which does contain a file a/file. It looks like Emacs uses the first
> method.
>
> The decision of which implementation to use depends on the semantics
> you *want*. As I noted, bash allows the user to choose *either*
> interpretation, which shows that both semantics are considered valid
> (by some people).
We pass paths around, the semantics must be one that others expect,
not what we want. For one, the kernel seems to resolve symlinks first,
then "..". We use chdir() and getcwd() provided by the kernel. We need
to agree with it on ".." semantics.
--
Duy
--
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
URGENT RESPONSE!!
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels...@yahoo.com.hk. Have a pleasant day. George Daniels -- 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
URGENT RESPONSE!!
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels...@yahoo.com.hk. Have a pleasant day. George Daniels -- 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
What's in "What's cooking"
Here is a note to explain various sections and what the readers on
this list are expected to read from them in the periodic "What's
cooking" summary. This probably should be integrated in the periodic
"A note from the maintainer" posting eventually.
The first part is mostly a boilerplate message, but the second
paragraph of it often explains where in the development cycle we are.
The latest one (issue #1 of this month) said:
The first release candidate v1.8.4-rc1 has been tagged; only
regression fixes and l10n updates from now on.
The preamble is followed by various sections, each listing topics in
different "doneness".
Each topic looks like this:
* nd/sq-quote-buf (2013-07-30) 3 commits
(merged to 'next' on 2013-08-01 at dc7934a)
+ quote: remove sq_quote_print()
+ tar-tree: remove dependency on sq_quote_print()
+ for-each-ref, quote: convert *_quote_print -> *_quote_buf
Code simplification as a preparatory step to something larger.
Will cook in 'next'.
A line that begins with a '*' has the name of a topic, the date of the
last activity on the topic and the number of changes in the topic.
Then each commit on the topic is listed with prefix ("+", "-" or ".").
The ones with "+" are already on 'next', and the dates when they were
merged to 'next' also appear on this list. This will give readers the
rough idea of how long the topic has been cooking in 'next' (the
branch active bug hunters and early adopters are expected to be
running) to measure the "doneness".
The list of commits on the topic is often followed by a few lines of
free-form text to summarize what the topic aims to achieve. This often
goes literally to the draft release notes when the topic graduates to
'master'. Also I annotate my short-term plan for the topic ("Will
cook in 'next' in the above example); it is very much appreciated if
readers raise timely objections to this plan (e.g. "Don't merge it
yet, it is broken --- see that discussion thread").
The [New topics] section lists topics that were not in my tree when
the previous issue of "What's cooking" was sent.
The [Graduated to "master"] section lists topics that have been
merged to 'master' since the previous issue. Even if you are not an
active bug hunter, please exercise the features/fixes these topics
brings to the system, as breakages or regressions caused by these
will appear in the next release if they are not noticed and fixed.
The [Stalled] section lists topics whose discussion has stalled, or
re-rolled patches have not been seen for a while after the topic
received review comments. This section is listed here so that people
interested in the topics in it can help the owners of them to move
things forward.
The [Cooking] section lists the remainder of the topics. They are
making normal progress and are no cause for worries in general.
Those whose commits are all in "next" are often just simmering to
give time to active bug hunters find unexpected problem in them.
those whose commits are not in "next" yet are still going through
review/revise cycle until they become ready.
--
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
What's cooking in git.git (Aug 2013, #01; Thu, 1)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The first release candidate v1.8.4-rc1 has been tagged; only regression fixes and l10n updates from now on. 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"] * jc/rm-submodule-error-message (2013-07-25) 1 commit + builtin/rm.c: consolidate error reporting for removing submodules * jx/clean-interactive (2013-07-24) 2 commits (merged to 'next' on 2013-07-30 at b7fd474) + git-clean: implement partial matching for selection (merged to 'next' on 2013-07-24 at 1e63bb9) + Documentation/git-clean: fix description for range * lf/echo-n-is-not-portable (2013-07-29) 1 commit (merged to 'next' on 2013-07-30 at e223ceb) + Avoid using `echo -n` anywhere * ma/hg-to-git (2013-07-23) 1 commit (merged to 'next' on 2013-07-30 at 1dddc06) + hg-to-git: --allow-empty-message in git commit * ms/subtree-install-fix (2013-07-30) 1 commit + contrib/subtree: Fix make install target * ob/typofixes (2013-07-29) 1 commit (merged to 'next' on 2013-07-30 at ec2c897) + many small typofixes -- [New Topics] * mb/docs-favor-en-us (2013-08-01) 1 commit - Provide some linguistic guidance for the documentation. Will merge to and cook in 'next'. * jc/parseopt-command-modes (2013-07-30) 2 commits - tag: use OPT_CMDMODE - parse-options: add OPT_CMDMODE() Many commands use --dashed-option as a operation mode selector (e.g. "git tag --delete") that the user can use at most one (e.g. "git tag --delete --verify" is a nonsense) and you cannot negate (e.g. "git tag --no-delete" is a nonsense). Make it easier for users of parse_options() to enforce these restrictions. -- [Stalled] * tf/gitweb-ss-tweak (2013-07-15) 4 commits - gitweb: make search help link less ugly - gitweb: omit the repository owner when it is unset - gitweb: vertically centre contents of page footer - gitweb: ensure OPML text fits inside its box Comments? * rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits - ### DONTMERGE: needs better explanation on what config they need - pack-refs.c: Add missing call to git_config() - show-ref.c: Add missing call to git_config() The changes themselves are probably good, but it is unclear what basic setting needs to be read for which exact operation. Waiting for clarification. $gmane/228294 * jh/shorten-refname (2013-05-07) 4 commits - t1514: refname shortening is done after dereferencing symbolic refs - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin - t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD" - t1514: Add tests of shortening refnames in strict/loose mode When remotes/origin/HEAD is not a symbolic ref, "rev-parse --abbrev-ref remotes/origin/HEAD" ought to show "origin", not "origin/HEAD", which is fixed with this series (if it is a symbolic ref that points at remotes/origin/something, then it should show "origin/something" and it already does). Expecting a reroll, as an early part of a larger series. $gmane/225137 * jk/list-objects-sans-blobs (2013-06-06) 4 commits . archive: ignore blob objects when checking reachability . list-objects: optimize "revs->blob_objects = 0" case . upload-archive: restrict remote objects with reachability check . clear parsed flag when we free tree buffers Attempt to allow "archive --remote=$there $arbitrary_sha1" while keeping the reachability safety. Seems to break some tests in a trivial and obvious way. * mg/more-textconv (2013-05-10) 7 commits - grep: honor --textconv for the case rev:path - grep: allow to use textconv filters - t7008: demonstrate behavior of grep with textconv - cat-file: do not die on --textconv without textconv filters - show: honor --textconv for blobs - diff_opt: track whether flags have been set explicitly - t4030: demonstrate behavior of show with textconv Make "git grep" and "git show" pay attention to --textconv when dealing with blob objects. I thought this was pretty well designed and executed, but it seems there are some doubts on the list; kicked back to 'pu'. * jc/format-patch (2013-04-22) 2 commits - format-patch: --inline-single - format-patch: rename "no_inline" field A new option to send a single patch to the standard output to be appended at the bottom of a message. I personally have no need for this, but it was easy enough to cobble together. Tests, docs and stripping out more MIMEy stuff are left as exercises to interested parties. Not ready for inclusion. Will discard unless we hear from anybody who is interested in tying its loose ends. * jk/g
[ANNOUNCE] Git v1.8.4-rc1
A release candidate for Git v1.8.4-rc1 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ab0bb0ed36dd9c0d6425f64021a9c7d7311a2b5c git-1.8.4.rc1.tar.gz 2d3f1f07ed3bde56fac5e823be7d71bf5bf0f743 git-htmldocs-1.8.4.rc1.tar.gz c21f40d9cd2bbf7c28be4d32a1ae1ad98c198d96 git-manpages-1.8.4.rc1.tar.gz The following public repositories all have a copy of the v1.8.4-rc1 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set the variable to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" (and "git add -A") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add "HEAD" to the list of candidate refs to be filtered by the usual rules (e.g. "--heads" that only show refs under refs/heads). The meaning of the option has been changed to always show "HEAD" regardless of what filtering will be app
Re: What's cooking in git.git (Jul 2013, #09; Mon, 29)
Ramsay Jones writes: > Junio C Hamano wrote: >> Ramsay Jones writes: >> I am personally in favor of this simpler solution. Comments? >>> >>> I had expected this to me marked for 'master'. >>> >>> Has this simply been overlooked, or do you have reservations about >>> applying this patch? >> >> I am just being careful and do want to keep it cooking in 'next' >> during the feature freeze. The more users work with 'next' (not >> "work *on* 'next'"), the more confidence we would be with, and >> hopefully this can be one of the topis that graduate early after >> the 1.8.4 release. > > Hmm, this patch is a bug-fix for a bug that (currently) will be > _introduced_ by v1.8.4. OK, let's merge it then. Thanks for being patient with me. > Do you want me to try and find a different bug-fix for v1.8.4? > (Although that would most likely be more risky than simply taking > this patch! ;-) ). Absolutely not, and I 100% agree with you. -- 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: What's cooking in git.git (Jul 2013, #09; Mon, 29)
Junio C Hamano wrote: > Ramsay Jones writes: > >>> I am personally in favor of this simpler solution. Comments? >> >> I had expected this to me marked for 'master'. >> >> Has this simply been overlooked, or do you have reservations about >> applying this patch? > > I am just being careful and do want to keep it cooking in 'next' > during the feature freeze. The more users work with 'next' (not > "work *on* 'next'"), the more confidence we would be with, and > hopefully this can be one of the topis that graduate early after > the 1.8.4 release. Hmm, this patch is a bug-fix for a bug that (currently) will be _introduced_ by v1.8.4. Do you want me to try and find a different bug-fix for v1.8.4? (Although that would most likely be more risky than simply taking this patch! ;-) ). ATB, Ramsay Jones -- 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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
On Thu, Aug 1, 2013 at 1:02 PM, Junio C Hamano wrote: > Brandon Casey writes: > >> On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano wrote: >>> That makes me feel somewhat uneasy. Yes, you can open/mmap/close >>> and hold onto the contents of a file still mapped in-core, and it >>> may not count as "open filedescriptor", but do OSes allow infinite >>> such mmapped regions to us? We do keep track of number of open >>> windows, but is there a way for us to learn how close we are to the >>> limit? >> >> Not that I know of, but xmmap() does already try to unmap existing >> windows when mmap() fails, and then retries the mmap. It calls >> release_pack_memory() which calls unuse_one_window(). mmap returns >> ENOMEM when either there is no available memory or if the limit of >> mmap mappings has been exceeded. > > OK, so if there were such an OS limit, the unuse_one_window() will > hopefully reduce the number of open windows and as a side effect we > may go below that limit. > > What I was worried about was if there was a limit on the number of > files we have windows into (i.e. having one window each in N files, > with fds all closed, somehow costs more than having N window in one > file with the fd closed). Ah, yeah, I've never heard of that type of limit and I do not know if there is one. If there is such a limit, like you said unuse_one_window() will _hopefully_ release enough windows to reduce the number of packs we have windows into, but it is certainly not guaranteed. > We currently have knobs for total number > of windows and number of open fds consumed for packs, and the latter > indirectly controls the number of active packfiles we have windows > into. Your proposed change will essentially make the number of > active packfiles unlimited by any of our knobs, and that was where > my uneasiness was coming from. Yes and no. The limit on the number of open fds used for packs only indirectly controls the number of active packfiles we have windows into for the packs that are larger than packedGitWindowSize. For pack files smaller than packedGitWindowSize, the number was unlimited too since we close the file descriptor if the whole pack fits within one window. -Brandon -- 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
URGENT RESPONSE!!
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels...@yahoo.com.hk. Have a pleasant day. George Daniels -- 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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
Brandon Casey writes: > On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano wrote: >> That makes me feel somewhat uneasy. Yes, you can open/mmap/close >> and hold onto the contents of a file still mapped in-core, and it >> may not count as "open filedescriptor", but do OSes allow infinite >> such mmapped regions to us? We do keep track of number of open >> windows, but is there a way for us to learn how close we are to the >> limit? > > Not that I know of, but xmmap() does already try to unmap existing > windows when mmap() fails, and then retries the mmap. It calls > release_pack_memory() which calls unuse_one_window(). mmap returns > ENOMEM when either there is no available memory or if the limit of > mmap mappings has been exceeded. OK, so if there were such an OS limit, the unuse_one_window() will hopefully reduce the number of open windows and as a side effect we may go below that limit. What I was worried about was if there was a limit on the number of files we have windows into (i.e. having one window each in N files, with fds all closed, somehow costs more than having N window in one file with the fd closed). We currently have knobs for total number of windows and number of open fds consumed for packs, and the latter indirectly controls the number of active packfiles we have windows into. Your proposed change will essentially make the number of active packfiles unlimited by any of our knobs, and that was where my uneasiness was coming from. -- 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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
On Thu, Aug 1, 2013 at 12:16 PM, Brandon Casey wrote: > On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano wrote: >> Brandon Casey writes: >> >>> I've been looking closer at uses of p->windows everywhere, and it >>> seems that we always open_packed_git() before we try to create new >>> windows. There doesn't seem to be any reason that we can't continue >>> to use the existing open windows even after closing the pack file. >>> ... >>> If we don't need to close_pack_windows(), find_lru_pack() doesn't >>> strictly need to reject packs that have windows in use. >> >> That makes me feel somewhat uneasy. Yes, you can open/mmap/close >> and hold onto the contents of a file still mapped in-core, and it >> may not count as "open filedescriptor", but do OSes allow infinite >> such mmapped regions to us? We do keep track of number of open >> windows, but is there a way for us to learn how close we are to the >> limit? > > Not that I know of, but xmmap() does already try to unmap existing > windows when mmap() fails, and then retries the mmap. It calls > release_pack_memory() which calls unuse_one_window(). mmap returns > ENOMEM when either there is no available memory or if the limit of > mmap mappings has been exceeded. > > So, I think we'll be ok. It's the same situation we'd be in if there > were many large packs (but fewer than pack_max_fds) and a small > packedGitWindowSize, requiring many mmap windows. We'd try to map an > additional segment, fail, release some unused segments, and retry. Also, it's the same situation we'd be in if there were many small packs that were smaller than packedGitWindowSize. We'd mmap the entire pack file into memory and then close the file descriptor, allowing us to have many more pack files mapped into memory than pack_max_fds would allow us to have open. With enough small packs, we'd eventually reach the mmap limit and xmmap would try to release some mappings. -Brandon -- 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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano wrote: > Brandon Casey writes: > >> I've been looking closer at uses of p->windows everywhere, and it >> seems that we always open_packed_git() before we try to create new >> windows. There doesn't seem to be any reason that we can't continue >> to use the existing open windows even after closing the pack file. >> ... >> If we don't need to close_pack_windows(), find_lru_pack() doesn't >> strictly need to reject packs that have windows in use. > > That makes me feel somewhat uneasy. Yes, you can open/mmap/close > and hold onto the contents of a file still mapped in-core, and it > may not count as "open filedescriptor", but do OSes allow infinite > such mmapped regions to us? We do keep track of number of open > windows, but is there a way for us to learn how close we are to the > limit? Not that I know of, but xmmap() does already try to unmap existing windows when mmap() fails, and then retries the mmap. It calls release_pack_memory() which calls unuse_one_window(). mmap returns ENOMEM when either there is no available memory or if the limit of mmap mappings has been exceeded. So, I think we'll be ok. It's the same situation we'd be in if there were many large packs (but fewer than pack_max_fds) and a small packedGitWindowSize, requiring many mmap windows. We'd try to map an additional segment, fail, release some unused segments, and retry. The memory usage of all mmap segments would still be bounded by packedGitLimit. It's just that now, when we're only under file descriptor pressure, we won't close the mmap windows unnecessarily when they may be needed again. -Brandon -- 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
[PATCH v3] Provide some linguistic guidance for the documentation.
This will hopefully avoid questions over which spelling and grammar should
be used. Translators are of course free to create localizations for
specific English dialects.
Signed-off-by: Marc Branchaud
---
On 13-08-01 02:21 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> + The documentation generally follows US English (en_US) norms for spelling
>> + and grammar, although most spelling variations are tolerated. Just avoid
>> + mixing styles when updating existing text. If you wish to correct the
>> + English of some of the existing documentation, please see the
>> documentation-
>> + related advice in the Documentation/SubmittingPatches file.
>
> Is that accurate? My impression has been:
>
> The documentation liberally mixes US and UK English (en_US/UK)
> norms for spelling and grammar, which is somewhat unfortunate.
> In an ideal world, it would have been better if it consistently
> used only one and not the other, and we would have picked en_US.
>
> A huge patch that touches the files all over the place only to
> correct the inconsistency is not welcome, though. Potential
> clashes with other changes that can result from such a patch is
> simply not worth it. What we would want is to gradually convert
> them, with small and easily digestable patches, as a side effect
> of doing some other _real_ work in the vicinity (e.g. rewriting
> a paragraph to clarify, while turning en_UK spelling to en_US).
I was focused more on just describing what the documentation should be rather
than what it is. I don't feel strongly about it & I think your phrasing is
fine. I do think the topic needs to be in both CodingGuidelines and
SubmittingPatches. How about this?
(The SubmittingPatches change also switches "I am " to "we are" in the
following paragraph, because I found the jump a bit too jarring.)
M.
Documentation/CodingGuidelines | 8
Documentation/SubmittingPatches | 14 +-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 559d5f9..8acf557 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -242,6 +242,14 @@ Writing Documentation:
processed into HTML and manpages (e.g. git.html and git.1 in the
same directory).
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US.
+ (If you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file.)
+
Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
conventions. A few commented examples follow to provide reference
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d0a4733..b3477ba 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -65,7 +65,19 @@ feature does not trigger when it shouldn't. Also make sure
that the
test suite passes after your commit. Do not forget to update the
documentation to describe the updated behaviour.
-Oh, another thing. I am picky about whitespaces. Make sure your
+Speaking of the documentation, it is currently a liberal mixture of US
+and UK English norms for spelling and grammar. A huge patch that
+touches the files all over the place only to correct the inconsistency
+is not welcome, though. Potential clashes with other changes that can
+result from such a patch are simply not worth it. We prefer to
+gradually reconcile the inconsistencies (in favor of US English), with
+small and easily digestible patches, as a side effect of doing some
+other real work in the vicinity (e.g. rewriting a paragraph for clarity,
+while turning en_UK spelling to en_US). Obvious typographical fixes are
+also welcome ("teh -> "the"), preferably submitted as independent patches
+separate from other documentation changes.
+
+Oh, another thing. We are picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
--
1.8.3.1
--
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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
Brandon Casey writes: > I've been looking closer at uses of p->windows everywhere, and it > seems that we always open_packed_git() before we try to create new > windows. There doesn't seem to be any reason that we can't continue > to use the existing open windows even after closing the pack file. > ... > If we don't need to close_pack_windows(), find_lru_pack() doesn't > strictly need to reject packs that have windows in use. That makes me feel somewhat uneasy. Yes, you can open/mmap/close and hold onto the contents of a file still mapped in-core, and it may not count as "open filedescriptor", but do OSes allow infinite such mmapped regions to us? We do keep track of number of open windows, but is there a way for us to learn how close we are to the limit? -- 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: [PATCH v2] Provide some linguistic guidance for the documentation.
Marc Branchaud writes: > + The documentation generally follows US English (en_US) norms for spelling > + and grammar, although most spelling variations are tolerated. Just avoid > + mixing styles when updating existing text. If you wish to correct the > + English of some of the existing documentation, please see the documentation- > + related advice in the Documentation/SubmittingPatches file. Is that accurate? My impression has been: The documentation liberally mixes US and UK English (en_US/UK) norms for spelling and grammar, which is somewhat unfortunate. In an ideal world, it would have been better if it consistently used only one and not the other, and we would have picked en_US. A huge patch that touches the files all over the place only to correct the inconsistency is not welcome, though. Potential clashes with other changes that can result from such a patch is simply not worth it. What we would want is to gradually convert them, with small and easily digestable patches, as a side effect of doing some other _real_ work in the vicinity (e.g. rewriting a paragraph to clarify, while turning en_UK spelling to en_US). -- 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
[PATCH v3 7/6] t5540/5541: smart-http does not support "--force-with-lease"
The push() method in remote-curl.c is not told and does not pass the
necessary information to underlying send-pack, so this extension
does not yet work. Leave a note in the test suite.
Signed-off-by: Junio C Hamano
---
* This is primarily to give a target for other people to shoot at;
patches to allow us to flip this expect_failure to expect_success
are very much welcomed ;-)
t/lib-httpd.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index 895b925..e2eca1f 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -167,6 +167,22 @@ test_http_push_nonff() {
test_expect_success 'non-fast-forward push shows help message' '
test_i18ngrep "Updates were rejected because" output
'
+
+ test_expect_failure 'force with lease aka cas' '
+ HEAD=$( cd "$REMOTE_REPO" && git rev-parse --verify HEAD ) &&
+ test_when_finished '\''
+ (cd "$REMOTE_REPO" && git update-ref HEAD "$HEAD")
+ '\'' &&
+ (
+ cd "$LOCAL_REPO" &&
+ git push -v --force-with-lease=$BRANCH:$HEAD origin
+ ) &&
+ git rev-parse --verify "$BRANCH" >expect &&
+ (
+ cd "$REMOTE_REPO" && git rev-parse --verify HEAD
+ ) >actual &&
+ test_cmp expect actual
+ '
}
setup_askpass_helper() {
--
1.8.4-rc0-154-gc668397
--
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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
On Thu, Aug 1, 2013 at 10:12 AM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> If the refs are loose, then upload-pack will read each ref from the
>> pack (allocating one or more mmap windows) so it can peel tags and
>> advertise the underlying object. If the refs are packed and peeled,
>> then upload-pack will use the peeled sha1 in the packed-refs file and
>> will not need to read from the pack files, so no mmap windows will be
>> allocated and just like with receive-pack, unuse_one_window() will
>
> Even though what it says is not incorrect, the phrasing around here,
> especially "so it can", confused me in my first reading. It reads
> objects "in order to" peel and advertise (and as a side-effect it
> can lead to windows into packs that eventually help relieaving the
> fd pressure), but a quick scan led me to misread it as "so it can do
> peel and advertise just fine", which misses the point, because it is
> not like we are having trouble peeling and advertising.
>
> Also, the objects at the tips of refs and the objects they point at
> may be loose objects, which is very likely for branch tips. The fd
> pressure will not be relieved in such a case even if these refs were
> packed.
>
> I've tentatively reworded the above section like so:
>
> ... If the refs are loose, then upload-pack will read each ref
> from the object database (if the object is in a pack, allocating
> one or more mmap windows for it) in order to peel tags and
> advertise the underlying object. But when the refs are packed
> and peeled, upload-pack will use the peeled sha1 in the
> packed-refs file and will not need to read from the pack files,
> so no mmap windows will be allocated ...
Thanks.
>> +static int close_one_pack(void)
>> +{
>> + struct packed_git *p, *lru_p = NULL;
>> + struct pack_window *mru_w = NULL;
>> +
>> + for (p = packed_git; p; p = p->next) {
>> + if (p->pack_fd == -1)
>> + continue;
>> + find_lru_pack(p, &lru_p, &mru_w);
>> + }
>> +
>> + if (lru_p) {
>> + close_pack_windows(lru_p);
>> + close(lru_p->pack_fd);
>> + pack_open_fds--;
>> + lru_p->pack_fd = -1;
>> + if (lru_p == last_found_pack)
>> + last_found_pack = NULL;
>> + return 1;
>> + }
>> +
>> + return 0;
>> +}
>
> OK, so in this codepath where we know we are under fd pressure, we
> find the pack that is least recently used that can be closed, and
> use close_pack_windows() to reclaim all of its open windows (if
> any),
I've been looking closer at uses of p->windows everywhere, and it
seems that we always open_packed_git() before we try to create new
windows. There doesn't seem to be any reason that we can't continue
to use the existing open windows even after closing the pack file. We
obviously do this when the window spans the entire file.
So, I'm thinking we can drop the close_pack_windows() and refrain from
resetting last_found_pack, so the last block will become simply:
+ if (lru_p) {
+ close(lru_p->pack_fd);
+ pack_open_fds--;
+ lru_p->pack_fd = -1;
+ return 1;
+ }
If the pack file needs to be reopened later and it has been rewritten
in the mean time, open_packed_git_1() should notice when it compares
either the file size or the pack's sha1 checksum to what was
previously read from the pack index. So this seems safe.
If we don't need to close_pack_windows(), find_lru_pack() doesn't
strictly need to reject packs that have windows in use. I think the
algorithm can be tweaked to prefer to close packs that have no windows
in use, but still select them for closing if not. The order of
preference would look like:
1. pack with no open windows, oldest mtime
2. pack with oldest MRU window but none in use
3. pack with oldest MRU window
> which takes care of the accounting for pack_mapped and
> pack_open_windows, but we need to do the pack_open_fds accounting
> here ourselves. Makes sense to me.
>
> Thanks.
Sorry about the additional reroll. I'll make the above changes and resubmit.
-Brandon
--
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: [PATCH v6 6/6] config: "git config --get-urlmatch" parses section..key
On Thu, Aug 01, 2013 at 10:25:13AM -0700, Junio C Hamano wrote:
> > diff --git a/builtin/config.c b/builtin/config.c
> > index c35c5be..9328a90 100644
> > --- a/builtin/config.c
> > +++ b/builtin/config.c
> > @@ -589,7 +589,9 @@ int cmd_config(int argc, const char **argv, const char
> > *prefix)
> > }
> > else if (actions == ACTION_GET_URLMATCH) {
> > check_argc(argc, 2, 2);
> > - return get_urlmatch(argv[0], argv[1]);
> > + if (git_config_parse_key(argv[0], &key, NULL))
> > + return CONFIG_INVALID_KEY;
> > + return get_urlmatch(key, argv[1]);
> > }
> > else if (actions == ACTION_UNSET) {
> > check_argc(argc, 1, 2);
>
> If we drop the "list every key in section.*" mode, the above should
> be sufficient, I think.
Ah, right, forgot about that again.
> I do not know how useful it would be to be for a scripted Porcelain
> to be able to ask
>
> $ git config --get-urlmatch http https://weak.example.com/path/to/git.git
>
> and get all the "http.*" variables that will apply to the given URL.
I do not think it is all that useful, but I don't think it hurts too
much to have it (and it would be a hard operation to do otherwise). The
implementation you posted that downcases as we memdup the key makes
sense to me.
The key thing is that it is done only by git-config, as we would not
want to pay the allocation cost for every config key we look at during a
git_config() run, but I think your implementation is fine in that
respect.
-Peff
--
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: [PATCH v6 6/6] config: "git config --get-urlmatch" parses section..key
Jeff King writes:
> That being said, git-config _should_ be lowercasing to match the normal
> --get code path. I think the fix (squashable on top of 6/6 + my earlier
> patch) is just:
>
> diff --git a/builtin/config.c b/builtin/config.c
> index c35c5be..9328a90 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -589,7 +589,9 @@ int cmd_config(int argc, const char **argv, const char
> *prefix)
> }
> else if (actions == ACTION_GET_URLMATCH) {
> check_argc(argc, 2, 2);
> - return get_urlmatch(argv[0], argv[1]);
> + if (git_config_parse_key(argv[0], &key, NULL))
> + return CONFIG_INVALID_KEY;
> + return get_urlmatch(key, argv[1]);
> }
> else if (actions == ACTION_UNSET) {
> check_argc(argc, 1, 2);
If we drop the "list every key in section.*" mode, the above should
be sufficient, I think.
I do not know how useful it would be to be for a scripted Porcelain
to be able to ask
$ git config --get-urlmatch http https://weak.example.com/path/to/git.git
and get all the "http.*" variables that will apply to the given URL.
--
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: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
Brandon Casey writes:
> If the refs are loose, then upload-pack will read each ref from the
> pack (allocating one or more mmap windows) so it can peel tags and
> advertise the underlying object. If the refs are packed and peeled,
> then upload-pack will use the peeled sha1 in the packed-refs file and
> will not need to read from the pack files, so no mmap windows will be
> allocated and just like with receive-pack, unuse_one_window() will
Even though what it says is not incorrect, the phrasing around here,
especially "so it can", confused me in my first reading. It reads
objects "in order to" peel and advertise (and as a side-effect it
can lead to windows into packs that eventually help relieaving the
fd pressure), but a quick scan led me to misread it as "so it can do
peel and advertise just fine", which misses the point, because it is
not like we are having trouble peeling and advertising.
Also, the objects at the tips of refs and the objects they point at
may be loose objects, which is very likely for branch tips. The fd
pressure will not be relieved in such a case even if these refs were
packed.
I've tentatively reworded the above section like so:
... If the refs are loose, then upload-pack will read each ref
from the object database (if the object is in a pack, allocating
one or more mmap windows for it) in order to peel tags and
advertise the underlying object. But when the refs are packed
and peeled, upload-pack will use the peeled sha1 in the
packed-refs file and will not need to read from the pack files,
so no mmap windows will be allocated ...
> +static int close_one_pack(void)
> +{
> + struct packed_git *p, *lru_p = NULL;
> + struct pack_window *mru_w = NULL;
> +
> + for (p = packed_git; p; p = p->next) {
> + if (p->pack_fd == -1)
> + continue;
> + find_lru_pack(p, &lru_p, &mru_w);
> + }
> +
> + if (lru_p) {
> + close_pack_windows(lru_p);
> + close(lru_p->pack_fd);
> + pack_open_fds--;
> + lru_p->pack_fd = -1;
> + if (lru_p == last_found_pack)
> + last_found_pack = NULL;
> + return 1;
> + }
> +
> + return 0;
> +}
OK, so in this codepath where we know we are under fd pressure, we
find the pack that is least recently used that can be closed, and
use close_pack_windows() to reclaim all of its open windows (if
any), which takes care of the accounting for pack_mapped and
pack_open_windows, but we need to do the pack_open_fds accounting
here ourselves. Makes sense to me.
Thanks.
> void unuse_pack(struct pack_window **w_cursor)
> {
> struct pack_window *w = *w_cursor;
> @@ -777,7 +838,7 @@ static int open_packed_git_1(struct packed_git *p)
> pack_max_fds = 1;
> }
>
> - while (pack_max_fds <= pack_open_fds && unuse_one_window(NULL, -1))
> + while (pack_max_fds <= pack_open_fds && close_one_pack())
> ; /* nothing */
>
> p->pack_fd = git_open_noatime(p->pack_name);
--
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: [PATCH v2] Provide some linguistic guidance for the documentation.
On 13-08-01 11:10 AM, Marc Branchaud wrote: > This will hopefully avoid questions over which spelling and grammar should > be used. Translators are of course free to create localizations for other Oops, I should have removed the word "other" here. M. > specific English dialects. > > Signed-off-by: Marc Branchaud -- 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
[PATCH v2] Provide some linguistic guidance for the documentation.
This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other specific English dialects. Signed-off-by: Marc Branchaud --- A little less stringent now. Documentation/CodingGuidelines | 6 ++ Documentation/SubmittingPatches | 10 ++ 2 files changed, 16 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 559d5f9..fc397f3 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -242,6 +242,12 @@ Writing Documentation: processed into HTML and manpages (e.g. git.html and git.1 in the same directory). + The documentation generally follows US English (en_US) norms for spelling + and grammar, although most spelling variations are tolerated. Just avoid + mixing styles when updating existing text. If you wish to correct the + English of some of the existing documentation, please see the documentation- + related advice in the Documentation/SubmittingPatches file. + Every user-visible change should be reflected in the documentation. The same general rule as for code applies -- imitate the existing conventions. A few commented examples follow to provide reference diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index d0a4733..998e407 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -65,6 +65,16 @@ feature does not trigger when it shouldn't. Also make sure that the test suite passes after your commit. Do not forget to update the documentation to describe the updated behaviour. +Speaking of the documentation, if you are attempting to correct typographical +or grammatical errors use one patch for indisputably correct changes (e.g. +"teh" -> "the") and put subjective/stylistic changes in a separate patch. +This helps to streamline reviews of your patches. Also, although the +documentation is mainly written in US English, most non-US spelling variants +are acceptable. Patches that change one common spelling to another (such as +changing "behaviour" to "behavior") are generally not helpful, as +oftentimes a few months later some generous soul will want to change the +spelling the other way. + Oh, another thing. I am picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped in templates/hooks--pre-commit. To help ensure this does not happen, -- 1.8.3.1 -- 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: Difficulty adding a symbolic link, part 3
> From: Duy Nguyen
> > Can someone give me advice on what this code *should* do?
>
> It does as the function name says: given cwd, a prefix (i.e. a
> relative path with no ".." components) and a path relative to
> cwd+prefix, convert 'path' to something relative to cwd. In the
> simplest case, prepending the prefix to 'path' is enough. cwd is also
> get_git_work_tree().
>
> I agree with you that this code should not resolve anything in the
> components after 'cwd', after rebasing the path to 'cwd' (not just the
> final component). Not sure how to do it correctly though because we do
> need to resolve symlinks before cwd. Maybe a new variant of real_path
> that stops at 'cwd'?
>
> We may also have problems with resolve symlinks before cwd when 'path'
> is relative, as normalize_path_copy() does not resolve symlinks. We
> just found out emacs has this bug [1] but did not realize we also have
> one :-P.
Thanks for the detailed information. It seems to me that the minimum
needed change is that the handling of relative and absolute paths
should be made consistent.
> [1] http://thread.gmane.org/gmane.comp.version-control.git/231268
That problem isn't so much a matter of not resolving symlinks but
rather the question of what ".." means. In the case shown in that
message, the current directory *is* {topdir}/z/b, but it was entered
with "cd {topdir}/b" -- and the shell records the latter as the value
of $PWD. (Actually, the bash shell can handle symbolic-linked
directories *either* way, depending on whether it is given the "-P"
option.)
When Emacs is given the file name "../a/file", does the ".." mean to
go up one directory *textually* in the pathspec based on $PWD
"{topdir}/b/../a/file" -> "{topdir}/a/file" (which does not exist)
or according to the directory linkage on the disk (where the ".."
entry in the current directory goes to the directory named {topdir}/z,
which does contain a file a/file. It looks like Emacs uses the first
method.
The decision of which implementation to use depends on the semantics
you *want*. As I noted, bash allows the user to choose *either*
interpretation, which shows that both semantics are considered valid
(by some people).
Dale
--
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: Difficulty adding a symbolic link, part 3
> From: Duy Nguyen > > With the above change, the test suite runs with zero failures, so it > > doesn't affect any common Git usage. > > It means the test suite is incomplete. As you can see, the commit > introducing this change does not come with a test case to catch people > changing this. Who should be blamed for omitting the test? > > Can someone give me advice on what this code *should* do? > > It does as the function name says: given cwd, a prefix (i.e. a > relative path with no ".." components) and a path relative to > cwd+prefix, convert 'path' to something relative to cwd. In the > simplest case, prepending the prefix to 'path' is enough. cwd is also > get_git_work_tree(). But as you can see, the exact behavior that the function is intended to exhibit regarding symlinks is not clear from the function name; there should have been a real explanation in the comment above the function. Dale -- 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: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)
Jens Müller tessarakt.de> writes: > > Hi all! > > I mainly use Git for version control, but have also tried out Mercurial. > While I don't really like Mercurial in general, the idea of maintaining > clearly separated patches with Mercurial Queues (MQ) is quite appealing. > Therefore, I am looking for something similar (but easier to use, more > "gitty" and maybe even more powerful) in Git. On Git Homepage and on Git Wiki you can find a (partial) list of Git tools. Among those there are patch-management interface tools, such as Guilt (formerly Git Queues (GQ), inspired by Mercurial Queues (MQ)) and StGit. There is also TopGit, which is feature-branch management tools (which seems like what you want, from what you written below). Unfortunately I don't know which of those projects are actively maintained... > So I will first explain what I have in mind: > > As an example, let's say I am doing test-driven development. My master > branch follows the main repository of the software. Branched out from > that, I have a branch called "feature-test", and branched out from that, > "feature-implementation": > > master > |_ feature-test >|_ feature-implementation > > For each branch, I remember the parent branch. > > Implementation would then work like this: I checkout feature-test and > write some test. Then I checkout feature-implementation, rebase it to > the current status of feature-test and write the implemenation. And so on. [...] -- 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
