how to recovery corrupted git blob
Hi all, I have a corrupted git repo.I've worked through the process https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F but still have some problem. 1- at the beginning, with git fsck --full, it showed: Checking object directories: 100% (256/256), done. dangling blob 13dcdade560f11e8bc2d865a0d4a1a1133e5b132 dangling tree 5c9e60742ff24bb19fd73a8c1c879c4e10951b78 missing blob 96209289c92e6ef0e6beb6ec1644f93981b00829 dangling blob f61e50d30fa95683067aa2a50380e3dd7033e6dd dangling tree 95b5c5eeec8ac9359a31b268b938c142443d783a dangling commit d41b93032b34e380030207b5c8f502c6ecfd56ad dangling blob dae58bd96104c1292a20e1b8c8c948025e2e8924 missing blob e187557d07857b974ea51e3ea962ac120cfc9488 2- since I don't have a broken link message,I use $ git commit -m fixing git repo,it said: error: invalid object 100644 e187557d07857b974ea51e3ea962ac120cfc9488 for 'proje ct5/css/style.css' error: Error building trees 3- and then I use $ git hash-object -w project5/css/style.css, it said: git hash-object -w project5/css/style.css f61e50d30fa95683067aa2a50380e3dd7033e6dd the result is not the missing blob (e187557d07857b974ea51e3ea962ac120cfc9488) 4- so I use $ git log --raw --all --full-history -- project5/css/style.css, it said: commit 7b5314a110b8e2835f7f3d068072429be87be574 Merge: ec5e609 e415bb6 Author: Yvonne Leroy articulati...@gmail.com Date: Sun Dec 15 23:40:41 2013 +0800 WIP on master: ec5e609 list commit e415bb6d51ee05d60055d89f2bf63ccb32f4c12c Author: Yvonne Leroy articulati...@gmail.com Date: Sun Dec 15 23:40:39 2013 +0800 index on master: ec5e609 list :100644 100644 595691a... e187557... M project5/css/style.css commit ec76f78324632c3eebd874a724a9ebfe7d1f22ec Author: Yvonne Leroy articulati...@gmail.com Date: Sat Dec 7 14:48:37 2013 +0800 nav view :00 100644 000... 595691a... A project5/css/style.css 5-here is my problem,how can I looking at those older and newer versions(Could someone point me to which commands I should look at? Still new to git:)) so that I can use the next stepgit hash-object -w recreated-file and could someone tell me what should I do with recreated-file,is it still project5/css/style.css ? Thanks in advance, Yvonne. -- View this message in context: http://git.661346.n2.nabble.com/how-to-recovery-corrupted-git-blob-tp7601220.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to recovery corrupted git blob
Hi, On Thu, Dec 26, 2013 at 9:35 AM, Yvonne Leroy articulati...@gmail.com wrote: 1- at the beginning, with git fsck --full, it showed: [...] missing blob e187557d07857b974ea51e3ea962ac120cfc9488 [...] commit e415bb6d51ee05d60055d89f2bf63ccb32f4c12c Author: Yvonne Leroy articulati...@gmail.com Date: Sun Dec 15 23:40:39 2013 +0800 index on master: ec5e609 list :100644 100644 595691a... e187557... M project5/css/style.css The above show you that the previous version of the blob was 595691a. But in the output you showed there was no line with something like: :100644 100644 e187557... newversion... M project5/css/style.css So we know the previous version but not the subsequent version of that file. Could you check again that there is no subsequent version with something like: git log --raw --all --full-history -- project5/css/style.css | grep e187557 ? [...] 5-here is my problem,how can I looking at those older and newer versions(Could someone point me to which commands I should look at? Still new to git:)) You can use git cat-file blob 595691a to look at the previous version. so that I can use the next stepgit hash-object -w recreated-file and could someone tell me what should I do with recreated-file,is it still project5/css/style.css ? If git hash-object -w recreated-file results in e187557d07857b974ea51e3ea962ac120cfc9488 then it means that the missing blob was successfully rewritten into your git repo, so everything should be fine after that. To make sure you can run git fsck again. Note that you are trying to recreate the missing blob, but in my opinion before trying to do that you should probably try to find the missing blob in another repo. The log above showed that the missing blob was created on the 15th of December (Sun Dec 15 23:40:39 2013 +0800). Haven't you pushed your repo somewhere since that day? If you did push, it's probably easier to get the missing blob from where you pushed. Regards, Christian. -- 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: questions / suggestions about history simplification
Adam Spiers g...@adamspiers.org writes: OTOH, including a sample repository embedded within the git repository is either impossible or very ugly (e.g. having a non-default value of GIT_DIR for the embedded repository). But I doubt you were suggesting that ;-) No. By the way, t/t1200-tutorial.sh was meant to follow what the tutorial manual tells the reader to try. We may want to update and/or enhance it to cover more materials. Thanks. -- 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
Restore Lost Data for iPhone, iPad iPod Touch
Restore Lost Data for iPhone, iPad iPod Touch -- View this message in context: http://git.661346.n2.nabble.com/Restore-Lost-Data-for-iPhone-iPad-iPod-Touch-tp7601224.html Sent from the git mailing list archive at Nabble.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
[PATCH] git-svn: workaround for a bug in svn serf backend
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its 3d argument when storing it on the returned
descriptor. As a result, by the time this field is used (in
transactions of file copying or renaming) it may well be released.
This patch works around this bug, by storing the value to be passed as
the 3d argument to add_file() in a local variable with the same scope as
the file change descriptor, making sure their lifetime is the same.
Cc: Benjamin Pabst benjamin.pabs...@gmail.com
Cc: Eric Wong normalper...@yhbt.net
Signed-off-by: Roman Kagan rka...@mail.ru
---
perl/Git/SVN/Editor.pm | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index b3bcd47..ae399c3 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -304,8 +304,12 @@ sub C {
my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m-{file_b});
my $pbat = $self-ensure_path($dir, $deletions);
+ # workaround for a bug in svn serf backend (v1.8.5 and below):
+ # store 3d argument to -add_file() in a local variable, to make it
+ # have the same lifetime as $fbat
+ my $upa = $self-url_path($m-{file_a});
my $fbat = $self-add_file($self-repo_path($m-{file_b}), $pbat,
- $self-url_path($m-{file_a}), $self-{r});
+ $upa, $self-{r});
print \tC\t$m-{file_a} = $m-{file_b}\n unless $::_q;
$self-chg_file($fbat, $m);
$self-close_file($fbat,undef,$self-{pool});
@@ -323,8 +327,10 @@ sub R {
my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m-{file_b});
my $pbat = $self-ensure_path($dir, $deletions);
+ # workaround for a bug in svn serf backend, see comment in C() above
+ my $upa = $self-url_path($m-{file_a});
my $fbat = $self-add_file($self-repo_path($m-{file_b}), $pbat,
- $self-url_path($m-{file_a}), $self-{r});
+ $upa, $self-{r});
print \tR\t$m-{file_a} = $m-{file_b}\n unless $::_q;
$self-apply_autoprops($file, $fbat);
$self-chg_file($fbat, $m);
--
1.8.4.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
Restore Lost Data for iPhone, iPad iPod Touch
Restore Lost Data for iPhone, iPad iPod Touch -- View this message in context: http://git.661346.n2.nabble.com/Restore-Lost-Data-for-iPhone-iPad-iPod-Touch-tp7601226.html Sent from the git mailing list archive at Nabble.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
Publish Your PDF as Flipbook with Flipbook Maker
Publish Your PDF as Flipbook with Flipbook Maker -- View this message in context: http://git.661346.n2.nabble.com/Publish-Your-PDF-as-Flipbook-with-Flipbook-Maker-tp7601227.html Sent from the git mailing list archive at Nabble.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
Crash on context menu
Win7 SP1; Git identifies itself as version 1.8.4-preview20130916. I copied the Git Bash shortcut from the start menu to the root of a Git repository (no remote part). I use the advanced context menu. For other files in the directory, it works fine, but hovering over the Git GUI option of the Bash shortcut's menu causes a hang and this error: Problem signature: Problem Event Name:APPCRASH Application Name:explorer.exe Application Version:6.1.7601.17567 Application Timestamp:4d672ee4 Fault Module Name:git_shell_ext64.dll Fault Module Version:0.1.0.0 Fault Module Timestamp:5236e807 Exception Code:c005 Exception Offset:5952 OS Version:6.1.7601.2.1.0.768.3 Locale ID:2057 Additional Information 1:e0e1 Additional Information 2:e0e1a815a0aa94764feb60e78ef36122 Additional Information 3:adad Additional Information 4:adad544d8612f37837c12844e48b8ca2 It seems odd that it occurs on hover, but nothing else - time or other menu items - trigger it. -- 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: Crash on context menu
On Thu, Dec 26, 2013 at 2:16 PM, George Bateman georgebatema...@gmail.com wrote: Win7 SP1; Git identifies itself as version 1.8.4-preview20130916. I copied the Git Bash shortcut from the start menu to the root of a Git repository (no remote part). I use the advanced context menu. For other files in the directory, it works fine, but hovering over the Git GUI option of the Bash shortcut's menu causes a hang and this error: Problem signature: Problem Event Name:APPCRASH Application Name:explorer.exe Application Version:6.1.7601.17567 Application Timestamp:4d672ee4 Fault Module Name:git_shell_ext64.dll Fault Module Version:0.1.0.0 Fault Module Timestamp:5236e807 Exception Code:c005 Exception Offset:5952 OS Version:6.1.7601.2.1.0.768.3 Locale ID:2057 Additional Information 1:e0e1 Additional Information 2:e0e1a815a0aa94764feb60e78ef36122 Additional Information 3:adad Additional Information 4:adad544d8612f37837c12844e48b8ca2 It seems odd that it occurs on hover, but nothing else - time or other menu items - trigger it. This is a problem with git-cheetah, and not git itself, so the question is probably better suited at the msysGit mailing list, as git-cheetah is mostly developed there. -- 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
[WIP/PATCH 0/5] git checkout --recurse-submodules
Hi, This patch series comes from https://github.com/jlehmann/git-submod-enhancements branch recursive_submodule_checkout. It needed some tiny tweaks to apply to current master and build without warnings, but nothing major, and I haven't sanity checked it much beyond that and letting the kind folks that use Debian experimental play with it. I'm sending it out now to get review and ideas for what needs to happen next to get this series in shape to be included in git.git. Thoughts of all kinds welcome. Thanks, Jonathan Jens Lehmann (5): submodule: prepare for recursive checkout of submodules submodule: teach unpack_trees() to remove submodule contents submodule: teach unpack_trees() to repopulate submodules submodule: teach unpack_trees() to update submodules Teach checkout to recursively checkout submodules Documentation/git-checkout.txt | 8 ++ builtin/checkout.c | 14 +++ entry.c| 19 +++- submodule.c| 217 - submodule.h| 11 +++ t/t2013-checkout-submodule.sh | 215 +++- unpack-trees.c | 94 ++ unpack-trees.h | 1 + wrapper.c | 3 + 9 files changed, 556 insertions(+), 26 deletions(-) -- 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 2/5] submodule: teach unpack_trees() to remove submodule contents
From: Jens Lehmann jens.lehm...@web.de
Date: Tue, 19 Jun 2012 20:55:45 +0200
Implement the functionality needed to enable work tree manipulating
commands to that a deleted submodule should not only affect the index
(leaving all the files of the submodule in the work tree) but also to
remove the work tree of the superproject (including any untracked
files).
That will only work properly when the submodule uses a gitfile instead of
a .git directory and no untracked files are present. Otherwise the removal
will fail with a warning (which is just what happened until now).
Extend rmdir_or_warn() to remove the directories of those submodules which
are scheduled for removal. Also teach verify_clean_submodule() to check
that a submodule configured to be removed is not modified before scheduling
it for removal.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Should this share some code (or just the error message) with the 'git
rm' code that checks whether a submodule is safe to remove?
rmdir_or_warn is a pretty low-level function --- it feels odd to be
relying on the git repository layout here. On the other hand, that
function only has two callers, so it is possible to check quickly
whether it is safe.
I assume this is mostly for the sake of the caller in unpack-trees?
In builtin/apply.c, remove_file is used for deletion and rename
patches. Do we want this logic take effect there, too?
submodule.c| 37 +
submodule.h| 1 +
unpack-trees.c | 6 +++---
wrapper.c | 3 +++
4 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3f18d4d..a25db46 100644
--- a/submodule.c
+++ b/submodule.c
@@ -412,6 +412,43 @@ int submodule_needs_update(const char *path)
return config_update_recurse_submodules != RECURSE_SUBMODULES_OFF;
}
+int depopulate_submodule(const char *path)
+{
+ struct strbuf dot_git = STRBUF_INIT;
+ struct child_process cp;
+ const char *argv[] = {rm, -rf, path, NULL};
+
+ /* Is it populated? */
+ strbuf_addf(dot_git, %s/.git, path);
+ if (!resolve_gitdir(dot_git.buf)) {
+ strbuf_release(dot_git);
+ return 0;
+ }
+ strbuf_release(dot_git);
+
+ /* Does it have a .git directory? */
+ if (!submodule_uses_gitfile(path)) {
+ warning(_(cannot remove submodule '%s' because it (or one of
+ its nested submodules) uses a .git directory),
+ path);
+ return -1;
+ }
+
+ /* Remove the whole submodule directory */
+ memset(cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = local_repo_env;
+ cp.git_cmd = 0;
+ cp.no_stdin = 1;
+ if (run_command(cp)) {
+ warning(Could not remove submodule %s, path);
+ strbuf_release(dot_git);
+ return -1;
+ }
+
+ return 0;
+}
+
void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
unsigned char one[20], unsigned char two[20],
diff --git a/submodule.h b/submodule.h
index 055918c..df291cf 100644
--- a/submodule.h
+++ b/submodule.h
@@ -24,6 +24,7 @@ void handle_ignore_submodules_arg(struct diff_options
*diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
int parse_update_recurse_submodules_arg(const char *opt, const char *arg);
int submodule_needs_update(const char *path);
+int depopulate_submodule(const char *path);
void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
unsigned char one[20], unsigned char two[20],
diff --git a/unpack-trees.c b/unpack-trees.c
index ad3e9a0..89b506a 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -8,6 +8,7 @@
#include progress.h
#include refs.h
#include attr.h
+#include submodule.h
/*
* Error messages expected by scripts out of plumbing commands such as
@@ -1263,14 +1264,13 @@ static void invalidate_ce_path(const struct cache_entry
*ce,
/*
* Check that checking out ce-sha1 in subdir ce-name is not
* going to overwrite any working files.
- *
- * Currently, git does not checkout subprojects during a superproject
- * checkout, so it is not going to overwrite anything.
*/
static int verify_clean_submodule(const struct cache_entry *ce,
enum unpack_trees_error_types error_type,
struct unpack_trees_options *o)
{
+ if (submodule_needs_update(ce-name) is_submodule_modified(ce-name,
0))
+ return 1;
return 0;
}
diff --git a/wrapper.c b/wrapper.c
index 0cc5636..425a3fd 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -2,6 +2,7 @@
* Various trivial helper wrappers around standard functions
*/
#include cache.h
+#include submodule.h
static void do_nothing(size_t size)
{
@@
[PATCH 3/5] submodule: teach unpack_trees() to repopulate submodules
From: Jens Lehmann jens.lehm...@web.de
Date: Mon, 18 Jun 2012 22:11:45 +0200
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Neat. Would probably be clearer with some of the corresponding tests
squashed in to illustrate the intended behavior.
entry.c| 4
submodule.c| 44 +---
submodule.h| 1 +
unpack-trees.c | 19 +++
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index 7b7aa81..d1bf6ec 100644
--- a/entry.c
+++ b/entry.c
@@ -2,6 +2,7 @@
#include blob.h
#include dir.h
#include streaming.h
+#include submodule.h
static void create_directories(const char *path, int path_len,
const struct checkout *state)
@@ -203,6 +204,9 @@ static int write_entry(struct cache_entry *ce,
return error(cannot create temporary submodule %s,
path);
if (mkdir(path, 0777) 0)
return error(cannot create submodule directory %s,
path);
+ if (submodule_needs_update(path)
+ populate_submodule(path, ce-sha1, state-force))
+ return error(cannot checkout submodule %s, path);
break;
default:
return error(unknown file mode for %s in index, path);
diff --git a/submodule.c b/submodule.c
index a25db46..06df5ae 100644
--- a/submodule.c
+++ b/submodule.c
@@ -412,6 +412,42 @@ int submodule_needs_update(const char *path)
return config_update_recurse_submodules != RECURSE_SUBMODULES_OFF;
}
+int populate_submodule(const char *path, unsigned char sha1[20], int force)
+{
+ struct string_list_item *path_option;
+ const char *name, *real_git_dir;
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process cp;
+ const char *argv[] = {read-tree, force ? --reset : -m, -u,
NULL, NULL};
+
+ path_option = unsorted_string_list_lookup(config_name_for_path, path);
+ if (!path_option)
+ return 0;
+
+ name = path_option-util;
+
+ strbuf_addf(buf, %s/modules/%s, resolve_gitdir(get_git_dir()), name);
+ real_git_dir = resolve_gitdir(buf.buf);
+ if (!real_git_dir)
+ goto out;
+ connect_work_tree_and_git_dir(path, real_git_dir);
+
+ /* Run read-tree --reset sha1 */
+ memset(cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = local_repo_env;
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+ argv[3] = sha1_to_hex(sha1);
+ if (run_command(cp))
+ warning(_(Checking out submodule %s failed), path);
+
+out:
+ strbuf_release(buf);
+ return 0;
+}
+
int depopulate_submodule(const char *path)
{
struct strbuf dot_git = STRBUF_INIT;
@@ -1207,6 +1243,7 @@ void connect_work_tree_and_git_dir(const char *work_tree,
const char *git_dir)
{
struct strbuf file_name = STRBUF_INIT;
struct strbuf rel_path = STRBUF_INIT;
+ const char *real_git_dir = xstrdup(real_path(git_dir));
const char *real_work_tree = xstrdup(real_path(work_tree));
FILE *fp;
@@ -1215,15 +1252,15 @@ void connect_work_tree_and_git_dir(const char
*work_tree, const char *git_dir)
fp = fopen(file_name.buf, w);
if (!fp)
die(_(Could not create git link %s), file_name.buf);
- fprintf(fp, gitdir: %s\n, relative_path(git_dir, real_work_tree,
+ fprintf(fp, gitdir: %s\n, relative_path(real_git_dir, real_work_tree,
rel_path));
fclose(fp);
/* Update core.worktree setting */
strbuf_reset(file_name);
- strbuf_addf(file_name, %s/config, git_dir);
+ strbuf_addf(file_name, %s/config, real_git_dir);
if (git_config_set_in_file(file_name.buf, core.worktree,
- relative_path(real_work_tree, git_dir,
+ relative_path(real_work_tree, real_git_dir,
rel_path)))
die(_(Could not set core.worktree in %s),
file_name.buf);
@@ -1231,4 +1268,5 @@ void connect_work_tree_and_git_dir(const char *work_tree,
const char *git_dir)
strbuf_release(file_name);
strbuf_release(rel_path);
free((void *)real_work_tree);
+ free((void *)real_git_dir);
}
diff --git a/submodule.h b/submodule.h
index df291cf..3657ca8 100644
--- a/submodule.h
+++ b/submodule.h
@@ -24,6 +24,7 @@ void handle_ignore_submodules_arg(struct diff_options
*diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
int parse_update_recurse_submodules_arg(const char *opt, const char *arg);
int submodule_needs_update(const char *path);
+int populate_submodule(const char *path, unsigned char sha1[20], int force);
int depopulate_submodule(const
[PATCH 4/5] submodule: teach unpack_trees() to update submodules
From: Jens Lehmann jens.lehm...@web.de
Date: Fri, 5 Apr 2013 18:35:27 +0200
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Also neat, also would benefit from documentation or tests.
entry.c| 15 --
submodule.c| 86 ++
submodule.h| 3 ++
unpack-trees.c | 69 --
unpack-trees.h | 1 +
5 files changed, 157 insertions(+), 17 deletions(-)
diff --git a/entry.c b/entry.c
index d1bf6ec..61a2767 100644
--- a/entry.c
+++ b/entry.c
@@ -265,7 +265,7 @@ int checkout_entry(struct cache_entry *ce,
if (!check_path(path, len, st, state-base_dir_len)) {
unsigned changed = ce_match_stat(ce, st,
CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE);
- if (!changed)
+ if (!changed (!S_ISDIR(st.st_mode) ||
!S_ISGITLINK(ce-ce_mode)))
return 0;
if (!state-force) {
if (!state-quiet)
@@ -280,9 +280,18 @@ int checkout_entry(struct cache_entry *ce,
* just do the right thing)
*/
if (S_ISDIR(st.st_mode)) {
- /* If it is a gitlink, leave it alone! */
- if (S_ISGITLINK(ce-ce_mode))
+ if (S_ISGITLINK(ce-ce_mode)) {
+ if (submodule_needs_update(ce-name)) {
+ if (is_submodule_populated(ce-name)) {
+ if (update_submodule(ce-name,
ce-sha1, state-force))
+ return error(cannot
checkout submodule %s, path);
+ } else {
+ if (populate_submodule(path,
ce-sha1, state-force))
+ return error(cannot
populate submodule %s, path);
+ }
+ }
return 0;
+ }
if (!state-force)
return error(%s is a directory, path);
remove_subtree(path);
diff --git a/submodule.c b/submodule.c
index 06df5ae..3365987 100644
--- a/submodule.c
+++ b/submodule.c
@@ -485,6 +485,42 @@ int depopulate_submodule(const char *path)
return 0;
}
+int update_submodule(const char *path, const unsigned char sha1[20], int force)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process cp;
+ const char *hex_sha1 = sha1_to_hex(sha1);
+ const char *argv[] = {
+ checkout,
+ force ? -fq : -q,
+ hex_sha1,
+ NULL,
+ };
+ const char *git_dir;
+
+ strbuf_addf(buf, %s/.git, path);
+ git_dir = read_gitfile(buf.buf);
+ if (!git_dir)
+ git_dir = buf.buf;
+ if (!is_directory(git_dir)) {
+ strbuf_release(buf);
+ /* The submodule is not populated, so we can't check it out */
+ return 0;
+ }
+ strbuf_release(buf);
+
+ memset(cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = local_repo_env;
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path; /* GIT_WORK_TREE doesn't work for git checkout */
+ if (run_command(cp))
+ return error(Could not checkout submodule %s, path);
+
+ return 0;
+}
+
void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
unsigned char one[20], unsigned char two[20],
@@ -926,6 +962,17 @@ out:
return result;
}
+int is_submodule_populated(const char *path)
+{
+ int retval = 0;
+ struct strbuf gitdir = STRBUF_INIT;
+ strbuf_addf(gitdir, %s/.git, path);
+ if (resolve_gitdir(gitdir.buf))
+ retval = 1;
+ strbuf_release(gitdir);
+ return retval;
+}
+
unsigned is_submodule_modified(const char *path, int ignore_untracked)
{
ssize_t len;
@@ -1075,6 +1122,45 @@ int ok_to_remove_submodule(const char *path)
return ok_to_remove;
}
+unsigned is_submodule_checkout_safe(const char *path, const unsigned char
sha1[20])
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process cp;
+ const char *hex_sha1 = sha1_to_hex(sha1);
+ const char *argv[] = {
+ read-tree,
+ -n,
+ -m,
+ HEAD,
+ hex_sha1,
+ NULL,
+ };
+ const char *git_dir;
+
+ strbuf_addf(buf, %s/.git, path);
+ git_dir = read_gitfile(buf.buf);
+ if (!git_dir)
+ git_dir = buf.buf;
+ if (!is_directory(git_dir)) {
+ strbuf_release(buf);
+ /* The submodule is not
[PATCH 5/5] Teach checkout to recursively checkout submodules
From: Jens Lehmann jens.lehm...@web.de
Date: Wed, 13 Jun 2012 18:50:10 +0200
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
This is the patch that actually introduces the --recurse-submodules
option, which makes the rest work.
The tests indicate some future directions for improving this, but
it works reasonably well already. I think I'd be most comfortable
applying these if they were rearranged a little to the following
order:
1. First, introducing the --recurse-submodules option, perhaps
with no actual effect, with tests that it is parsed correctly,
the default works, etc.
2. Then, adding the desired behaviors one by one with corresponding
tests (handling submodule modifications, removals, additions).
3. Finally, any needed tweaks on top.
That way, it is easy to play around with early patches without
worrying about the later ones at first, and the patches are easy
to review to confirm that they at least don't break anything in
the --no-recurse-submodules case.
That said, Debian experimental has these applied as is already,
and there haven't been any complaints yet.
Thoughts?
Jonathan
Documentation/git-checkout.txt | 8 ++
builtin/checkout.c | 14 +++
submodule.c| 14 +++
submodule.h| 3 +
t/t2013-checkout-submodule.sh | 215 -
5 files changed, 251 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 91294f8..aabcc65 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -225,6 +225,14 @@ This means that you can use `git checkout -p` to
selectively discard
edits from your current working tree. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
+--[no-]recurse-submodules::
+ Using --recurse-submodules will update the content of all initialized
+ submodules according to the commit recorded in the superproject.If
+ local modifications in a submodule would be overwritten the checkout
+ will fail until `-f` is used. If nothing (or --no-recurse-submodules)
+ is used, the work trees of submodules will not be updated, only the
+ hash recorded in the superproject will be changed.
+
branch::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with refs/heads/, is a valid ref), then that
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5df3837..ac2f8d8 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -21,6 +21,9 @@
#include submodule.h
#include argv-array.h
+static const char *recurse_submodules_default = off;
+static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
+
static const char * const checkout_usage[] = {
N_(git checkout [options] branch),
N_(git checkout [options] [branch] -- file...),
@@ -,6 +1114,12 @@ int cmd_checkout(int argc, const char **argv, const char
*prefix)
N_(do not limit pathspecs to sparse entries only)),
OPT_HIDDEN_BOOL(0, guess, dwim_new_local_branch,
N_(second guess 'git checkout
no-such-branch')),
+ { OPTION_CALLBACK, 0, recurse-submodules, recurse_submodules,
+ checkout, control recursive updating of
submodules,
+ PARSE_OPT_OPTARG, option_parse_update_submodules },
+ { OPTION_STRING, 0, recurse-submodules-default,
+ recurse_submodules_default, NULL,
+ default mode for recursion, PARSE_OPT_HIDDEN },
OPT_END(),
};
@@ -1132,6 +1141,11 @@ int cmd_checkout(int argc, const char **argv, const char
*prefix)
git_xmerge_config(merge.conflictstyle, conflict_style, NULL);
}
+ set_config_update_recurse_submodules(
+
parse_fetch_recurse_submodules_arg(--recurse-submodules-default,
+ recurse_submodules_default),
+ recurse_submodules);
+
if ((!!opts.new_branch + !!opts.new_branch_force +
!!opts.new_orphan_branch) 1)
die(_(-b, -B and --orphan are mutually exclusive));
diff --git a/submodule.c b/submodule.c
index 3365987..bdce1b2 100644
--- a/submodule.c
+++ b/submodule.c
@@ -398,6 +398,20 @@ int parse_update_recurse_submodules_arg(const char *opt,
const char *arg)
}
}
+int option_parse_update_submodules(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (unset) {
+ *(int *)opt-value = RECURSE_SUBMODULES_OFF;
+ } else {
+ if (arg)
+ *(int *)opt-value =
parse_update_recurse_submodules_arg(opt-long_name, arg);
+ else
+ *(int *)opt-value =
Re: german translation bug
On Wed, Dec 25, 2013 at 10:53 PM, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: Am Mittwoch, 25. Dezember 2013, 21:59:10 schrieb Ralf Thielow: What version of Git do you use? What distro in what version do you use? freshly installed kubuntu 13.10. The package language-pack-de mentioned at the end of this mail is installed. I suppose I should open a KDE bug report? The Ubuntu translators have already updated the German Git translation for 13.10. So the issue should be fixed in the next language pack update [1]. AFAIK Ubuntu ships the translations aside software packages that they're able to update l10n without updating the software itself. They also maintain the translations for themselves. Issues that's been reported to them also getting fixed by them. However, those fixes do not necessarily find their way to upstream Git translations. The benefit of reporting issues to Git ML is that they can be fixed in both upstream Git and Ubuntu. I'll try to keep an eye to launchpad and fix bugs in German translation reported on the ML on both places in the future. Thanks for reporting the issue. [1] https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git/de/+translate?batch=10show=allsearch=nothing+to+commit%2C+working+directory+clean i5:~ ((unknown)) git --version git version 1.8.3.2 wr@s5:~/kajongg/src$ grep -a 'Nichts zum Einreichen' /usr/share/locale-langpack/de/LC_MESSAGES/git.mo Nichts zum Einreichen Nichts zum Einreichen, Arbeitsverzeichnis leer root@s5:~/kajongg/src# apt-file search /de/ | grep /git.mo language-pack-de-base: /usr/share/locale-langpack/de/LC_MESSAGES/git.mo root@s5:~/kajongg/src# LANG=C dpkg --info /var/cache/apt/archives/language-pack-de-base_1%3a13.10+20131012_all.deb new debian package, version 2.0. size 3346634 bytes: control archive=7323 bytes. 955 bytes,19 lines control 20278 bytes, 231 lines md5sums 125 bytes, 9 lines * postinst #!/bin/sh 121 bytes, 9 lines * postrm #!/bin/sh Package: language-pack-de-base Version: 1:13.10+20131012 Architecture: all Maintainer: Language pack maintainers language-pa...@ubuntu.com Installed-Size: 11247 Pre-Depends: dpkg (= 1.10.27ubuntu1) Depends: locales (= 2.3.6), language-pack-de (= 1:13.10+20131012) Recommends: firefox-locale-de Conflicts: language-pack-de ( 1:13.10+20131012) Replaces: language-pack-de ( 1:13.10+20131012), language-pack-de-base ( 1:13.10+20131012), language-pack-gnome-de ( 1:13.10+20131012), language-pack-gnome-de-base ( 1:13.10+20131012), language-pack-kde-de ( 1:13.10+20131012), language-pack-kde-de-base ( 1:13.10+20131012) Section: translations Priority: optional Description: translations for language German Translation data for all supported packages for: German . This package provides the bulk of translation data and is updated only seldom. language-pack-de provides frequent translation updates, so you should install this as well. -- Wolfgang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Support multiple worktrees
Duy Nguyen pclo...@gmail.com writes: On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote: Do we even need to expose them as ref-like things as a part of the external API/UI in the first place? For end-user scripts that want to operate in a real or borrowing worktree, there should be no reason to touch this other repository directly. Things like if one of the wortrees tries to check out a branch that is already checked out elsewhere, error out policy may need to consult the other worktrees via $GIT_COMMON_DIR mechanism but at that level we have all the control without contaminating end-user facing ref namespace in a way main/FETCH_HEAD... do. No, external API/UI is just extra bonus. We need to (or should) do so in order to handle $GIT_COMMON_DIR/HEAD exactly like how we do normal refs. And that is what I consider a confusion-trigger, not a nice bonus. I do not think it is particularly a good idea to contaminate end-user namespace for this kind of peek another repository special operation. In order to handle your multiple worktrees manipulating the same branch case sanely, you need to be aware of not just the real repository your worktree is borrowing from, but also _all_ the other worktrees that borrow from that same real repository, so a single main virtual namespace will not cut it. You will be dealing with an unbounded set of HEADs, one for each such worktree. Can't we do this by adding a with this real repository layer, e.g. resolve HEAD wrt that repository, somewhat similar to how we peek into submodule namespaces? -- 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] add: don't complain when adding empty project root
Hi,
Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Thanks.
[...]
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
for (i = 0; i pathspec.nr; i++) {
const char *path = pathspec.items[i].match;
- if (!seen[i]
+ if (!seen[i] pathspec.items[i].match[0]
((pathspec.items[i].magic
(PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
!file_exists(path))) {
Nit: in this loop there's already the synonym 'path' for item.match,
so perhaps
if (!seen[i] path[0] ...)
would be clearer.
Should git add --refresh . get the same treatment?
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -307,4 +307,8 @@ test_expect_success 'git add --dry-run --ignore-missing
of non-existing file out
test_i18ncmp expect.err actual.err
'
+test_expect_success 'git add -A on empty repo does not error out' '
+ git init empty ( cd empty git add -A . )
+'
Adding a test at the end like this means the tests come in chronological
order instead of logical order and simultaneous patches to the same
test script become more likely to conflict.
How about something like the following, for squashing in?
With or without the tweaks below,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
diff --git i/builtin/add.c w/builtin/add.c
index fbd3f3a..d7e3e44 100644
--- i/builtin/add.c
+++ w/builtin/add.c
@@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
for (i = 0; i pathspec.nr; i++) {
const char *path = pathspec.items[i].match;
- if (!seen[i] pathspec.items[i].match[0]
+ if (!seen[i] path[0]
((pathspec.items[i].magic
(PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
!file_exists(path))) {
diff --git i/t/t3700-add.sh w/t/t3700-add.sh
index 1535d8f..fe274e2 100755
--- i/t/t3700-add.sh
+++ w/t/t3700-add.sh
@@ -272,6 +272,25 @@ test_expect_success 'add non-existent should fail' '
! (git ls-files | grep non-existent)
'
+test_expect_success 'git add -A on empty repo does not error out' '
+ rm -fr empty
+ git init empty
+ (
+ cd empty
+ git add -A .
+ git add -A
+ )
+'
+
+test_expect_success 'git add . in empty repo' '
+ rm -fr empty
+ git init empty
+ (
+ cd empty
+ git add .
+ )
+'
+
test_expect_success 'git add --dry-run of existing changed file'
echo new track-this
git add --dry-run track-this actual 21
@@ -307,8 +326,4 @@ test_expect_success 'git add --dry-run --ignore-missing of
non-existing file out
test_i18ncmp expect.err actual.err
'
-test_expect_success 'git add -A on empty repo does not error out' '
- git init empty ( cd empty git add -A . )
-'
-
test_done
--
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] add: don't complain when adding empty project root
Jonathan Nieder jrnie...@gmail.com writes: How about something like the following, for squashing in? With or without the tweaks below, Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks, both. Regarding git add --refresh (no other arguments), it would say Nothing specified, nothing added., and that is unrelated to the breakage reported and fixed in this thread, I think. It is the same message git add (no other arguments) gives, which I think is a mistake. git add --refresh is like git add -u in that the affected paths are determined by the index, and running these commands while your index is still empty can just be a silent no-op. -- 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 v3 07/10] builtin/replace: teach listing using short, medium or full formats
Christian Couder christian.cou...@gmail.com writes: On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: I think this last one might be useful for people replacing objects with objects that have another type. ... which IIUC is strongly discouraged---didn't you have to tighten it recently? And that makes it useful primarily for debugging unusual situations. Ok, so would you prefer the following: - NAME_ONLY_REPLACE_FMT and --format=name_only instead of SHORT_REPLACE_FMT and --format=short - NAME_AND_VALUE_REPLACE_FMT and --format=name_and_value instead of MEDIUM_REPLACE_FMT and --format=medium - DEBUG_REPLACE_FMT and --format=debug instead of FULL _REPLACE_FMT and --format=full The end-user facing names are probably fine with short, medium, full, as long as what they show are clearly explained in the end-user documentation (patch 10/10 covers this). I have a hunch that we may later regret full when somebody wants to add even fuller information, though. It might be better spelled long instead; I'd rather see REPLACE_FMT_ as a prefix, not suffix. Do we use common suffix for enum values elsewhere? -- 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] add: don't complain when adding empty project root
Junio C Hamano gits...@pobox.com writes:
Regarding git add --refresh (no other arguments), it would say
Nothing specified, nothing added., and that is unrelated to the
breakage reported and fixed in this thread, I think. It is the same
message git add (no other arguments) gives, which I think is a
mistake. git add --refresh is like git add -u in that the
affected paths are determined by the index, and running these
commands while your index is still empty can just be a silent no-op.
Something like this...
builtin/add.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index d7e3e44..84e8a3e 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -483,8 +483,10 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
(implicit_dot ? ADD_CACHE_IMPLICIT_DOT : 0);
if (require_pathspec argc == 0) {
- fprintf(stderr, _(Nothing specified, nothing added.\n));
- fprintf(stderr, _(Maybe you wanted to say 'git add .'?\n));
+ if (!refresh_only) {
+ fprintf(stderr, _(Nothing specified, nothing
added.\n));
+ fprintf(stderr, _(Maybe you wanted to say 'git add
.'?\n));
+ }
return 0;
}
--
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 02/12] Convert starts_with() to skip_prefix() for option parsing
Duy Nguyen pclo...@gmail.com writes: On Sat, Dec 21, 2013 at 4:31 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: /* here we care if we saw the prefix, as above */ if (parse_prefix(foo, prefix, the_rest)) ... /* * and here we do not care, and just want to optionally strip the * prefix, and take the full value otherwise; we just have to ignore * the return value in this case. */ parse_prefix(foo, prefix, foo); Sounds fine. I recall earlier somebody wanting to have a good name for this thing, and I think foo_gently is *not* it (the name is about adding a variant that does not die outright to foo that checks and dies if condition is not right). starts_with(foo, prefix); strip_prefix(foo, prefix, foo); perhaps? I still need consensus on the name here guys, parse_prefix. remove_prefix or strip_prefix? If no other opinions i'll go with strip_prefix (Jeff's comment before parse_prefix() also uses strip) Yup, that comment is where I took strip from. When you name your thing as X, using too generic a word X, and then need to explain what X does using a bit more specific word Y, you are often better off naming it after Y. -- 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 1/2] sha1_object_info_extended: provide delta base sha1s
Jeff King p...@peff.net writes:
@@ -1824,6 +1856,22 @@ static int packed_object_info(struct packed_git *p,
off_t obj_offset,
}
}
+ if (oi-delta_base_sha1) {
+ if (type == OBJ_OFS_DELTA || type == OBJ_REF_DELTA) {
+ const unsigned char *base;
+
+ base = get_delta_base_sha1(p, w_curs, curpos,
+type, obj_offset);
+ if (!base) {
+ type = OBJ_BAD;
+ goto out;
+ }
+
+ hashcpy(oi-delta_base_sha1, base);
+ } else
+ hashclr(oi-delta_base_sha1);
+ }
+
Makes sense.
--
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: [WIP/PATCH 0/5] git checkout --recurse-submodules
Jonathan Nieder jrnie...@gmail.com writes: Hi, This patch series comes from https://github.com/jlehmann/git-submod-enhancements branch recursive_submodule_checkout. It needed some tiny tweaks to apply to current master and build without warnings, but nothing major, and I haven't sanity checked it much beyond that and letting the kind folks that use Debian experimental play with it. I'm sending it out now to get review and ideas for what needs to happen next to get this series in shape to be included in git.git. Thoughts of all kinds welcome. Thanks, Jonathan Jens Lehmann (5): submodule: prepare for recursive checkout of submodules submodule: teach unpack_trees() to remove submodule contents submodule: teach unpack_trees() to repopulate submodules submodule: teach unpack_trees() to update submodules Teach checkout to recursively checkout submodules Documentation/git-checkout.txt | 8 ++ builtin/checkout.c | 14 +++ entry.c| 19 +++- submodule.c| 217 - submodule.h| 11 +++ t/t2013-checkout-submodule.sh | 215 +++- unpack-trees.c | 94 ++ unpack-trees.h | 1 + wrapper.c | 3 + 9 files changed, 556 insertions(+), 26 deletions(-) Looks reasonably clean from a cursory read. Thanks. -- 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 0/2] cat-file --batch-check='%(deltabase)'
Jeff King wrote: I needed this recently to write tests for another (not yet published) series. But I think it stands on its own as a debugging / introspection tool. [1/2]: sha1_object_info_extended: provide delta base sha1s [2/2]: cat-file: provide %(deltabase) batch format Neat. The error handling looks right. Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: workaround for a bug in svn serf backend
Roman Kagan wrote: Subversion serf backend in versions 1.8.5 and below has a bug that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its 3d argument when storing it on the returned 3d makes me think of 3-dimensional. ;-) I think you mean third (or the abbreviation 3rd). descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released. Please describe the symptom so this patch is easy to find when other people run into it. Do I remember correctly that ... released and scribbled over with a new value, causing such-and-such assertion to fire was what happened? This patch works around this bug, by storing the value to be passed as the 3d argument to add_file() in a local variable with the same scope as the file change descriptor, making sure their lifetime is the same. Could this be reproduced with a test script to make sure we don't reintroduce the bug again later? (It's okay if the test only fails on machines with the problematic svn version.) Modulo the confusing 3-dimensional arguments in comments, the code change looks good. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2013, #05; Thu, 26)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * bc/log-decoration (2013-12-20) 1 commit - log: properly handle decorations with chained tags git log --decorate did not handle a tag pointed by another tag nicely. Will merge to 'next'. * jh/rlimit-nofile-fallback (2013-12-18) 1 commit - get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure When we figure out how many file descriptors to allocate for keeping packfiles open, a system with non-working getrlimit() could cause us to die(), but because we make this call only to get a rough estimate of how many is available and we do not even attempt to use up all file descriptors available ourselves, it is nicer to fall back to a reasonable low value rather than dying. Will merge to 'next'. * rt/bfg-ad-in-filter-branch-doc (2013-12-18) 1 commit - docs: add filter-branch notes on The BFG Will merge to 'next'. * sb/diff-orderfile-config (2013-12-18) 3 commits - diff: add diff.orderfile configuration variable - diff: let git diff -O read orderfile from any file and fail properly - t4056: add new tests for git diff -O Allow git diff -Ofile to be configured with a new configuration variable. Will merge to 'next'. * jc/graph-post-root-gap (2013-12-20) 1 commit - graph: give an extra gap after showing root commit This was primarily a RFH ($gmane/239580). * nd/daemon-informative-errors-typofix (2013-12-20) 1 commit - daemon: be strict at parsing parameters --[no-]informative-errors Will merge to 'next'. * tm/fetch-prune (2013-12-20) 2 commits - fetch --prune: run prune before fetching - fetch --prune: always print header url Fetching 'frotz' branch with git fetch, while having 'frotz/nitfol' remote-tracking branch from an earlier fetch, would error out, primarily because the command has not been told to remove anything on our side. In such a case, git fetch --prune can be used to remove 'frotz/nitfol' to make room to fetch and store 'frotz' remote-tracking branch. Will merge to 'next'. * jk/oi-delta-base (2013-12-26) 2 commits - cat-file: provide %(deltabase) batch format - sha1_object_info_extended: provide delta base sha1s Teach cat-file --batch to show delta-base object name for a packed object that is represented as a delta. Will merge to 'next'. * jk/sha1write-void (2013-12-26) 1 commit - do not pretend sha1write returns errors Code clean-up. Will merge to 'next'. * jl/submodule-recursive-checkout (2013-12-26) 5 commits - Teach checkout to recursively checkout submodules - submodule: teach unpack_trees() to update submodules - submodule: teach unpack_trees() to repopulate submodules - submodule: teach unpack_trees() to remove submodule contents - submodule: prepare for recursive checkout of submodules * mh/safe-create-leading-directories (2013-12-26) 5 commits - rename_ref(): fix a mkdir()/rmdir() race - safe_create_leading_directories(): fix a mkdir/rmdir race - safe_create_leading_directories(): add slash pointer - safe_create_leading_directories(): reduce scope of local variable - safe_create_leading_directories(): modernize format of if chaining Code clean-up and protection against concurrent write access to the ref namespace. Will merge to 'next'. * nd/add-empty-fix (2013-12-26) 1 commit - add: don't complain when adding empty project root git add -A (no other arguments) in a totally empty working tree used to emit an error. Will merge to 'next'. * nd/commit-tree-constness (2013-12-26) 1 commit - commit.c: make tree a const pointer in commit_tree*() Code clean-up. Will merge to 'next'. -- [Stalled] * mo/subtree-split-updates (2013-12-10) 3 commits - subtree: add --edit option - subtree: allow --squash and --message with push - subtree: support split --rejoin --squash Comments? * hv/submodule-ignore-fix (2013-12-06) 4 commits - disable complete ignorance of submodules for index - HEAD diff - always show committed submodules in summary after commit - teach add -f option for ignored submodules - fix 'git add' to skip submodules configured as ignored Teach git add to be consistent with git status when changes to submodules are set to be ignored, to avoid surprises after checking with git status to see there isn't any change to be further added and then see that git add . adds changes to them. I think a reroll is coming, so this may need to be replaced, but I needed some practice with heavy conflict resolution. It conflicts with two changes to git add that have been scheduled for Git 2.0 quite badly, and I think I got the resolution right
Re: [PATCH 1/5] safe_create_leading_directories(): modernize format of if chaining
Michael Haggerty wrote: [Subject: safe_create_leading_directories(): modernize format of if chaining] Trivia: it's not so much modernizing as following KR style, which git more or less followed since day 1. Linux's Documentation/CodingStyle explains: Note that the closing brace is empty on a line of its own, _except_ in the cases where it is followed by a continuation of the same statement, ie a while in a do-statement or an else in an if-statement, like this: [...] Rationale: KR. Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on. Here it's especially jarring since the function uses a mix of styles. Thanks for cleaning it up. -- 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 2/5] safe_create_leading_directories(): reduce scope of local variable
Michael Haggerty wrote:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index c9245a6..cc9957e 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;
Is this to make it easier to reason about whether 'st' has been
properly initialized at any given moment, or is there a more subtle
reason?
Curious,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] safe_create_leading_directories(): add slash pointer
Michael Haggerty wrote:
[Subject: safe_create_leading_directories(): add slash pointer]
Is this a cleanup or improving the (internal) functionality of the
function somehow? The above one-liner doesn't sum up for me in an
obvious way why this is a good change.
Keep track of the position of the slash character separately, and
Separately from what?
restore the slash character at a single place, at the end of the while
loop. This makes the next change easier to implement.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Ah, do I understand correctly that this is about cleaning up
after the code that scribbles over 'path' in one place, to make
it harder to forget to do that cleanup as new code paths are
introduced?
It's too bad there's no variant of 'stat' and 'mkdir' that takes
a (buf, len) pair which would avoid the scribbling altogether.
---
sha1_file.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index cc9957e..dcfd35a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -107,40 +107,40 @@ 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);
This name change is probably worth also mentioning in the commit
message (or lifting into a separate patch) so the reader doesn't get
distracted.
+ int retval = 0;
- while (pos) {
+ while (!retval next_component) {
A more usual style would be
int ... = 0;
while (pos) {
...
if (!stat(path, st)) {
/* path exists */
if (!S_ISDIR(st.st_mode)) {
... = -3;
goto out;
}
} else if (...) {
...
}
...
}
out:
*slash = '/';
return ...;
}
which makes it more explicit that the slash needs to be written back.
In this example, that would look like:
char *slash = NULL;
int ret;
while (pos) {
...
if (!slash)
break;
...
if (!*pos)
break;
*slash = '\0';
if (!stat(path, st)) {
if (!S_ISDIR(st.st_mode)) {
ret = -3;
goto out;
}
} else if (mkdir(...)) {
if (errno == EEXIST ...) {
; /* ok */
} else {
ret = -1;
goto out;
}
} else if (adjust_shared_perm(...)) {
ret = -2;
goto out;
}
*slash = '/';
}
ret = 0;
out:
if (slash)
*slash = '/';
return ret;
Using retval for control flow instead makes it eight lines more
concise, which is probably worth it.
[...]
if (!S_ISDIR(st.st_mode)) {
- *pos = '/';
- return -3;
+ retval = -3;
}
Now the 'if' body is one line, so we can drop the braces and save
another line. :)
One more nit: elsewhere in this file, a variable keeping track of the
return value is named 'ret', so it probably makes sense to also use
that name here.
That would mean the following changes to be potentially squashed in
(keeping 'pos' name to make the patch easier to read, s/retval/ret/,
removing unnecessary braces). None of these tweaks are particularly
important. Feel free to skip them --- the only comment I've made that
matters is about the commit message.
Thanks for a nice cleanup,
Jonathan
diff --git i/sha1_file.c w/sha1_file.c
index dcfd35a..18cb50a 100644
--- i/sha1_file.c
+++ w/sha1_file.c
@@ -107,40 +107,38 @@ int mkdir_in_gitdir(const char *path)
int safe_create_leading_directories(char *path)
{
- char *next_component = path + offset_1st_component(path);
- int retval = 0;
+ char *pos = path + offset_1st_component(path);
+ int ret = 0;
- while (!retval next_component) {
+ while (!ret pos) {
struct stat st;
- char *slash = strchr(next_component, '/');
+ char *slash = strchr(pos, '/');
if (!slash)
return 0;
while (*(slash + 1) == '/')
slash++;
- next_component = slash + 1;
- if (!*next_component)
+ pos = slash + 1;
+ if (!*pos)
return
Re: [PATCH 4/5] safe_create_leading_directories(): fix a mkdir/rmdir race
Hi, Michael Haggerty wrote: It could be that some other process is trying to clean up empty directories at the same time that safe_create_leading_directories() is attempting to create them. In this case, it could happen that directory a/b was present at the end of one iteration of the loop (either it was already present or we just created it ourselves), but by the time we try to create directory a/b/c, directory a/b has been deleted. In fact, directory a might also have been deleted. When does this happen in practice? Is this about git racing with itself or with some other program? I fear that the aggressive directory creator fighting the aggressive directory remover might be waging a losing battle. Is this about a push that creates a ref racing against a push that deletes a ref from the same hierarchy? So, if a call to mkdir() fails with ENOENT, then try checking/making all directories again from the beginning. Attempt up to three times before giving up. If we are racing against a ref deletion, then we can retry while our rival keeps walking up the directory tree and deleting parent directories. As soon as we successfully create a directory, we have won the race. But what happens if the entire safe_create_leading_directories operation succeeds and *then* our racing partner deletes the directory? No one is putting in a file to reserve the directory for the directory creator. If we care enough to retry more than once, I fear this is retrying at the wrong level. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- sha1_file.c | 11 +++ 1 file changed, 11 insertions(+) Tests? The code is clear and implements the design correctly. Thanks for some food for thought, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] rename_ref(): fix a mkdir()/rmdir() race
Michael Haggerty wrote:
refs.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
A test or example reproduction recipe would be nice. (But I can
understand not having one --- races are hard to test.)
[...]
--- a/refs.c
+++ b/refs.c
[...]
@@ -2574,6 +2575,13 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
}
goto retry;
} else {
+ if (errno == ENOENT --attempts)
+ /*
+ * Perhaps somebody just pruned the empty
+ * directory into which we wanted to move the
+ * file.
+ */
+ goto retry;
Style nit: it's easier to read a test of errno when the 'else's
cascade (i.e., using 'else if' here).
This patch doesn't depend on any of the others from the series. For
what it's worth, with or without the following squashed in,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
diff --git i/refs.c w/refs.c
index 3ab1491..ea62395 100644
--- i/refs.c
+++ w/refs.c
@@ -2574,14 +2574,14 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
goto rollback;
}
goto retry;
+ } else if (errno == ENOENT --attempts)
+ /*
+* Perhaps somebody just pruned the empty
+* directory into which we wanted to move the
+* file.
+*/
+ goto retry;
} else {
- if (errno == ENOENT --attempts)
- /*
-* Perhaps somebody just pruned the empty
-* directory into which we wanted to move the
-* file.
-*/
- goto retry;
error(unable to move logfile TMP_RENAMED_LOG to
logs/%s: %s,
newrefname, strerror(errno));
goto rollback;
--
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: german translation bug
2013/12/27 Ralf Thielow ralf.thie...@gmail.com: On Wed, Dec 25, 2013 at 10:53 PM, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: Am Mittwoch, 25. Dezember 2013, 21:59:10 schrieb Ralf Thielow: What version of Git do you use? What distro in what version do you use? freshly installed kubuntu 13.10. The package language-pack-de mentioned at the end of this mail is installed. I suppose I should open a KDE bug report? The Ubuntu translators have already updated the German Git translation for 13.10. So the issue should be fixed in the next language pack update [1]. AFAIK Ubuntu ships the translations aside software packages that they're able to update l10n without updating the software itself. They also maintain the translations for themselves. Issues that's been reported to them also getting fixed by them. However, those fixes do not necessarily find their way to upstream Git translations. The benefit of reporting issues to Git ML is that they can be fixed in both upstream Git and Ubuntu. I'll try to keep an eye to launchpad and fix bugs in German translation reported on the ML on both places in the future. Thanks for reporting the issue. [1] https://translations.launchpad.net/ubuntu/saucy/+source/git/+pots/git/de/+translate?batch=10show=allsearch=nothing+to+commit%2C+working+directory+clean I reported the same issue recently, and you can see reply from Canonical in this thread: * http://thread.gmane.org/gmane.comp.version-control.git/239130 -- 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: [PATCH] git-svn: workaround for a bug in svn serf backend
2013/12/27 Jonathan Nieder jrnie...@gmail.com: Roman Kagan wrote: Subversion serf backend in versions 1.8.5 and below has a bug that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its 3d argument when storing it on the returned 3d makes me think of 3-dimensional. ;-) I think you mean third (or the abbreviation 3rd). Indeed. descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released. Please describe the symptom so this patch is easy to find when other people run into it. OK Do I remember correctly that ... released and scribbled over with a new value, causing such-and-such assertion to fire was what happened? Exactly. This patch works around this bug, by storing the value to be passed as the 3d argument to add_file() in a local variable with the same scope as the file change descriptor, making sure their lifetime is the same. Could this be reproduced with a test script to make sure we don't reintroduce the bug again later? (It's okay if the test only fails on machines with the problematic svn version.) That would need a fairly fancy setup phase, as the bug triggers only on http(s)-accessed svn repositories. I'll take a look if there's something already available in the existing test scripts; writing one from scratch for this specific case is IMO beyond the reasonable effort. Modulo the confusing 3-dimensional arguments in comments, the code change looks good. Thanks, I'll adjust the wording and resubmit. Roman. -- 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] git-svn: workaround for a bug in svn serf backend
2013/12/27 Roman Kagan rka...@mail.ru: 2013/12/27 Jonathan Nieder jrnie...@gmail.com: Could this be reproduced with a test script to make sure we don't reintroduce the bug again later? (It's okay if the test only fails on machines with the problematic svn version.) That would need a fairly fancy setup phase, as the bug triggers only on http(s)-accessed svn repositories. I'll take a look if there's something already available in the existing test scripts Turns out the stuff is all there, and the tests doing file renames and dcomit-ting them do exist (t9115-git-svn-dcommit-funky-renames.sh for one). However, the httpd setup is seriously broken; I haven't managed to get it to run on my Fedora 20 with apache 2.4.6. Apparently git-svn tests (almost) never get executed against an http-based repository; even those who don't set NO_SVN_TESTS get them run against file-based repository and thus don't trigger the error. Someone with better apache-foo needs to take a look into that. Once that is sorted out I believe the tests will start triggering the bug. Meanwhile I assume that the patch doesn't need to include an extra testcase. Roman. -- 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
