Re: [PATCH] Fix safe_create_leading_directories() for Windows
On Thu, Jan 2, 2014 at 10:08 PM, Junio C Hamano wrote: >> Seems like the path to clone to is taken as-is from argv in >> cmd_clone(). So maybe another solution would be to replace all >> backslashes with forward slashes already there? > > That sounds like a workable alternative, and it might even be a > preferable solution but if and only if clone's use of the function > to create paths that lead to a new working tree location is the only > (ab)use of the function. That was what I meant when I said "it may > be that it is a bug in the specific caller". AFAIK, the function I think Dscho made valid points in his other mail that the better solution still is to make safe_create_leading_directories() actually safe, also regarding its arguments. -- Sebastian Schuberth -- 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] Documentation: @{-N} can refer to a commit
The @{-N} syntax always referred to the N-th last thing checked out,
which can be either a branch or a commit (for detached HEAD cases).
However, the documentation only mentioned branches.
Edit in a "/commit" in the appropriate places.
Reported-by: Kevin
Signed-off-by: Thomas Rast
---
This is the "minimal" edit. I'd welcome better wording for the
git-commit manpage, I can't come up with any right now.
Documentation/git-checkout.txt | 4 ++--
Documentation/revisions.txt| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 91294f8..33ad2ad 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -232,8 +232,8 @@ section of linkgit:git-add[1] to learn how to operate the
`--patch` mode.
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
-As a special case, the `"@{-N}"` syntax for the N-th last branch
-checks out the branch (instead of detaching). You may also specify
+As a special case, the `"@{-N}"` syntax for the N-th last branch/commit
+checks out branches (instead of detaching). You may also specify
`-` which is synonymous with `"@{-1}"`.
+
As a further special case, you may use `"A...B"` as a shortcut for the
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 2c06ed3..5a286d0 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -88,7 +88,7 @@ some output processing may assume ref names in UTF-8.
branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
'@\{-\}', e.g. '@\{-1\}'::
- The construct '@\{-\}' means the th branch checked out
+ The construct '@\{-\}' means the th branch/commit checked out
before the current one.
'@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
--
1.9.rc0.162.g8980120
--
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] Fix safe_create_leading_directories() for Windows
On Thu, Jan 2, 2014 at 10:19 PM, Johannes Schindelin wrote: >> and parsed to be stuffed into trees), it is fine to do so as long as all >> the codepaths understands the new world order, but my earlier "git grep" >> hits did not tell me that such a change is warranted. > > You call safe_create_leading_directories() with an argument that is > supposed to be the final path, correct? So what exactly is wrong with > safe_create_leading_directories() creating all the directories necessary > so that we can write to the path afterwards, *even* if that path is > interpreted in a platform-dependent manner (as one would actually expect > it to)? > > Last time I checked we did not make a fuss about > safe_create_leading_directories() interpreting the argument in a > case-insensitive fashion on certain setups, either. So it is not exactly a > new thing that the paths are interpreted in a platform-dependent manner. Sorry for the late reply. I just want to add that on top of that, I would expect any function called *safe*_create_leading_directories() in a cross-platform project like Git (yes, effectively Git has become a cross-platform project by now) to gracefully handle platform-specific input. In other words, I would expect the word "safe" to be applied not only to the output (the creation of the directory hierarchy with any missing parent directories) but also to the input (the arguments to the function). -- Sebastian Schuberth -- 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: Verifiable git archives?
On 01/09/2014 09:11 PM, Junio C Hamano wrote: > Andy Lutomirski writes: > >> It's possible, in principle, to shove enough metadata into the output >> of 'git archive' to allow anyone to verify (without cloning the repo) >> to verify that the archive is a correct copy of a given commit. Would >> this be considered a useful feature? >> >> Presumably there would be a 'git untar' command that would report >> failure if it fails to verify the archive contents. >> >> This could be as simple as including copies of the commit object and >> all relevant tree objects and checking all of the hashes when >> untarring. > > You only need the object name of the top-level tree. After "untar" > the archive into an empty directory, make it a new repository and > "git add . && git write-tree"---the result should match the > top-level tree the archive was supposed to contain. > [...] This wouldn't work if any files were excluded from the archive using gitattribute "export-ignore" (or "export-subst", which you already mentioned in a follow-up email). Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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
Wonga Loan Right on your Doorstep.
Do you need a Loan. Here is your opportunity to acquire one. Open attachment for further information. Open with Adobe Reader. Regards, Wonga Management. WONGA-LOANS.pdf Description: Adobe PDF document
[PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components
When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where
"foo" does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or
directory
Fix this by not hard-coding a platform specific directory separator
into safe_create_leading_directories().
This patch, including its entire commit message, is derived from a
patch by Sebastian Schuberth.
Signed-off-by: Johannes Schindelin
Signed-off-by: Sebastian Schuberth
Signed-off-by: Junio C Hamano
Signed-off-by: Michael Haggerty
---
This patch applies on top of v3 of mh/safe-create-leading-directories.
The only logical change from Sebastian's patch is that this version
restores the original slash character rather than always restoring it
to '/' (as suggested by Junio).
Please note that I have merely adapted Sebastian's patch to apply on
top of my changes. I do not have an opinion about whether slashes
should rather be normalized before they are passed to this function.
And I cannot test the patch under Windows (though it passes the test
suite under Linux).
sha1_file.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 8b0849f..6e8c05d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -112,17 +112,21 @@ enum scld_error safe_create_leading_directories(char
*path)
while (ret == SCLD_OK && next_component) {
struct stat st;
- char *slash = strchr(next_component, '/');
+ char *slash = next_component, slash_character;
- if (!slash)
+ while (*slash && !is_dir_sep(*slash))
+ slash++;
+
+ if (!*slash)
break;
next_component = slash + 1;
- while (*next_component == '/')
+ while (is_dir_sep(*next_component))
next_component++;
if (!*next_component)
break;
+ slash_character = *slash;
*slash = '\0';
if (!stat(path, &st)) {
/* path exists */
@@ -148,7 +152,7 @@ enum scld_error safe_create_leading_directories(char *path)
} else if (adjust_shared_perm(path)) {
ret = SCLD_PERMS;
}
- *slash = '/';
+ *slash = slash_character;
}
return ret;
}
--
1.8.5.2
--
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 09/17] safe_create_leading_directories(): add new error value SCLD_VANISHED
Add a new possible error result that can be returned by
safe_create_leading_directories() and
safe_create_leading_directories_const(): SCLD_VANISHED. This value
indicates that a file or directory on the path existed at one point
(either it already existed or the function created it), but then it
disappeared. This probably indicates that another process deleted the
directory while we were working. If SCLD_VANISHED is returned, the
caller might want to retry the function call, as there is a chance
that a new attempt will succeed.
Why doesn't safe_create_leading_directories() do the retrying
internally? Because an empty directory isn't really ever safe until
it holds a file. So even if safe_create_leading_directories() were
absolutely sure that the directory existed before it returned, there
would be no guarantee that the directory still existed when the caller
tried to write something in it.
Signed-off-by: Michael Haggerty
---
cache.h | 10 +-
sha1_file.c | 11 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 8030e36..c0a7a8a 100644
--- a/cache.h
+++ b/cache.h
@@ -742,12 +742,20 @@ int adjust_shared_perm(const char *path);
* Create the directory containing the named path, using care to be
* somewhat safe against races. Return one of the scld_error values
* to indicate success/failure.
+ *
+ * SCLD_VANISHED indicates that one of the ancestor directories of the
+ * path existed at one point during the function call and then
+ * suddenly vanished, probably because another process pruned the
+ * directory while we were working. To be robust against this kind of
+ * race, callers might want to try invoking the function again when it
+ * returns SCLD_VANISHED.
*/
enum scld_error {
SCLD_OK = 0,
SCLD_FAILED = -1,
SCLD_PERMS = -2,
- SCLD_EXISTS = -3
+ SCLD_EXISTS = -3,
+ SCLD_VANISHED = -4
};
enum scld_error safe_create_leading_directories(char *path);
enum scld_error safe_create_leading_directories_const(const char *path);
diff --git a/sha1_file.c b/sha1_file.c
index a065308..8b0849f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -132,6 +132,17 @@ enum scld_error safe_create_leading_directories(char *path)
if (errno == EEXIST &&
!stat(path, &st) && S_ISDIR(st.st_mode))
; /* somebody created it since we checked */
+ else if (errno == ENOENT)
+ /*
+* Either mkdir() failed because
+* somebody just pruned the containing
+* directory, or stat() failed because
+* the file that was in our way was
+* just removed. Either way, inform
+* the caller that it might be worth
+* trying again:
+*/
+ ret = SCLD_VANISHED;
else
ret = SCLD_FAILED;
} else if (adjust_shared_perm(path)) {
--
1.8.5.2
--
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 12/17] remove_dir_recurse(): tighten condition for removing unreadable dir
If opendir() fails on the top-level directory, it makes sense to try
to delete it anyway--but only if the failure was due to EACCES.
Signed-off-by: Michael Haggerty
---
dir.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index d10a63f..785a83e 100644
--- a/dir.c
+++ b/dir.c
@@ -1511,8 +1511,11 @@ static int remove_dir_recurse(struct strbuf *path, int
flag, int *kept_up)
flag &= ~REMOVE_DIR_KEEP_TOPLEVEL;
dir = opendir(path->buf);
if (!dir) {
- /* an empty dir could be removed even if it is unreadble */
- if (!keep_toplevel)
+ if (errno == EACCES && !keep_toplevel)
+ /*
+* An empty dir could be removable even if it
+* is unreadable:
+*/
return rmdir(path->buf);
else
return -1;
--
1.8.5.2
--
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 08/17] cmd_init_db(): when creating directories, handle errors conservatively
safe_create_leading_directories_const() returns a non-zero value on
error. The old code at this calling site recognized a couple of
particular error values, and treated all other return values as
success. Instead, be more conservative: recognize the errors we are
interested in, but treat any other nonzero values as failures. This
is more robust in case somebody adds another possible return value
without telling us.
Signed-off-by: Michael Haggerty
---
builtin/init-db.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 6f69593..c7c76bb 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -515,13 +515,14 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
saved = shared_repository;
shared_repository = 0;
switch
(safe_create_leading_directories_const(argv[0])) {
+ case SCLD_OK:
+ case SCLD_PERMS:
+ break;
case SCLD_EXISTS:
errno = EEXIST;
/* fallthru */
- case SCLD_FAILED:
- die_errno(_("cannot mkdir %s"),
argv[0]);
- break;
default:
+ die_errno(_("cannot mkdir %s"),
argv[0]);
break;
}
shared_repository = saved;
--
1.8.5.2
--
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 16/17] rename_tmp_log(): limit the number of remote_empty_directories() attempts
This doesn't seem to be a likely error, but we've got the counter
anyway, so we might as well use it for an added bit of safety.
Please note that the first call to rename() is optimistic, and it is
normal for it to fail if there is a directory in the way. So bump the
total number of allowed attempts to 4, to be sure that we can still
have at least 3 retries in the case of a race.
Signed-off-by: Michael Haggerty
---
refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index a90904b..134d5aa 100644
--- a/refs.c
+++ b/refs.c
@@ -2530,7 +2530,7 @@ int delete_ref(const char *refname, const unsigned char
*sha1, int delopt)
static int rename_tmp_log(const char *newrefname)
{
- int attempts_remaining = 3;
+ int attempts_remaining = 4;
retry:
if (safe_create_leading_directories(git_path("logs/%s", newrefname))) {
@@ -2539,7 +2539,7 @@ static int rename_tmp_log(const char *newrefname)
}
if (rename(git_path(TMP_RENAMED_LOG), git_path("logs/%s", newrefname)))
{
- if (errno==EISDIR || errno==ENOTDIR) {
+ if ((errno==EISDIR || errno==ENOTDIR) && --attempts_remaining >
0) {
/*
* rename(a, b) when b is an existing
* directory ought to result in ISDIR, but
--
1.8.5.2
--
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 13/17] remove_dir_recurse(): handle disappearing files and directories
If a file or directory that we are trying to remove disappears (e.g.,
because another process has pruned it), do not consider it an error.
However, if REMOVE_DIR_KEEP_TOPLEVEL is set, and the toplevel
directory is missing, then consider it an error (like before).
Signed-off-by: Michael Haggerty
---
dir.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index 785a83e..b35b633 100644
--- a/dir.c
+++ b/dir.c
@@ -1511,7 +1511,9 @@ static int remove_dir_recurse(struct strbuf *path, int
flag, int *kept_up)
flag &= ~REMOVE_DIR_KEEP_TOPLEVEL;
dir = opendir(path->buf);
if (!dir) {
- if (errno == EACCES && !keep_toplevel)
+ if (errno == ENOENT)
+ return keep_toplevel ? -1 : 0;
+ else if (errno == EACCES && !keep_toplevel)
/*
* An empty dir could be removable even if it
* is unreadable:
@@ -1531,13 +1533,21 @@ static int remove_dir_recurse(struct strbuf *path, int
flag, int *kept_up)
strbuf_setlen(path, len);
strbuf_addstr(path, e->d_name);
- if (lstat(path->buf, &st))
- ; /* fall thru */
- else if (S_ISDIR(st.st_mode)) {
+ if (lstat(path->buf, &st)) {
+ if (errno == ENOENT)
+ /*
+* file disappeared, which is what we
+* wanted anyway
+*/
+ continue;
+ /* fall thru */
+ } else if (S_ISDIR(st.st_mode)) {
if (!remove_dir_recurse(path, flag, &kept_down))
continue; /* happy */
- } else if (!only_empty && !unlink(path->buf))
+ } else if (!only_empty &&
+ (!unlink(path->buf) || errno == ENOENT)) {
continue; /* happy, too */
+ }
/* path too long, stat fails, or non-directory still exists */
ret = -1;
@@ -1547,7 +1557,7 @@ static int remove_dir_recurse(struct strbuf *path, int
flag, int *kept_up)
strbuf_setlen(path, original_len);
if (!ret && !keep_toplevel && !kept_down)
- ret = rmdir(path->buf);
+ ret = (!rmdir(path->buf) || errno == ENOENT) ? 0 : -1;
else if (kept_up)
/*
* report the uplevel that it is not an error that we
--
1.8.5.2
--
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 07/17] safe_create_leading_directories(): introduce enum for return values
Instead of returning magic integer values (which a couple of callers
go to the trouble of distinguishing), return values from an enum. Add
a docstring.
Signed-off-by: Michael Haggerty
---
builtin/init-db.c | 4 ++--
cache.h | 17 +++--
merge-recursive.c | 2 +-
sha1_file.c | 16
4 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index b3f03cf..6f69593 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -515,10 +515,10 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
saved = shared_repository;
shared_repository = 0;
switch
(safe_create_leading_directories_const(argv[0])) {
- case -3:
+ case SCLD_EXISTS:
errno = EEXIST;
/* fallthru */
- case -1:
+ case SCLD_FAILED:
die_errno(_("cannot mkdir %s"),
argv[0]);
break;
default:
diff --git a/cache.h b/cache.h
index c9efe88..8030e36 100644
--- a/cache.h
+++ b/cache.h
@@ -737,8 +737,21 @@ enum sharedrepo {
};
int git_config_perm(const char *var, const char *value);
int adjust_shared_perm(const char *path);
-int safe_create_leading_directories(char *path);
-int safe_create_leading_directories_const(const char *path);
+
+/*
+ * Create the directory containing the named path, using care to be
+ * somewhat safe against races. Return one of the scld_error values
+ * to indicate success/failure.
+ */
+enum scld_error {
+ SCLD_OK = 0,
+ SCLD_FAILED = -1,
+ SCLD_PERMS = -2,
+ SCLD_EXISTS = -3
+};
+enum scld_error safe_create_leading_directories(char *path);
+enum scld_error safe_create_leading_directories_const(const char *path);
+
int mkdir_in_gitdir(const char *path);
extern void home_config_paths(char **global, char **xdg, char *file);
extern char *expand_user_path(const char *path);
diff --git a/merge-recursive.c b/merge-recursive.c
index a18bd15..8400a8e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -693,7 +693,7 @@ static int make_room_for_path(struct merge_options *o,
const char *path)
/* Make sure leading directories are created */
status = safe_create_leading_directories_const(path);
if (status) {
- if (status == -3) {
+ if (status == SCLD_EXISTS) {
/* something else exists */
error(msg, path, _(": perhaps a D/F conflict?"));
return -1;
diff --git a/sha1_file.c b/sha1_file.c
index 80122b2..a065308 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -105,12 +105,12 @@ int mkdir_in_gitdir(const char *path)
return adjust_shared_perm(path);
}
-int safe_create_leading_directories(char *path)
+enum scld_error safe_create_leading_directories(char *path)
{
char *next_component = path + offset_1st_component(path);
- int ret = 0;
+ enum scld_error ret = SCLD_OK;
- while (!ret && next_component) {
+ while (ret == SCLD_OK && next_component) {
struct stat st;
char *slash = strchr(next_component, '/');
@@ -127,26 +127,26 @@ int safe_create_leading_directories(char *path)
if (!stat(path, &st)) {
/* path exists */
if (!S_ISDIR(st.st_mode))
- ret = -3;
+ ret = SCLD_EXISTS;
} else if (mkdir(path, 0777)) {
if (errno == EEXIST &&
!stat(path, &st) && S_ISDIR(st.st_mode))
; /* somebody created it since we checked */
else
- ret = -1;
+ ret = SCLD_FAILED;
} else if (adjust_shared_perm(path)) {
- ret = -2;
+ ret = SCLD_PERMS;
}
*slash = '/';
}
return ret;
}
-int safe_create_leading_directories_const(const char *path)
+enum scld_error safe_create_leading_directories_const(const char *path)
{
/* path points to cache entries, so xstrdup before messing with it */
char *buf = xstrdup(path);
- int result = safe_create_leading_directories(buf);
+ enum scld_error result = safe_create_leading_directories(buf);
free(buf);
return result;
}
--
1.8.5.2
--
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 06/17] safe_create_leading_directories(): always restore slash at end of loop
Always restore the slash that we scribbled over at the end of the
loop, rather than also fixing it up at each premature exit from the
loop. This makes it harder to forget to do the cleanup as new paths
are added to the code.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 9d4459f..80122b2 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -108,8 +108,9 @@ int mkdir_in_gitdir(const char *path)
int safe_create_leading_directories(char *path)
{
char *next_component = path + offset_1st_component(path);
+ int ret = 0;
- while (next_component) {
+ while (!ret && next_component) {
struct stat st;
char *slash = strchr(next_component, '/');
@@ -125,25 +126,20 @@ int safe_create_leading_directories(char *path)
*slash = '\0';
if (!stat(path, &st)) {
/* path exists */
- if (!S_ISDIR(st.st_mode)) {
- *slash = '/';
- return -3;
- }
+ if (!S_ISDIR(st.st_mode))
+ ret = -3;
} else if (mkdir(path, 0777)) {
if (errno == EEXIST &&
- !stat(path, &st) && S_ISDIR(st.st_mode)) {
+ !stat(path, &st) && S_ISDIR(st.st_mode))
; /* somebody created it since we checked */
- } else {
- *slash = '/';
- return -1;
- }
+ else
+ ret = -1;
} else if (adjust_shared_perm(path)) {
- *slash = '/';
- return -2;
+ ret = -2;
}
*slash = '/';
}
- return 0;
+ return ret;
}
int safe_create_leading_directories_const(const char *path)
--
1.8.5.2
--
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 02/17] safe_create_leading_directories(): reduce scope of local variable
This makes it more obvious that values of "st" don't persist across
loop iterations.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 8031d51..d8647c7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -108,9 +108,10 @@ int mkdir_in_gitdir(const char *path)
int safe_create_leading_directories(char *path)
{
char *pos = path + offset_1st_component(path);
- struct stat st;
while (pos) {
+ struct stat st;
+
pos = strchr(pos, '/');
if (!pos)
break;
--
1.8.5.2
--
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 14/17] rename_ref(): extract function rename_tmp_log()
It's about to become a bit more complex.
Signed-off-by: Michael Haggerty
---
refs.c | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/refs.c b/refs.c
index 4060ed1..d0fab39 100644
--- a/refs.c
+++ b/refs.c
@@ -2528,6 +2528,35 @@ int delete_ref(const char *refname, const unsigned char
*sha1, int delopt)
*/
#define TMP_RENAMED_LOG "logs/refs/.tmp-renamed-log"
+static int rename_tmp_log(const char *newrefname)
+{
+ if (safe_create_leading_directories(git_path("logs/%s", newrefname))) {
+ error("unable to create directory for %s", newrefname);
+ return -1;
+ }
+
+ retry:
+ if (rename(git_path(TMP_RENAMED_LOG), git_path("logs/%s", newrefname)))
{
+ if (errno==EISDIR || errno==ENOTDIR) {
+ /*
+* rename(a, b) when b is an existing
+* directory ought to result in ISDIR, but
+* Solaris 5.8 gives ENOTDIR. Sheesh.
+*/
+ if (remove_empty_directories(git_path("logs/%s",
newrefname))) {
+ error("Directory not empty: logs/%s",
newrefname);
+ return -1;
+ }
+ goto retry;
+ } else {
+ error("unable to move logfile "TMP_RENAMED_LOG" to
logs/%s: %s",
+ newrefname, strerror(errno));
+ return -1;
+ }
+ }
+ return 0;
+}
+
int rename_ref(const char *oldrefname, const char *newrefname, const char
*logmsg)
{
unsigned char sha1[20], orig_sha1[20];
@@ -2575,30 +2604,9 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
}
}
- if (log && safe_create_leading_directories(git_path("logs/%s",
newrefname))) {
- error("unable to create directory for %s", newrefname);
+ if (log && rename_tmp_log(newrefname))
goto rollback;
- }
- retry:
- if (log && rename(git_path(TMP_RENAMED_LOG), git_path("logs/%s",
newrefname))) {
- if (errno==EISDIR || errno==ENOTDIR) {
- /*
-* rename(a, b) when b is an existing
-* directory ought to result in ISDIR, but
-* Solaris 5.8 gives ENOTDIR. Sheesh.
-*/
- if (remove_empty_directories(git_path("logs/%s",
newrefname))) {
- error("Directory not empty: logs/%s",
newrefname);
- goto rollback;
- }
- goto retry;
- } else {
- error("unable to move logfile "TMP_RENAMED_LOG" to
logs/%s: %s",
- newrefname, strerror(errno));
- goto rollback;
- }
- }
logmoved = log;
lock = lock_ref_sha1_basic(newrefname, NULL, 0, NULL);
--
1.8.5.2
--
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 17/17] rename_tmp_log(): on SCLD_VANISHED, retry
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again from the beginning. Try at most
4 times.
Signed-off-by: Michael Haggerty
---
refs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 134d5aa..0148bbd 100644
--- a/refs.c
+++ b/refs.c
@@ -2533,7 +2533,14 @@ static int rename_tmp_log(const char *newrefname)
int attempts_remaining = 4;
retry:
- if (safe_create_leading_directories(git_path("logs/%s", newrefname))) {
+ switch (safe_create_leading_directories(git_path("logs/%s",
newrefname))) {
+ case SCLD_OK:
+ break; /* success */
+ case SCLD_VANISHED:
+ if (--attempts_remaining > 0)
+ goto retry;
+ /* fall through */
+ default:
error("unable to create directory for %s", newrefname);
return -1;
}
--
1.8.5.2
--
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 00/17] Fix some mkdir/rmdir races
Sorry, I forgot to send this re-roll to the mailing list. This version differs only very slightly from v2: * Rebased to the current master (there were no conflicts). * Rename a couple of local variables from "attempts" to "attempts_remaining". * Patches 13, 16, and 17 have slightly improved commit messages. Michael Haggerty (17): safe_create_leading_directories(): fix format of "if" chaining safe_create_leading_directories(): reduce scope of local variable safe_create_leading_directories(): add explicit "slash" pointer safe_create_leading_directories(): rename local variable safe_create_leading_directories(): split on first of multiple slashes safe_create_leading_directories(): always restore slash at end of loop safe_create_leading_directories(): introduce enum for return values cmd_init_db(): when creating directories, handle errors conservatively safe_create_leading_directories(): add new error value SCLD_VANISHED lock_ref_sha1_basic(): on SCLD_VANISHED, retry lock_ref_sha1_basic(): if locking fails with ENOENT, retry remove_dir_recurse(): tighten condition for removing unreadable dir remove_dir_recurse(): handle disappearing files and directories rename_ref(): extract function rename_tmp_log() rename_tmp_log(): handle a possible mkdir/rmdir race rename_tmp_log(): limit the number of remote_empty_directories() attempts rename_tmp_log(): on SCLD_VANISHED, retry builtin/init-db.c | 9 +++--- cache.h | 25 +-- dir.c | 27 +++- merge-recursive.c | 2 +- refs.c| 92 --- sha1_file.c | 67 ++-- 6 files changed, 155 insertions(+), 67 deletions(-) -- 1.8.5.2 -- 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 03/17] safe_create_leading_directories(): add explicit "slash" pointer
Keep track of the position of the slash character independently of
"pos", thereby making the purpose of each variable clearer and
working towards other upcoming changes.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d8647c7..88b8d8c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -111,19 +111,21 @@ int safe_create_leading_directories(char *path)
while (pos) {
struct stat st;
+ char *slash = strchr(pos, '/');
- pos = strchr(pos, '/');
- if (!pos)
+ if (!slash)
break;
- while (*++pos == '/')
- ;
+ while (*(slash + 1) == '/')
+ slash++;
+ pos = slash + 1;
if (!*pos)
break;
- *--pos = '\0';
+
+ *slash = '\0';
if (!stat(path, &st)) {
/* path exists */
if (!S_ISDIR(st.st_mode)) {
- *pos = '/';
+ *slash = '/';
return -3;
}
} else if (mkdir(path, 0777)) {
@@ -131,14 +133,14 @@ int safe_create_leading_directories(char *path)
!stat(path, &st) && S_ISDIR(st.st_mode)) {
; /* somebody created it since we checked */
} else {
- *pos = '/';
+ *slash = '/';
return -1;
}
} else if (adjust_shared_perm(path)) {
- *pos = '/';
+ *slash = '/';
return -2;
}
- *pos++ = '/';
+ *slash = '/';
}
return 0;
}
--
1.8.5.2
--
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 05/17] safe_create_leading_directories(): split on first of multiple slashes
If the input path has multiple slashes between path components (e.g., "foo//bar"), then the old code was breaking the path at the last slash, not the first one. So in the above example, the second slash was overwritten with NUL, resulting in the parent directory being sought as "foo/". When stat() is called on "foo/", it fails with ENOTDIR if "foo" exists but is not a directory. This caused the wrong path to be taken in the subsequent logic. So instead, split path components at the first intercomponent slash rather than the last one. Signed-off-by: Michael Haggerty --- sha1_file.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 1e1510d..9d4459f 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -115,9 +115,10 @@ int safe_create_leading_directories(char *path) if (!slash) break; - while (*(slash + 1) == '/') - slash++; + next_component = slash + 1; + while (*next_component == '/') + next_component++; if (!*next_component) break; -- 1.8.5.2 -- 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 15/17] rename_tmp_log(): handle a possible mkdir/rmdir race
If a directory vanishes while renaming the temporary reflog file,
retry (up to 3 times). This could happen if another process deletes
the directory created by safe_create_leading_directories() just before
we rename the file into the directory.
As far as I can tell, this race could not occur internal to git. The
only time that a directory under $GIT_DIR/logs is deleted is if room
has to be made for a log file for a reference with the same name;
for example, in the following sequence:
git branch foo/bar# Creates file .git/logs/refs/heads/foo/bar
git branch -d foo/bar # Deletes file but leaves .git/logs/refs/heads/foo/
git branch foo# Deletes .git/logs/refs/heads/foo/
But the only reason the last command deletes the directory is because
it wants to create a file with the same name. So if another process
(e.g.,
git branch foo/baz
) wants to create that directory, one of the two is doomed to failure
anyway because of a D/F conflict.
Signed-off-by: Michael Haggerty
---
refs.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index d0fab39..a90904b 100644
--- a/refs.c
+++ b/refs.c
@@ -2530,12 +2530,14 @@ int delete_ref(const char *refname, const unsigned char
*sha1, int delopt)
static int rename_tmp_log(const char *newrefname)
{
+ int attempts_remaining = 3;
+
+ retry:
if (safe_create_leading_directories(git_path("logs/%s", newrefname))) {
error("unable to create directory for %s", newrefname);
return -1;
}
- retry:
if (rename(git_path(TMP_RENAMED_LOG), git_path("logs/%s", newrefname)))
{
if (errno==EISDIR || errno==ENOTDIR) {
/*
@@ -2548,6 +2550,13 @@ static int rename_tmp_log(const char *newrefname)
return -1;
}
goto retry;
+ } else if (errno == ENOENT && --attempts_remaining > 0) {
+ /*
+* Maybe another process just deleted one of
+* the directories in the path to newrefname.
+* Try again from the beginning.
+*/
+ goto retry;
} else {
error("unable to move logfile "TMP_RENAMED_LOG" to
logs/%s: %s",
newrefname, strerror(errno));
--
1.8.5.2
--
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 11/17] lock_ref_sha1_basic(): if locking fails with ENOENT, retry
If hold_lock_file_for_update() fails with errno==ENOENT, it might be
because somebody else (for example, a pack-refs process) has just
deleted one of the lockfile's ancestor directories. So if this
condition is detected, try again (up to 3 times).
Signed-off-by: Michael Haggerty
---
refs.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 9ae184d..4060ed1 100644
--- a/refs.c
+++ b/refs.c
@@ -2081,7 +2081,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock->lk = xcalloc(1, sizeof(struct lock_file));
- lflags = LOCK_DIE_ON_ERROR;
+ lflags = 0;
if (flags & REF_NODEREF) {
refname = orig_refname;
lflags |= LOCK_NODEREF;
@@ -2109,6 +2109,17 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
}
lock->lock_fd = hold_lock_file_for_update(lock->lk, ref_file, lflags);
+ if (lock->lock_fd < 0) {
+ if (errno == ENOENT && --attempts_remaining > 0)
+ /*
+* Maybe somebody just deleted one of the
+* directories leading to ref_file. Try
+* again:
+*/
+ goto retry;
+ else
+ unable_to_lock_index_die(ref_file, errno);
+ }
return old_sha1 ? verify_lock(lock, old_sha1, mustexist) : lock;
error_return:
--
1.8.5.2
--
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 01/17] safe_create_leading_directories(): fix format of "if" chaining
Signed-off-by: Michael Haggerty
---
sha1_file.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index e13bd2c..8031d51 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -125,8 +125,7 @@ int safe_create_leading_directories(char *path)
*pos = '/';
return -3;
}
- }
- else if (mkdir(path, 0777)) {
+ } else if (mkdir(path, 0777)) {
if (errno == EEXIST &&
!stat(path, &st) && S_ISDIR(st.st_mode)) {
; /* somebody created it since we checked */
@@ -134,8 +133,7 @@ int safe_create_leading_directories(char *path)
*pos = '/';
return -1;
}
- }
- else if (adjust_shared_perm(path)) {
+ } else if (adjust_shared_perm(path)) {
*pos = '/';
return -2;
}
--
1.8.5.2
--
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 04/17] safe_create_leading_directories(): rename local variable
Rename "pos" to "next_component", because now it always points at the
next component of the path name that has to be processed.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 88b8d8c..1e1510d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -107,18 +107,18 @@ int mkdir_in_gitdir(const char *path)
int safe_create_leading_directories(char *path)
{
- char *pos = path + offset_1st_component(path);
+ char *next_component = path + offset_1st_component(path);
- while (pos) {
+ while (next_component) {
struct stat st;
- char *slash = strchr(pos, '/');
+ char *slash = strchr(next_component, '/');
if (!slash)
break;
while (*(slash + 1) == '/')
slash++;
- pos = slash + 1;
- if (!*pos)
+ next_component = slash + 1;
+ if (!*next_component)
break;
*slash = '\0';
--
1.8.5.2
--
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 10/17] lock_ref_sha1_basic(): on SCLD_VANISHED, retry
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again (up to 3 times).
This can occur if another process is deleting directories at the same
time as we are trying to make them. For example, "git pack-refs
--all" tries to delete the loose refs and any empty directories that
are left behind. If a pack-refs process is running, then it might
delete a directory that we need to put a new loose reference in.
If safe_create_leading_directories() thinks this might have happened,
then take its advice and try again (maximum three attempts).
Signed-off-by: Michael Haggerty
---
refs.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 490b57b..9ae184d 100644
--- a/refs.c
+++ b/refs.c
@@ -2039,6 +2039,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
int type, lflags;
int mustexist = (old_sha1 && !is_null_sha1(old_sha1));
int missing = 0;
+ int attempts_remaining = 3;
lock = xcalloc(1, sizeof(struct ref_lock));
lock->lock_fd = -1;
@@ -2093,7 +2094,15 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
if ((flags & REF_NODEREF) && (type & REF_ISSYMREF))
lock->force_write = 1;
- if (safe_create_leading_directories(ref_file)) {
+ retry:
+ switch (safe_create_leading_directories(ref_file)) {
+ case SCLD_OK:
+ break; /* success */
+ case SCLD_VANISHED:
+ if (--attempts_remaining > 0)
+ goto retry;
+ /* fall through */
+ default:
last_errno = errno;
error("unable to create directory for %s", ref_file);
goto error_return;
--
1.8.5.2
--
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: git-p4: exception when cloning a perforce repository
dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100: > > On 16 Jan 2014, at 15:45, Pete Wyckoff wrote: > > > Oh cool, that helps a lot. P4 is just broken here, so we can get > > away with being a bit sloppy in git. I'll try just pretending > > "empty symlinks" are not in the repo. Hopefully you'll have a > > future commit in your p4 repo that brings back bn.h properly. > > Thanks ! > I would love to use git instead of perforce if possible :) > > > Still not sure about how I'll test this. > > I can test for you, no probleme with that. Any chance you can give this a go? I've a bigger patch in a longer series, but this should be the minimal fix. If it works, I'll ship it to Junio. Thanks, -- Pete 8< >From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001 From: Pete Wyckoff Date: Thu, 16 Jan 2014 18:34:09 -0500 Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist. The effect in git p4 is that "p4 print" on the symlink returns an empty string, confusing the curret symlink-handling code. In p4, syncing to a change that includes such a bogus symlink creates errors: //depot/empty-symlink - updating /home/me/p4/empty-symlink rename: /home/me/p4/empty-symlink: No such file or directory and leaves no symlink. Replicate the p4 behavior by ignoring these bogus symlinks. If they are fixed in later revisions, the symlink will be replaced properly. Reported-by: Damien Gérard Signed-off-by: Pete Wyckoff --- git-p4.py | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index 5ea8bb8..e798ecf 100755 --- a/git-p4.py +++ b/git-p4.py @@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap): # p4 print on a symlink sometimes contains "target\n"; # if it does, remove the newline data = ''.join(contents) -if data[-1] == '\n': +if not data: +# Some version of p4 allowed creating a symlink that pointed +# to nothing. This causes p4 errors when checking out such +# a change, and errors here too. Work around it by ignoring +# the bad symlink; hopefully a future change fixes it. +print "\nIgnoring empty symlink in %s" % file['depotFile'] +return +elif data[-1] == '\n': contents = [data[:-1]] else: contents = [data] -- 1.8.5.2.320.g99957e5 -- 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
REQUEST-PULL: Please pull from git-gui.
The following changes since commit 1b2c79e63e5afa3cecb3ab4a40cb414dbe6511ce: git-gui 0.19 (2014-01-18 17:29:34 +) are available in the git repository at: http://repo.or.cz/r/git-gui.git tags/gitgui-0.19.0 for you to fetch changes up to 1b2c79e63e5afa3cecb3ab4a40cb414dbe6511ce: git-gui 0.19 (2014-01-18 17:29:34 +) git-gui 0.19.0 This includes the following commits that are not already merged into the main git repository. 02f6cfb is important as it fixes an earlier commit that will prevent git-gui running with Tk 8.4. 1b2c79e git-gui 0.19 c64a0ad git-gui: chmod +x po2msg, windows/git-gui.sh 02f6cfb git-gui: fallback right pane to packed widgets with Tk 8.4 1ea11f0 git-gui i18n: Added Bulgarian translation 15a7453 git-gui l10n: Add 29 more terms to glossary 99337ef git-gui i18n: Initial glossary in Bulgarian -- Pat Thoytshttp://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD -- 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: Workflow on git with 2 branch with specifc code
Hello! Thx you all guys for the help. That's no need more explanations here for rebases Jon. I alredy do a lot of this when i need to change configs of databases and domains and other things, of my local branch to do some tests, so this is ok for me. Seems that i just need some. some people organization here. I will get that info that you guys provide to our devel group and aply that. Thaks you all for the help. On 18/01/2014 01:30, Jon Seymour wrote: On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson wrote: On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon Freeman wrote: Hello guys, im Gordon. I have a question about workflow with git that i dont know if im doing it right. I have 1 repo with 2 branchs the first is the master of the project. the second is a branch copy of the master but he need to have some specifc code because is code for a client. so, every time that i updade master i need to merge master with client branch and it give me conflicts of course that will hapen. Well if was just me who work on this 2 branchs it will be easy to fix the conflicts and let all work and shine. But whe have here, 10 people woking on master branch and some times code are lost on merge and we need to look on commits to search whats goin on. What i just asking here is if its correct the workflow that i do. If for some problem like this, the community have a standard resolution. Or if what im doing here is all wrong. There are many correct workflows. I personally use the workflow you've mentioned for the exact same reason (customizations for a client), but I'm the only developer on that repository. I agree with Brian that there are many correct workflows and which one you choose does depend on details of the branches you are trying to manage. Myself, I would tend to avoid a workflow in which you continually merge from master into the client branch. The reason is that once you have done this 20 times or so it will become quite difficult to understand how and why the client branch diverged from the master branch. Yes, it is in the history, but reasoning about diffs that cross merge points is just hard. Assuming that there is not much actual development on the client branch, but rather a relatively small set of customizations to configuration and things of that kind, then I would tend to maintain the client changes as topic branch, then maintain a client integration branch which represents the merge between master and the client topic branch. Changes that represent divergence of the client from the master branch would be committed to the client topic branch and then merged into the client integration branch. Refreshes from master would be merged into the integration branch. Commits directly to the integration branch would be avoided where possible. Once master has diverged from client enough that there start to be frequent conflicts when merging into the integration branch, then consider rebasing the client topic branch onto the tip of master branch and then repeat the cycle again. There is some risk of history loss with this approach - a later release of the client branch may not be a direct descendent of an earlier release of the client branch, but even this problem can be solved with judicious use of merge -s ours after you have successfully rebased the client topic branch. I can expand on how you do this, if there is interest. jon. -- 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] gitk: fix mistype
Signed-off-by: Max Kirillov
---
gitk-git/gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b217dbc..30a3b20 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7958,7 +7958,7 @@ proc blobdiffmaybeseehere {ateof} {
if {$diffseehere >= 0} {
mark_ctext_line [lindex [split $diffseehere .] 0]
}
-maybe_scroll_ctext ateof
+maybe_scroll_ctext $ateof
}
proc getblobdiffline {bdf ids} {
--
1.8.5.2.421.g4cdf8d0
--
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: Want to do some cleanups in this round of l10n
2014/1/18 Alexander Shopov (Александър Шопов) : > How much of a translation (in Bulgarian) should I do to be included? Feel free to send me pull request when you translated some (greater than zero) in the initial commit, and also update po/TEAMS in this commit. > I have no idea how much time do I have before 1.9 is out. Maybe three weeks left. You can estimate it by checking the date for history tags, such as v1.8.5-rc0 and v1.8.5-rc3. v1.8.5-rc0: Wed Oct 30 12:17:56 2013 -0700 v1.8.5-rc3: Wed Nov 20 11:27:39 2013 -0800 v1.8.5: Wed Nov 27 12:14:52 2013 -0800 > I have sent translations of gitk and git gui to this list as inline > patches, cc-ing the maintainers. Should I prod them again to be > considered for 1.9? > If the reviews all subscribe this list, you can send to this list. But If not, you can send to the reviewers directly. > The stats you provide do not add up plus there is nothing about fuzzy > messages Yes, fuzz messages are not included. I double checked the history of da.po and nl.po, and I'm sure there are no further updates since their maintainers sent me Email like "Hi, add me as the maintainer for that language, and I will send translations latter..." Remove them can make the Git package smaller and give opportunities to other contributors. -- Jiang Xin -- 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: Want to do some cleanups in this round of l10n
How much of a translation (in Bulgarian) should I do to be included? I have no idea how much time do I have before 1.9 is out. For this round I will try to at least translate most used commands like: commit, push, pull, rebase I have sent translations of gitk and git gui to this list as inline patches, cc-ing the maintainers. Should I prod them again to be considered for 1.9? The stats you provide do not add up plus there is nothing about fuzzy messages > da.po : 0 translated messages, 724 untranslated messages. > de.po : 2192 translated messages, 2 untranslated messages. > fr.po : 2194 translated messages. > is.po : 14 translated messages. > it.po : 716 translated messages, 350 untranslated messages. > nl.po : 0 translated messages, 722 untranslated messages. > pt_PT.po : 306 translated messages, 687 untranslated messages. > sv.po : 2194 translated messages. > vi.po : 2194 translated messages. > zh_CN.po : 2194 translated messages. Kind regards: al_shopov -- 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
