* [PATCH 1/5] git-p4: only a single ... wildcard is supported
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Catch the case where a ... exists at the end, and also elsehwere.
Reported-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 4 ++--
t/t9809-git-p4-client-view.sh | 8 +++++++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..20208bf 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1207,8 +1207,8 @@ class View(object):
die("Can't handle * wildcards in view: %s" % self.path)
triple_dot_index = self.path.find("...")
if triple_dot_index >= 0:
- if not self.path.endswith("..."):
- die("Can handle ... wildcard only at end of path: %s" %
+ if triple_dot_index != len(self.path) - 3:
+ die("Can handle only single ... wildcard, at end: %s" %
self.path)
self.ends_triple_dot = True
diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index c9471d5..54204af 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -101,12 +101,18 @@ test_expect_success 'unsupported view wildcard *' '
test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
'
-test_expect_success 'wildcard ... only supported at end of spec' '
+test_expect_success 'wildcard ... only supported at end of spec 1' '
client_view "//depot/.../file11 //client/.../file11" &&
test_when_finished cleanup_git &&
test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
'
+test_expect_success 'wildcard ... only supported at end of spec 2' '
+ client_view "//depot/.../a/... //client/.../a/..." &&
+ test_when_finished cleanup_git &&
+ test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
+'
+
test_expect_success 'basic map' '
client_view "//depot/dir1/... //client/cli1/..." &&
files="cli1/file11 cli1/file12" &&
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 2/5] git-p4: fix verbose comment typo
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 20208bf..e267f31 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1263,7 +1263,7 @@ class View(object):
if self.exclude:
c = "-"
return "View.Mapping: %s%s -> %s" % \
- (c, self.depot_side, self.client_side)
+ (c, self.depot_side.path, self.client_side.path)
def map_depot_to_client(self, depot_path):
"""Calculate the client path if using this mapping on the
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 3/5] git-p4: clarify comment
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e267f31..e11e15b 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1363,7 +1363,8 @@ class View(object):
else:
# This mapping matched; no need to search any further.
# But, the mapping could be rejected if the client path
- # has already been claimed by an earlier mapping.
+ # has already been claimed by an earlier mapping (i.e.
+ # one later in the list, which we are walking backwards).
already_mapped_in_client = False
for f in paths_filled:
# this is View.Path.match
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 4/5] git-p4: adjust test to adhere to stricter useClientSpec
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
This test relied on what now is seen as broken behavior
in --use-client-spec. Change it to make sure it works
according to the new behavior as described in
ecb7cf9 (git-p4: rewrite view handling, 2012-01-02) and
c700b68 (git-p4: test client view handling, 2012-01-02).
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9806-git-p4-options.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9806-git-p4-options.sh b/t/t9806-git-p4-options.sh
index 1f1952a..0571602 100755
--- a/t/t9806-git-p4-options.sh
+++ b/t/t9806-git-p4-options.sh
@@ -146,7 +146,7 @@ test_expect_success 'clone --use-client-spec' '
(
cd "$git" &&
test_path_is_file bus/dir/f4 &&
- test_path_is_file file1
+ test_path_is_missing file1
) &&
cleanup_git &&
@@ -159,7 +159,7 @@ test_expect_success 'clone --use-client-spec' '
"$GITP4" sync //depot/... &&
git checkout -b master p4/master &&
test_path_is_file bus/dir/f4 &&
- test_path_is_file file1
+ test_path_is_missing file1
)
'
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 5/5] git-p4: add tests demonstrating spec overlay ambiguities
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Introduce new tests that look more closely at overlay situations
when there are conflicting files. Five of these are broken.
Document the brokenness.
This is a fundamental problem with how git-p4 only "borrows" a
client spec. At some sync operation, a new change can contain
a file which is already in the repo or explicitly deleted through
another mapping. To sort this out would involve listing all the
files in the client spec to find one with a higher priority.
While this is not too hard for the initial import, subsequent
sync operations would be very costly.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
Documentation/git-p4.txt | 5 +
t/t9809-git-p4-client-view.sh | 387 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 392 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 78938b2..8b92cc0 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -314,6 +314,11 @@ around whitespace. Of the possible wildcards, git-p4 only handles
'...', and only when it is at the end of the path. Git-p4 will complain
if it encounters an unhandled wildcard.
+Bugs in the implementation of overlap mappings exist. If multiple depot
+paths map through overlays to the same location in the repository,
+git-p4 can choose the wrong one. This is hard to solve without
+dedicating a client spec just for git-p4.
+
The name of the client can be given to git-p4 in multiple ways. The
variable 'git-p4.client' takes precedence if it exists. Otherwise,
normal p4 mechanisms of determining the client are used: environment
diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index 54204af..ae9145e 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -247,6 +247,393 @@ test_expect_success 'quotes on rhs only' '
'
#
+# What happens when two files of the same name are overlayed together?
+# The last-listed file should take preference.
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - filecollide
+# - dir2
+# - file21
+# - file22
+# - filecollide
+#
+test_expect_success 'overlay collision setup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/filecollide >dir1/filecollide &&
+ p4 add dir1/filecollide &&
+ p4 submit -d dir1/filecollide &&
+ echo dir2/filecollide >dir2/filecollide &&
+ p4 add dir2/filecollide &&
+ p4 submit -d dir2/filecollide
+ )
+'
+
+test_expect_success 'overlay collision 1 to 2' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 filecollide" &&
+ echo dir2/filecollide >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/filecollide &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/filecollide
+'
+
+test_expect_failure 'overlay collision 2 to 1' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 filecollide" &&
+ echo dir1/filecollide >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/filecollide &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/filecollide
+'
+
+test_expect_success 'overlay collision delete 2' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir2/filecollide &&
+ p4 submit -d "remove dir2/filecollide"
+ )
+'
+
+# no filecollide, got deleted with dir2
+test_expect_failure 'overlay collision 1 to 2, but 2 deleted' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files
+'
+
+test_expect_success 'overlay collision update 1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 open dir1/filecollide &&
+ echo dir1/filecollide update >dir1/filecollide &&
+ p4 submit -d "update dir1/filecollide"
+ )
+'
+
+# still no filecollide, dir2 still wins with the deletion even though the
+# change to dir1 is more recent
+test_expect_failure 'overlay collision 1 to 2, but 2 deleted, then 1 updated' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files
+'
+
+test_expect_success 'overlay collision delete filecollides' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/filecollide dir2/filecollide &&
+ p4 submit -d "remove filecollides"
+ )
+'
+
+#
+# Overlays as part of sync, rather than initial checkout:
+# 1. add a file in dir1
+# 2. sync to include it
+# 3. add same file in dir2
+# 4. sync, make sure content switches as dir2 has priority
+# 5. add another file in dir1
+# 6. sync
+# 7. add/delete same file in dir2
+# 8. sync, make sure it disappears, again dir2 wins
+# 9. cleanup
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - colA
+# - colB
+# - dir2
+# - file21
+# - file22
+# - colA
+# - colB
+#
+test_expect_success 'overlay sync: add colA in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colA >dir1/colA &&
+ p4 add dir1/colA &&
+ p4 submit -d dir1/colA
+ )
+'
+
+test_expect_success 'overlay sync: initial git checkout' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync: add colA in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colA >dir2/colA &&
+ p4 add dir2/colA &&
+ p4 submit -d dir2/colA
+ )
+'
+
+test_expect_success 'overlay sync: colA content switch' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir2/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync: add colB in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colB >dir1/colB &&
+ p4 add dir1/colB &&
+ p4 submit -d dir1/colB
+ )
+'
+
+test_expect_success 'overlay sync: colB appears' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colB
+'
+
+test_expect_success 'overlay sync: add/delete colB in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colB >dir2/colB &&
+ p4 add dir2/colB &&
+ p4 submit -d dir2/colB &&
+ p4 delete dir2/colB &&
+ p4 submit -d "delete dir2/colB"
+ )
+'
+
+test_expect_success 'overlay sync: colB disappears' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files
+'
+
+test_expect_success 'overlay sync: cleanup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/colA dir2/colA dir1/colB &&
+ p4 submit -d "remove overlay sync files"
+ )
+'
+
+#
+# Overlay tests again, but swapped so dir1 has priority.
+# 1. add a file in dir1
+# 2. sync to include it
+# 3. add same file in dir2
+# 4. sync, make sure content does not switch
+# 5. add another file in dir1
+# 6. sync
+# 7. add/delete same file in dir2
+# 8. sync, make sure it is still there
+# 9. cleanup
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - colA
+# - colB
+# - dir2
+# - file21
+# - file22
+# - colA
+# - colB
+#
+test_expect_success 'overlay sync swap: add colA in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colA >dir1/colA &&
+ p4 add dir1/colA &&
+ p4 submit -d dir1/colA
+ )
+'
+
+test_expect_success 'overlay sync swap: initial git checkout' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync swap: add colA in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colA >dir2/colA &&
+ p4 add dir2/colA &&
+ p4 submit -d dir2/colA
+ )
+'
+
+test_expect_failure 'overlay sync swap: colA no content switch' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync swap: add colB in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colB >dir1/colB &&
+ p4 add dir1/colB &&
+ p4 submit -d dir1/colB
+ )
+'
+
+test_expect_success 'overlay sync swap: colB appears' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colB
+'
+
+test_expect_success 'overlay sync swap: add/delete colB in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colB >dir2/colB &&
+ p4 add dir2/colB &&
+ p4 submit -d dir2/colB &&
+ p4 delete dir2/colB &&
+ p4 submit -d "delete dir2/colB"
+ )
+'
+
+test_expect_failure 'overlay sync swap: colB no change' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$cli"/colB
+'
+
+test_expect_success 'overlay sync swap: cleanup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/colA dir2/colA dir1/colB &&
+ p4 submit -d "remove overlay sync files"
+ )
+'
+
+#
# Rename directories to test quoting in depot-side mappings
# //depot
# - "dir 1"
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* Re: [PATCHv3 10/13] credentials: add "cache" helper
From: Jonathan Nieder @ 2012-01-11 23:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120110175312.GA7289@sigill.intra.peff.net>
Jeff King wrote:
> Still, it would be slightly more robust. I wonder how portable fchdir
> is in practice (I guess we could always fall back to the getcwd code
> path). Do you want to prepare a patch on top?
I've been wanting to get around to doing something similar for setup.c
for a while. I'm happy enough to forget about it for now. ;-)
Thanks again for the fix. Here's another quick nit.
-- >8 --
Subject: unix-socket: do not let close() or chdir() clobber errno during cleanup
unix_stream_connect and unix_stream_listen return -1 on error, with
errno set by the failing underlying call to allow the caller to write
a useful diagnosis.
Unfortunately the error path involves a few system calls itself, such
as close(), that can themselves touch errno.
This is not as worrisome as it might sound. If close() fails, this
just means substituting one meaningful error message for another,
which is perfectly fine. However, when the call _succeeds_, it is
allowed to (and sometimes might) clobber errno along the way with some
undefined value, so it is good higiene to save errno and restore it
immediately before returning to the caller. Do so.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
unix-socket.c | 39 ++++++++++++++++++++++-----------------
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/unix-socket.c b/unix-socket.c
index 7d8bec61..01f119f9 100644
--- a/unix-socket.c
+++ b/unix-socket.c
@@ -73,25 +73,29 @@ static int unix_sockaddr_init(struct sockaddr_un *sa, const char *path,
int unix_stream_connect(const char *path)
{
- int fd;
+ int fd, saved_errno;
struct sockaddr_un sa;
struct unix_sockaddr_context ctx;
if (unix_sockaddr_init(&sa, path, &ctx) < 0)
return -1;
fd = unix_stream_socket();
- if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0)
+ goto fail;
unix_sockaddr_cleanup(&ctx);
return fd;
+
+fail:
+ saved_errno = errno;
+ unix_sockaddr_cleanup(&ctx);
+ close(fd);
+ errno = saved_errno;
+ return -1;
}
int unix_stream_listen(const char *path)
{
- int fd;
+ int fd, saved_errno;
struct sockaddr_un sa;
struct unix_sockaddr_context ctx;
@@ -100,18 +104,19 @@ int unix_stream_listen(const char *path)
fd = unix_stream_socket();
unlink(path);
- if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0)
+ goto fail;
- if (listen(fd, 5) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (listen(fd, 5) < 0)
+ goto fail;
unix_sockaddr_cleanup(&ctx);
return fd;
+
+fail:
+ saved_errno = errno;
+ unix_sockaddr_cleanup(&ctx);
+ close(fd);
+ errno = saved_errno;
+ return -1;
}
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH 1/2] cache-tree: update API to take abitrary flags
From: Junio C Hamano @ 2012-01-11 23:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326275982-29866-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> ---
Thanks; this one looks very sensible regardless of what follows (or does
not follow). Forgot to sign-off?
^ permalink raw reply
* Re: [PATCH 2/2] commit: add --skip-intent-to-add to allow commit with i-t-a entries in index
From: Junio C Hamano @ 2012-01-11 23:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326275982-29866-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> ---
> builtin/commit.c | 10 +++++++---
> cache-tree.c | 8 +++++---
> cache-tree.h | 1 +
> t/t2203-add-intent.sh | 17 +++++++++++++++++
> 4 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index bf42bb3..021206e 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -86,6 +86,7 @@ static int all, also, interactive, patch_interactive, only, amend, signoff;
> static int edit_flag = -1; /* unspecified */
> static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
> static int no_post_rewrite, allow_empty_message;
> +static int cache_tree_flags, skip_intent_to_add;
> static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
> static char *sign_commit;
>
> @@ -170,6 +171,7 @@ static struct option builtin_commit_options[] = {
> OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
> OPT_BOOLEAN(0, "no-post-rewrite", &no_post_rewrite, "bypass post-rewrite hook"),
> { OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
> + OPT_BOOL(0, "skip-intent-to-add", &skip_intent_to_add, "allow intent-to-add entries in index"),
This is more like "ignore", not "allow", from end user's point of view,
no? The user earlier said "I cannot decide what contents to put in the
commit yet for this path", and normally we catch it and remind the user
that she needs to decide. This option gives her a quick way to say "I
decide that I do not want to add this path at all to this commit I am
creating, so please ignore it in the meantime."
> @@ -1088,6 +1090,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
> cleanup_mode = CLEANUP_ALL;
> else
> die(_("Invalid cleanup mode %s"), cleanup_arg);
> + if (skip_intent_to_add)
> + cache_tree_flags = WRITE_TREE_INTENT_TO_ADD_OK;
The name WRITE_TREE_INTENT_TO_ADD_OK says "it is OK to call write-tree
with i-t-a entries in the index, please do not barf", but I think "when
writing a tree, ignore i-t-a entries" would be a more appropriate way to
say the same thing, i.e. WRITE_TREE_IGNORE_INTENT_TO_ADD.
Other than that, I do not see an issue in the implementation of the
patch. It is a separate design level issue if we want to worsen
proliferation of the options, though.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 09/10] clone: allow --branch to take a tag
From: Junio C Hamano @ 2012-01-11 23:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <1326189427-20800-10-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -766,6 +771,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> find_ref_by_name(mapped_refs, head.buf);
> strbuf_release(&head);
>
> + if (!our_head_points_at) {
> + strbuf_addstr(&head, "refs/tags/");
> + strbuf_addstr(&head, option_branch);
> + our_head_points_at =
> + find_ref_by_name(mapped_refs, head.buf);
> + strbuf_release(&head);
> + }
> +
Ok. I think this makes sense.
^ permalink raw reply
* Re: leaky cherry-pick
From: Junio C Hamano @ 2012-01-12 0:00 UTC (permalink / raw)
To: Jeff King
Cc: Ramkumar Ramachandra, Pete Wyckoff, git,
Nguyễn Thái Ngọc
In-Reply-To: <20120111195605.GB12333@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Maybe this?
>
> diff --git a/attr.c b/attr.c
> index 76b079f..1656db4 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -301,6 +301,7 @@ static void free_attr_elem(struct attr_stack *e)
> }
> free(a);
> }
> + free(e->attrs);
> free(e);
> }
Yeah, that is definitely a leak.
^ permalink raw reply
* Re: [PATCH 2/2] diff --word-diff: use non-whitespace regex by default
From: Tay Ray Chuan @ 2012-01-12 0:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <87lipexawp.fsf@thomas.inf.ethz.ch>
Hi,
Thomas, first off, thanks for looking through this.
On Thu, Jan 12, 2012 at 4:05 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> Factor out the comprehensive non-whitespace regex in use by PATTERNS and
>> IPATTERN and use it as the word-diff regex for the default diff driver.
>
> Why?
>
> I seem to recall that the motivation for keeping the original code as-is
> instead of just emulating its behavior with a default regex was that it
> is faster. So disabling the default mode should at least have an
> advantage?
>
> </devils-advocate>
If you're talking about speed, yeah, that's probably true.
But I think it's worthwhile to trade-off performance for a sensible
default. Something like
matrix[a,b,c]
matrix[d,b,c]
gives
matrix[[-a-]{+d+},b,c]
and when we have
ImagineALanguageLikeFoo
ImagineALanguageLikeBar
we get
ImagineALanguageLike[-Foo-]{+Bar+}
(But I cheated. Foo and Bar have no common characters in common; if
they did, the word diff would be messy.)
Both of which seem sensible. From a usability/effectiveness
standpoint, I think it's more useful than what the current word-diff
defaults to - the whole line is taken as a "word", with the pre-image
shown as deleted and the post-image as added; we don't even try to run
LCS on it.
Examples are lifted from:
[1] http://article.gmane.org/gmane.comp.version-control.git/105896
[2] http://article.gmane.org/gmane.comp.version-control.git/105237
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 1/2] cache-tree: update API to take abitrary flags
From: Nguyen Thai Ngoc Duy @ 2012-01-12 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmx9t6bs5.fsf@alter.siamese.dyndns.org>
2012/1/12 Junio C Hamano <gitster@pobox.com>:
> Thanks; this one looks very sensible regardless of what follows (or does
> not follow). Forgot to sign-off?
Deliberately to stop you from using it because I did not test it
carefully. It was created as material for the discussion only. Will
resubmit later.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Nguyen Thai Ngoc Duy @ 2012-01-12 1:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7v8vle6ng3.fsf@alter.siamese.dyndns.org>
2012/1/12 Junio C Hamano <gitster@pobox.com>:
>> @@ -938,6 +940,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
>> char *handler = xmalloc(len + 1);
>> handler[len] = 0;
>> strncpy(handler, url, len);
>> + remote->foreign_vcs = helper;
>> transport_helper_init(ret, handler);
>> }
>
> This I am not sure. What value does "helper" variable have at this point
> in the flow? Wouldn't it be a NULL? Or did you mean "handler"?
Ah yes "handler", my bad.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] am: learn passing -b to mailinfo
From: Junio C Hamano @ 2012-01-12 1:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <19539098c07a207f3bd24f5a145ba3b6c5e46766.1326312730.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> @@ -571,8 +574,8 @@ then
> else
> utf8=-n
> fi
> -if test "$(cat "$dotest/keep")" = t
> -then
> +keep=$(cat "$dotest/keep")
> +if test "$keep" = t
> keep=-k
> fi
Curious.
Who writes 't' to $dotest/keep after this patch is applied?
I also do not want to worry about "echo" portability issues that may come
from an existing
echo "$keep" >"$dotest/keep"
that this patch does not touch.
I suspect that this patch was not tested in a way to exercise this
codepath; shell would have barfed when seeing the lack of "then" here, no?
^ permalink raw reply
* Re: [PATCH 1/2] t9200: On MSYS, do not pass Windows-style paths to CVS
From: Junio C Hamano @ 2012-01-12 2:06 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: msysgit, git
In-Reply-To: <4F0D544E.6010105@gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> For details, see the commit message of 4114156ae9. Note that while using
> $PWD as part of GIT_DIR is not required here, it does no harm and it is
> more consistent. In addition, on MSYS using an environment variable should
> be slightly faster than spawning an external executable.
Thanks. It seems that the "Dos and Dont's" from t/README needs to be
stressed a bit more strongly.
^ permalink raw reply
* Re: git diff <file> HEAD^:<file> error message
From: Junio C Hamano @ 2012-01-12 2:26 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <20120111111831.GB15232@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> I was trying to figure out why running
>
> git diff HEAD^:RelNotes RelNotes
>
> gives the expected output (on maint it tells me that the stable
> version changed from 1.7.8.3 to 1.7.8.4) but swapping the arguments
> doesn't.
>
> git diff RelNotes HEAD^:RelNotes
>
> doesn't show the opposite patch ...
That comes from the general argument parsing rules of Git, namely, global
options (e.g. --paginate) first, then subcommand name, followed by dashed
options, revs and finally the paths. Once you give "RelNotes", which
cannot be a rev, you cannot give a rev.
We _could_ special case the rule for "diff", but we simply didn't bother,
as the resulting code (and the implications of special casing) would be
too ugly to live to support such a corner case usage, especially when you
could always say "-R" to reverse the output.
^ permalink raw reply
* Re: [PATCH 1/2] get_sha1_with_context: report features used in resolution
From: Junio C Hamano @ 2012-01-12 2:36 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git, Albert Astals Cid
In-Reply-To: <20120111194210.GA12441@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Most callers generally treat get_sha1 as a black box, giving
> it a string from the user and expecting to get a sha1 in
> return. The get_sha1_with_context function gives callers
> more information about what happened while resolving the
> object name so they can make better decisions about how to
> use the result. We currently use this only to provide
> information about the path entry used to find a blob.
>
> We don't currently provide any information about the
> resolution rules that were used to reach the final object.
> Some callers may want these in order to enforce a policy
> that a particular subset of the lookup rules are used (e.g.,
> when serving remote requests).
>
> This patch adds a set of bit-fields that document the use of
> particular features during an object lookup.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> The diffstat looks a little scary, but it is mostly just the internal
> get_sha1 functions learning to pass the object_context around.
Hmm, shouldn't this also cover peel_to_type()? That would have made it
also apply to the maintenance track.
^ permalink raw reply
* Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Junio C Hamano @ 2012-01-12 2:46 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jeff King, git, Albert Astals Cid
In-Reply-To: <1326283958-30271-1-git-send-email-cmn@elego.de>
Carlos Martín Nieto <cmn@elego.de> writes:
> The tightening done in (ee27ca4a: archive: don't let remote clients
> get unreachable commits, 2011-11-17) went too far and disallowed
> HEAD:Documentation as it would try to find "HEAD:Documentation" as a
> ref.
I do not think it went too far. Actually we discussed this exact issue
when the topic was cooking, and saw no objections. The commit in question
itself advertises this restriction.
Why are we loosening it now? I do not see a compelling reason to do so.
> Only DWIM the "HEAD" part to see if it exists as a ref. Once we're
> sure that we've been given a valid ref, we follow the normal code
> path. This still disallows attempts to access commits which are not
> branch tips.
>
> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
> ---
> AFAICT this should still be safe. Using HEAD^:Documentation or
> <sha1>:Documentation still complains that HEAD^ and <sha1> aren't
> refs.
Having said that, I think I agree this is a safe thing to do, _if_ we want
to loosen it.
^ permalink raw reply
* Re: [PATCH 1/2] get_sha1_with_context: report features used in resolution
From: Jeff King @ 2012-01-12 2:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, git, Albert Astals Cid
In-Reply-To: <7vmx9t4pgj.fsf@alter.siamese.dyndns.org>
On Wed, Jan 11, 2012 at 06:36:12PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Most callers generally treat get_sha1 as a black box, giving
> > it a string from the user and expecting to get a sha1 in
> > return. The get_sha1_with_context function gives callers
> > more information about what happened while resolving the
> > object name so they can make better decisions about how to
> > use the result. We currently use this only to provide
> > information about the path entry used to find a blob.
> >
> > We don't currently provide any information about the
> > resolution rules that were used to reach the final object.
> > Some callers may want these in order to enforce a policy
> > that a particular subset of the lookup rules are used (e.g.,
> > when serving remote requests).
> >
> > This patch adds a set of bit-fields that document the use of
> > particular features during an object lookup.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > The diffstat looks a little scary, but it is mostly just the internal
> > get_sha1 functions learning to pass the object_context around.
>
> Hmm, shouldn't this also cover peel_to_type()? That would have made it
> also apply to the maintenance track.
I don't see how peel_to_type is relevant. As far as get_sha1 is
concerned, the interesting thing is actually calling peel_onion. It does
get the context passed to it in my patch, but I didn't bother marking
that the peel feature was used (because it wasn't relevant to the policy
I wanted to implement in the follow-on patch).
But we could pretty easily mark the use of the peel feature, too.
I'm not sure what you mean about the maintenance track, though. AFAICT,
we don't separately call peel_to_type, but just potentially use it as
part of get_sha1_with_context. Am I missing something?
-Peff
^ permalink raw reply
* Re: [PATCH RFC] commit: allow to commit even if there are intent-to-add entries
From: Nguyen Thai Ngoc Duy @ 2012-01-12 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Jeff King, Will Palmer
In-Reply-To: <7vr4z654m3.fsf@alter.siamese.dyndns.org>
2012/1/12 Junio C Hamano <gitster@pobox.com>:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> When running "commit" and "status" with files marked with "intent to add",
>>> I think there are three possible interpretations of what the user
>>> wants to do.
>> [ (1) thanks for stopping me, I had forgotten about that file;
>> (2) I changed my mind, please leave that file out; or (3) please
>> dwim and add the file ]
>>
>> I think (3) was a trick --- no one that does not use the "-a" option
>> would want that. :)
>
> I really wish it were the case, but I doubt it.
>
> People from other VCS background seem to still think that "commit" without
> paths should commit everything; after getting told that "what you add to
> the index is what you will commit", I can easily see this commint: but but
> but I told Git that I _want_ to add with -N! Why aren't you committing it?
I see "-N" just as an indication, not really an "add" operation.
Perhaps update-index is a better place for it.
>> (2) makes intent-to-add entries just like any other tracked index
>> entry with some un-added content.
>
> You are comparing files edited in the working tree without the user
> telling anything about them to Git (both tracked and untracked) and files
> the user explicitly told Git that the user hasn't made up her mind
> about. Why is it a good thing to make the latter behave "just like any
> other"?
The way I see this flag is "include these files in my diff in addition
to tracked files", and therefore should not have any effects at commit
time. I might turn some of those extra files to tracked some time if I
want to commit.
--
Duy
^ permalink raw reply
* Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Jeff King @ 2012-01-12 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, git, Albert Astals Cid
In-Reply-To: <7vipkh4oyn.fsf@alter.siamese.dyndns.org>
On Wed, Jan 11, 2012 at 06:46:56PM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > The tightening done in (ee27ca4a: archive: don't let remote clients
> > get unreachable commits, 2011-11-17) went too far and disallowed
> > HEAD:Documentation as it would try to find "HEAD:Documentation" as a
> > ref.
>
> I do not think it went too far. Actually we discussed this exact issue
> when the topic was cooking, and saw no objections. The commit in question
> itself advertises this restriction.
I think you and I discussed it off list (I originally took this off-list
because the original issue did have some security implications). So I
don't think people necessarily had a chance to object.
> Why are we loosening it now? I do not see a compelling reason to do so.
I see it the opposite way. People are clearly using the "$ref:$path"
syntax. So why would we restrict them from doing so? There are no
security implications (i.e., they could always just grab $ref and
extract $path themselves). In my view, ee27ca4a was over-eager in its
restrictions because I wanted it to be simple and close the hole. Now we
can take our time adding more code to loosen it.
-Peff
^ permalink raw reply
* Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Jeff King @ 2012-01-12 2:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, git, Albert Astals Cid
In-Reply-To: <20120112025445.GB25365@sigill.intra.peff.net>
On Wed, Jan 11, 2012 at 09:54:45PM -0500, Jeff King wrote:
> On Wed, Jan 11, 2012 at 06:46:56PM -0800, Junio C Hamano wrote:
>
> > Carlos Martín Nieto <cmn@elego.de> writes:
> >
> > > The tightening done in (ee27ca4a: archive: don't let remote clients
> > > get unreachable commits, 2011-11-17) went too far and disallowed
> > > HEAD:Documentation as it would try to find "HEAD:Documentation" as a
> > > ref.
> >
> > I do not think it went too far. Actually we discussed this exact issue
> > when the topic was cooking, and saw no objections. The commit in question
> > itself advertises this restriction.
>
> I think you and I discussed it off list (I originally took this off-list
> because the original issue did have some security implications). So I
> don't think people necessarily had a chance to object.
Here is the only on-list discussion:
http://article.gmane.org/gmane.comp.version-control.git/186366
Quoted below:
>> * jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
>> - archive: don't let remote clients get unreachable commits
>> (this branch is used by jk/maint-upload-archive.)
>>
>> * jk/maint-upload-archive (2011-11-21) 1 commit
>> - Merge branch 'jk/maint-1.6.2-upload-archive' into
>> jk/maint-upload-archive
>> (this branch uses jk/maint-1.6.2-upload-archive.)
>>
>> Will merge to 'next' after taking another look.
>
> Thanks. I also have some followup patches to re-loosen to at least
> trees reachable from refs. Do you want to leave the tightening to
> the maint track, and then consider the re-loosening for master?
I was planning to first have the really tight version graduate to
'master' and ship it in 1.7.9, while possibly merging that to 1.7.8.X
series. If we hear complaints from real users in the meantime before
or after such releases, we could apply loosening patch on top of these
topics and call them "regression fix", but I have been assuming that
nobody would have been using this backdoor for anything that really
matters.
So now we have heard a complaint. :)
-Peff
^ permalink raw reply
* Re: [PATCH v3 07/10] clone: --branch=<branch> always means refs/heads/<branch>
From: Nguyen Thai Ngoc Duy @ 2012-01-12 3:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7v4nw26mbe.fsf@alter.siamese.dyndns.org>
2012/1/12 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> It does not make sense to look outside refs/heads for HEAD's target
>> (src_ref_prefix can be set to "refs/" if --mirror is used) because ref
>> code only allows symref in form refs/heads/...
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> builtin/clone.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/builtin/clone.c b/builtin/clone.c
>> index 05224d7..960242f 100644
>> --- a/builtin/clone.c
>> +++ b/builtin/clone.c
>> @@ -463,7 +463,7 @@ static void update_remote_refs(const struct ref *refs,
>> static void update_head(const struct ref *our, const struct ref *remote,
>> const char *msg)
>> {
>> - if (our) {
>> + if (our && !prefixcmp(our->name, "refs/heads/")) {
>> /* Local default branch link */
>> create_symref("HEAD", our->name, NULL);
>> if (!option_bare) {
>
> I think this makes sense. In the following three casees:
>
> - When cloning without --branch, if we could not find a branch that match
> HEAD at the remote;
>
> - When cloning with --branch, if we did not see such a branch at the
> remote; or
>
> - When cloning from an empty repository
>
> we come here with "our" set to NULL. Additionally, if the remote HEAD
> points outside refs/heads/ and the transport could detect that case
> (e.g. a helper that reads from ls-remote output), we can see our->name
> outside refs/heads/. Is there any other case where our is not NULL and
> our->name does not start with refs/heads/?
No, this patch pretty much guarantees that our->name must be inside
refs/heads, unless remote's HEAD points outside, which makes it a
broken remote and git-upload-pack should refuse to serve in the first
place. Until --branch=tag comes into the picture.
> The "else if (remote)" clause (not shown, outside the context) that
> follows still has comments that says it is a case for "Source had detached
> HEAD pointing somewhere", and needs to be adjusted for this change, no? It
> is "(1) we know the HEAD points at a non-branch, (2) HEAD may point at a
> branch but we do not know which one, or (3) we asked for a specific branch
> but it did not exist there" (cloning from an empty will have NULL in
> remote and the comment would not apply to that case).
Yes.
--
Duy
^ permalink raw reply
* Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Junio C Hamano @ 2012-01-12 3:03 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git, Albert Astals Cid
In-Reply-To: <20120112025445.GB25365@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I see it the opposite way. People are clearly using the "$ref:$path"
> syntax. So why would we restrict them from doing so? There are no
> security implications (i.e., they could always just grab $ref and
> extract $path themselves). In my view, ee27ca4a was over-eager in its
> restrictions because I wanted it to be simple and close the hole. Now we
> can take our time adding more code to loosen it.
Ok, so it is more like a partial revert of whatever we did. In that case,
I'd take CMN's patch to limit the extent of the changes, as it more
closely matches the spirit of the original ee27ca4 (archive: don't let
remote clients get unreachable commits, 2011-11-17) that singled out and
catered to the need of "archive" command alone. It is already part of the
v1.7.8.1 release, so I would prefer a change to be stupid and simple.
^ permalink raw reply
* Re: leaky cherry-pick
From: Jeff King @ 2012-01-12 3:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Pete Wyckoff, git,
Nguyễn Thái Ngọc
In-Reply-To: <7v7h0x6b89.fsf@alter.siamese.dyndns.org>
On Wed, Jan 11, 2012 at 04:00:38PM -0800, Junio C Hamano wrote:
> Yeah, that is definitely a leak.
Here it is with a commit message. "valgrind git cherry-pick" reports no
leaks in the attr code after this (but unfortunately still lots of leaks
from unpack-trees).
-Peff
-- >8 --
Subject: [PATCH] attr: fix leak in free_attr_elem
This function frees the individual "struct match_attr"s we
have allocated, but forgot to free the array holding their
pointers, leading to a very minor memory leak.
Signed-off-by: Jeff King <peff@peff.net>
---
attr.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/attr.c b/attr.c
index 96eda0e..303751f 100644
--- a/attr.c
+++ b/attr.c
@@ -301,6 +301,7 @@ static void free_attr_elem(struct attr_stack *e)
}
free(a);
}
+ free(e->attrs);
free(e);
}
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox