Re: [PATCH v3 07/25] reflog: avoid constructing .lock path with git_path

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v3 07/25] reflog: avoid constructing .lock path with git_path

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:00

Nguyễn Thái Ngọc Duy  [off-list ref] writes:
git_path() soon understands the path given to it. Some paths "abc" may
become "def" while other "ghi" may become "ijk". We don't want
git_path() to interfere with .lock path construction. Concatenate
".lock" after the path has been resolved by git_path() so if "abc"
becomes "def", we'll have "def.lock", not "ijk".
Hmph.  I am not sure if the above is readable (or if I am reading it
correctly).

If "abc" becomes "def", it would take deliberate work to make
"abc.lock" into "ijk", and it would be natural to expect that
"abc.lock" would become "def.lock" without any fancy trick, no?

quoted hunk
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
 builtin/reflog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 852cff6..ccf2cf6 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -372,7 +372,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
 	if (!file_exists(log_file))
 		goto finish;
 	if (!cmd->dry_run) {
-		newlog_path = git_pathdup("logs/%s.lock", ref);
+		newlog_path = mkpathdup("%s.lock", log_file);
 		cb.newlog = fopen(newlog_path, "w");
 	}

Re: [PATCH v3 07/25] reflog: avoid constructing .lock path with git_path

From: Duy Nguyen <hidden>
Date: 2016-06-15 23:00:07

On Wed, Feb 26, 2014 at 5:44 AM, Junio C Hamano [off-list ref] wrote:
Nguyễn Thái Ngọc Duy  [off-list ref] writes:
quoted
git_path() soon understands the path given to it. Some paths "abc" may
become "def" while other "ghi" may become "ijk". We don't want
git_path() to interfere with .lock path construction. Concatenate
".lock" after the path has been resolved by git_path() so if "abc"
becomes "def", we'll have "def.lock", not "ijk".
Hmph.  I am not sure if the above is readable (or if I am reading it
correctly).
Definitely not now that I have had my break from the series and reread it.
If "abc" becomes "def", it would take deliberate work to make
"abc.lock" into "ijk", and it would be natural to expect that
"abc.lock" would become "def.lock" without any fancy trick, no?
A better explanation may be, while many paths are not converted by
git_path() ("abc" -> "abc"), some of them will be based on the given
path ("def" -> "ghi"). Giving path def.lock to git_path() may confuse
it and make it believe def.lock should not be converted because the
signature is "def.lock" not "def". But we want the lock file to have
the same base name with the locked file (e.g. "ghi.lock", not
"def.lock"). So it's best to append ".lock" after git_path() has done
its conversion.

The alternative is teach git_path about ".lock", but I don't really
want to put more logic down there.
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help