Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)
Jens Müller blog at 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
Re: Difficulty adding a symbolic link, part 3
From: Duy Nguyen pclo...@gmail.com 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: Difficulty adding a symbolic link, part 3
From: Duy Nguyen pclo...@gmail.com
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
[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 marcn...@xiplink.com --- 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: [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 marcn...@xiplink.com -- 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 bca...@nvidia.com 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 v6 6/6] config: git config --get-urlmatch parses section.url.key
Jeff King p...@peff.net 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
On Thu, Aug 1, 2013 at 10:12 AM, Junio C Hamano gits...@pobox.com wrote:
Brandon Casey bca...@nvidia.com 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
[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 gits...@pobox.com
---
* 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] Provide some linguistic guidance for the documentation.
Marc Branchaud marcn...@xiplink.com 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
Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
Brandon Casey draf...@gmail.com 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
[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 marcn...@xiplink.com --- On 13-08-01 02:21 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com 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
On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com 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
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 draf...@gmail.com wrote: On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com 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
Brandon Casey draf...@gmail.com writes: On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com 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
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
On Thu, Aug 1, 2013 at 1:02 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com 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
Re: What's cooking in git.git (Jul 2013, #09; Mon, 29)
Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk 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: What's cooking in git.git (Jul 2013, #09; Mon, 29)
Ramsay Jones ram...@ramsay1.demon.co.uk writes: Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk 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
[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 path will behave as git add -A path, 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 path 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 applied to any other ref. This is a backward
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
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
Re: Difficulty adding a symbolic link, part 3
On Thu, Aug 1, 2013 at 10:00 PM, Dale R. Worley wor...@alum.mit.edu wrote:
From: Duy Nguyen pclo...@gmail.com
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
Re: [TIG][PATCH] Scroll diff with arrow keys in log view
On Wed, Jul 31, 2013 at 11:11 PM, Kumar Appaiah a.ku...@alumni.iitm.ac.in 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: [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 a.ku...@alumni.iitm.ac.in 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: 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
[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 draf...@gmail.com
---
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
+
