Re: [PATCH] git-svn: workaround for a bug in svn serf backend

[Roman Kagan]

2013/12/27 Roman Kagan :
> 2013/12/27 Jonathan Nieder :
>> 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

Re: [PATCH] git-svn: workaround for a bug in svn serf backend

[Roman Kagan]

2013/12/27 Jonathan Nieder :
> 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: german translation bug

[Jiang Xin]

2013/12/27 Ralf Thielow :
> On Wed, Dec 25, 2013 at 10:53 PM, Wolfgang Rohdewald
>  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=10&show=all&search=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 5/5] rename_ref(): fix a mkdir()/rmdir() race

[Jonathan Nieder]

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 

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: [PATCH 4/5] safe_create_leading_directories(): fix a mkdir/rmdir race

[Jonathan Nieder]

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 
> ---
>  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 3/5] safe_create_leading_directories(): add "slash" pointer

[Jonathan Nieder]

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 

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)
  

Re: [PATCH 2/5] safe_create_leading_directories(): reduce scope of local variable

[Jonathan Nieder]

Michael Haggerty wrote:

> 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 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 1/5] safe_create_leading_directories(): modernize format of "if" chaining

[Jonathan Nieder]

Michael Haggerty wrote:

> [Subject: safe_create_leading_directories(): modernize format of "if" 
> chaining]

Trivia: it's not so much modernizing as following K&R 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: K&R.

  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

What's cooking in git.git (Dec 2013, #05; Thu, 26)

[Junio C Hamano]

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 -O" 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

Re: [PATCH] git-svn: workaround for a bug in svn serf backend

[Jonathan Nieder]

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

Re: [PATCH 0/2] cat-file --batch-check='%(deltabase)'

[Jonathan Nieder]

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 
--
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

[Junio C Hamano]

Jonathan Nieder  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 1/2] sha1_object_info_extended: provide delta base sha1s

[Junio C Hamano]

Jeff King  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: [PATCH 02/12] Convert starts_with() to skip_prefix() for option parsing

[Junio C Hamano]

Duy Nguyen  writes:

> On Sat, Dec 21, 2013 at 4:31 AM, Junio C Hamano  wrote:
>> Jeff King  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] add: don't complain when adding empty project root

[Junio C Hamano]

Junio C Hamano  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 v3 07/10] builtin/replace: teach listing using short, medium or full formats

[Junio C Hamano]

Christian Couder  writes:

> On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano  wrote:
>> Christian Couder  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]

Jonathan Nieder  writes:

> How about something like the following, for squashing in?
>
> With or without the tweaks below,
> Reviewed-by: Jonathan Nieder 

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] add: don't complain when adding empty project root

[Jonathan Nieder]

Hi,

Nguyễn Thái Ngọc Duy wrote:

> Signed-off-by: Nguyễn Thái Ngọc Duy 

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 

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 2>&1 &&
@@ -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 v2 00/21] Support multiple worktrees

[Junio C Hamano]

Duy Nguyen  writes:

> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano  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: german translation bug

[Jonathan Nieder]

Hi,

Wolfgang Rohdewald wrote:
> Am Mittwoch, 25. Dezember 2013, 22:53:29 schrieb Wolfgang Rohdewald:

>> I suppose I should open a KDE bug report?
>
> I meant a ubuntu bug report of course.

Yes, please.  Feel free to cc me if doing so.

In generally, I'm a bit uncomfortable lately at how Ubuntu's
translation system works for Git.  They are trying to solve a real
problem: old Ubuntu releases stick to old versions of git that do not
have as complete translations as the latest version.  But their
solution to this problem does not seem to work well and creates a lot
of confusion.  Worse, it creates duplicated effort, as their custom
translations don't seem to have been submitted upstream for review or
inclusion.
--
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

[Ralf Thielow]

On Wed, Dec 25, 2013 at 10:53 PM, Wolfgang Rohdewald
 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=10&show=all&search=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 
>  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

[PATCH 5/5] Teach checkout to recursively checkout submodules

[Jonathan Nieder]

From: Jens Lehmann 
Date: Wed, 13 Jun 2012 18:50:10 +0200

Signed-off-by: Jens Lehmann 
Signed-off-by: Jonathan Nieder 
---
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 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] "),
N_("git checkout [options] [] -- ..."),
@@ -,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 = RECURSE_SUBMODULES_ON;
+   }
+   

[PATCH 4/5] submodule: teach unpack_trees() to update submodules

[Jonathan Nieder]

From: Jens Lehmann 
Date: Fri, 5 Apr 2013 18:35:27 +0200

Signed-off-by: Jens Lehmann 
Signed-off-by: Jonathan Nieder 
---
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 popula

[PATCH 3/5] submodule: teach unpack_trees() to repopulate submodules

[Jonathan Nieder]

From: Jens Lehmann 
Date: Mon, 18 Jun 2012 22:11:45 +0200

Signed-off-by: Jens Lehmann 
Signed-off-by: Jonathan Nieder 
---
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(

[PATCH 2/5] submodule: teach unpack_trees() to remove submodule contents

[Jonathan Nieder]

From: Jens Lehmann 
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 
Signed-off-by: Jonathan Nieder 
---
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)
 {
@@ -409,6 +410,8 @@ int

[PATCH 1/5] submodule: prepare for recursive checkout of submodules

[Jonathan Nieder]

From: Jens Lehmann 
Date: Mon, 18 Jun 2012 22:17:59 +0200

This commit adds the functions needed for configuration, for setting the
default behavior and for determining if a submodule path should be updated
automatically.

Signed-off-by: Jens Lehmann 
Signed-off-by: Jonathan Nieder 
---
Should probably be squashed into a patch that uses and documents this
configuration.

 submodule.c | 36 
 submodule.h |  3 +++
 2 files changed, 39 insertions(+)

diff --git a/submodule.c b/submodule.c
index 613857e..3f18d4d 100644
--- a/submodule.c
+++ b/submodule.c
@@ -16,6 +16,8 @@ static struct string_list config_name_for_path;
 static struct string_list config_fetch_recurse_submodules_for_name;
 static struct string_list config_ignore_for_name;
 static int config_fetch_recurse_submodules = RECURSE_SUBMODULES_ON_DEMAND;
+static int config_update_recurse_submodules = RECURSE_SUBMODULES_OFF;
+static int option_update_recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
 static struct string_list changed_submodule_paths;
 static int initialized_fetch_ref_tips;
 static struct sha1_array ref_tips_before_fetch;
@@ -382,6 +384,34 @@ int parse_fetch_recurse_submodules_arg(const char *opt, 
const char *arg)
}
 }
 
+int parse_update_recurse_submodules_arg(const char *opt, const char *arg)
+{
+   switch (git_config_maybe_bool(opt, arg)) {
+   case 1:
+   return RECURSE_SUBMODULES_ON;
+   case 0:
+   return RECURSE_SUBMODULES_OFF;
+   default:
+   if (!strcmp(arg, "checkout"))
+   return RECURSE_SUBMODULES_ON;
+   die("bad %s argument: %s", opt, arg);
+   }
+}
+
+int submodule_needs_update(const char *path)
+{
+   struct string_list_item *path_option;
+   path_option = unsorted_string_list_lookup(&config_name_for_path, path);
+   if (!path_option)
+   return 0;
+
+   /* update can't be "none", "merge" or "rebase" */
+
+   if (option_update_recurse_submodules != RECURSE_SUBMODULES_DEFAULT)
+   return 1;
+   return config_update_recurse_submodules != RECURSE_SUBMODULES_OFF;
+}
+
 void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
unsigned char one[20], unsigned char two[20],
@@ -589,6 +619,12 @@ int push_unpushed_submodules(unsigned char new_sha1[20], 
const char *remotes_nam
return ret;
 }
 
+void set_config_update_recurse_submodules(int default_value, int option_value)
+{
+   config_update_recurse_submodules = default_value;
+   option_update_recurse_submodules = option_value;
+}
+
 static int is_submodule_commit_present(const char *path, unsigned char 
sha1[20])
 {
int is_present = 0;
diff --git a/submodule.h b/submodule.h
index 7beec48..055918c 100644
--- a/submodule.h
+++ b/submodule.h
@@ -22,12 +22,15 @@ void gitmodules_config(void);
 int parse_submodule_config_option(const char *var, const char *value);
 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);
 void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
unsigned char one[20], unsigned char two[20],
unsigned dirty_submodule, const char *meta,
const char *del, const char *add, const char *reset);
 void set_config_fetch_recurse_submodules(int value);
+void set_config_update_recurse_submodules(int default_value, int option_value);
 void check_for_new_submodule_commits(unsigned char new_sha1[20]);
 int fetch_populated_submodules(const struct argv_array *options,
   const char *prefix, int command_line_option,
-- 
1.8.5.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[WIP/PATCH 0/5] git checkout --recurse-submodules

[Jonathan Nieder]

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

Re: Crash on context menu

[Erik Faye-Lund]

On Thu, Dec 26, 2013 at 2:16 PM, George Bateman
 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

Crash on context menu

[George Bateman]

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

Publish Your PDF as Flipbook with Flipbook Maker

[StellaWolf]

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

Restore Lost Data for iPhone, iPad & iPod Touch

[StellaWolf]

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

[PATCH] git-svn: workaround for a bug in svn serf backend

[Roman Kagan]

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 
Cc: Eric Wong 
Signed-off-by: Roman Kagan 
---
 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

[StellaWolf]

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

Re: questions / suggestions about history simplification

[Junio C Hamano]

Adam Spiers  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

Re: how to recovery corrupted git blob

[Christian Couder]

Hi,

On Thu, Dec 26, 2013 at 9:35 AM, Yvonne Leroy  wrote:
>
> 1- at the beginning, with "git fsck --full", it showed:

[...]

> missing blob e187557d07857b974ea51e3ea962ac120cfc9488

[...]

> commit e415bb6d51ee05d60055d89f2bf63ccb32f4c12c
> Author: Yvonne Leroy 
> 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... ... 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 
> and could someone tell me what should I do with ,is it still
> project5/css/style.css ?

If "git hash-object -w " 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

how to recovery corrupted git blob

[Yvonne Leroy]

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 
Date:   Sun Dec 15 23:40:41 2013 +0800 

WIP on master: ec5e609 list 

commit e415bb6d51ee05d60055d89f2bf63ccb32f4c12c 
Author: Yvonne Leroy 
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 
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 
and could someone tell me what should I do with ,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-tp7601221.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

how to recovery corrupted git blob

[Yvonne Leroy]

Hi all,

I have a corrupted git repo.I've worked through the process


 
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 
Date:   Sun Dec 15 23:40:41 2013 +0800

WIP on master: ec5e609 list

commit e415bb6d51ee05d60055d89f2bf63ccb32f4c12c
Author: Yvonne Leroy 
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 
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 
and could someone tell me what should I do with ,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