这丑与美的世界

[这丑与美的世界]

你的老朋友邀你来Q群:343257759

Gitignore file exceptions are not applied to untarcked files

[Assen Totin]

Hi,

I'm not sure if the described issue is a bug or a feature; if it is the
latter, please, excuse the report.

I'm dealing with git 1.7.12.4. If this has been addressed in the later
issue, please, point me so.

The problem: I have a directory tree with lots of files and dirs, of which
I only track certain files in subdirs of a specific subdir. It goes like
this:

/untracted_file1
/untracked_file2
/untracked_dir1/...
/untracked_dir2/...
/tracked_dir/subdir1/config
/tracked_dir/subdir1/another_untracked_file
/tracked_dir/subdir2/config
/tracked_dir/subdir2/another_untracked_file

I'm only interested in /tracked_dir/.../config files. My .gitignore is as
follows:

# Ignore everything first
*
# Do not ignore tracked files
!/tracked_dir/*/config
# Don't ignore .gitignore
!.gitignore

This works fine until a new directory with a config file is created inside
/tracked_dir:

/tracked_dir/new_subdir/config

This config file is not seen by git at all (git status returns no changes
to add), although it matches the exclusion pattern.

While I can use various workarounds, I'm interested whether this actual
phenomenon occurs - why does the exclusion pattern not match an untracked
file in untracked directory? Is it because the exclusion pattern is never
applied to untracked files? Or is it because the directory new_subdir is
itself untracked?

WWell,

Assen Totin
--
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: fast-import fails in read-only tree

[Stefan Monnier]

>> I recently discovered that "git fast-import" signals an error if used in
>> a tree to which we do not have write-access, because it tries to create
>> a "objects/pack/tmp_pack_XXX" file even before starting to process
>> the commands.
> The primary goal of fast-import is to write that packfile.  It kind of
> sounds like you are using the wrong tool for the job.

Yes, I realize that.  But in some cases it's the best tool available.
`fast-import' is very close to being a "generic access API" which can be
used instead of something like libgit.  I think it'd be good to push it
yet a bit closer.

My earlier "cat-blob applied to a tree" issue is another such case.

> Can you elaborate on what you are sending to fast-import (preferably
> with a concrete example)?

I'm sending a stream of "progress ; cat-blob ", basically.

The concrete example is in [BuGit](https://gitlab.com/monnier/bugit),
see for example 
https://gitlab.com/monnier/bugit/commit/3678dcb8830a9c79c6f3404d75d63e6dd07bfe4c

> There may be a way to accomplish the same thing with read-only tools
> like cat-file.

Yes, I switched to using "cat-file --batch" instead, but it's less
convenient (I can't intersperse ad-hoc info in the output, the way I can
with "progress" in fast-import) and there are cases where the list of
files I need to extract cannot be determined without first looking at
some of those extracted files (I currently have been able to avoid
this in BuGit, luckily).

If I could use "cat-blob" on directories, there would be even more cases
where I'd want to use fast-import for read-only operations to reduce the
number of Git processes I fork.


Stefan

--
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 v5 03/10] test-regex: expose full regcomp() to the command line

[Ramsay Jones]

On 29/01/16 05:31, Eric Sunshine wrote:
> On Thu, Jan 28, 2016 at 06:56:16PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>> diff --git a/test-regex.c b/test-regex.c
>> @@ -1,19 +1,63 @@
>>  int main(int argc, char **argv)
>>  {
>> -char *pat = "[^={} \t]+";
>> -char *str = "={}\nfred";
>> +const char *pat;
>> +const char *str;
>> +int flags = 0;
>>  regex_t r;
>>  regmatch_t m[1];
>>  
>> -if (regcomp(, pat, REG_EXTENDED | REG_NEWLINE))
>> +if (argc == 1) {
>> +/* special case, bug check */
>> +pat = "[^={} \t]+";
>> +str = "={}\nfred";
>> +flags = REG_EXTENDED | REG_NEWLINE;
>> +} else {
>> +argv++;
>> +pat = *argv++;
>> +str = *argv++;
> 
> I realize that this is just a test program, but it might be a good
> idea to insert:
> 
> if (argc < 3)
> die("usage: ...");
> 
> prior to the *argv++ dereferences to give a controlled failure rather
> than an outright crash when an incorrect number of arguments is
> given.
> 
> More below...
> 
>> +while (*argv) {
>> +struct reg_flag *rf;
>> +for (rf = reg_flags; rf->name; rf++)
>> +if (!strcmp(*argv, rf->name)) {
>> +flags |= rf->flag;
>> +break;
>> +}
>> +if (!rf->name)
>> +die("do not recognize %s", *argv);
>> +argv++;
>> +}
>> +git_setup_gettext();
>> +}
>> +
>> +if (regcomp(, pat, flags))
>>  die("failed regcomp() for pattern '%s'", pat);
>> -if (regexec(, str, 1, m, 0))
>> -die("no match of pattern '%s' to string '%s'", pat, str);
>> +if (regexec(, str, 1, m, 0)) {
>> +if (argc == 1)
>> +die("no match of pattern '%s' to string '%s'", pat, 
>> str);
>> +return 1;
>> +}
>>  
>>  /* http://sourceware.org/bugzilla/show_bug.cgi?id=3957  */
>> -if (m[0].rm_so == 3) /* matches '\n' when it should not */
>> +if (argc == 1 && m[0].rm_so == 3) /* matches '\n' when it should not */
>>  die("regex bug confirmed: re-build git with NO_REGEX=1");
> 
> Again, I realize that this is just a test program, but sprinkling
> this 'argc == 1' special case throughout the code makes it
> unnecessarily difficult to follow. 

I completely agree!

> Some alternatives:
> 
> 1. Rename the existing test-regex to test-regex-bug (or
>test-regex-bugs), and then name the new general purpose program
>test-regex.
> 
> 2. Drop the special case altogether and have the program emit the
>matched text on stdout (in addition to the exit code indicating
>success/failure). Most callers will care only about the exit
>status, but the one special case in t0070 which wants to check for
>the glibc bug can do so itself:
> 
> test_expect_success 'check for a bug in the regex routines' '
> # if this test fails, re-build git with NO_REGEX=1
> printf "fred" >expect &&
> test-regex "[^={} \t]+" "={}\nfred" EXTENDED NEWLINE >actual &&
> test_cmp expect actual
> '
> 
>Of course, that doesn't actually work because "\n" in the 'str'
>argument isn't really a newline, so test-regex would have to do a
>bit of preprocessing of 'str' first (which might be as simple as
>calling unquote_c_style() or something).
> 
> 3. [less desirable] Move the 'argc == 1' special case to its own
>function, which will result in a bit of duplicated code, but the
>result should at least be easier to follow.

I think this is the most desirable (and was going to be my first
suggestion); the duplication is minimal and it makes the code _much_
easier to follow. [I suppose separate test programs (ie. point 1) would
be my second choice.]

ATB,
Ramsay Jones


--
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/2] stash: use "stash--helper"

[Thomas Gummerer]

On 01/28, Stefan Beller wrote:
> On Thu, Jan 28, 2016 at 12:36 PM, Matthias Asshauer  wrote:
> > From: Matthias Aßhauer 
> >
> > Use the new "git stash--helper" builtin. It should be faster than the old 
> > shell code and is a first step to move
> > more shell code to C.
>
> You had some good measurements in the coverletter, which is not going to be
> recorded in the projects history. This part however would be part of the 
> commit.
> So you could move the speed improvements here (as well as the other reasoning)
> on why this is a good idea. :)

In addition it would be nice to add a performance test in t/perf,
especially since it seems further improvements are planned.  That will
make it easy for everyone to reproduce the performance numbers for
different use-cases.

Matthias, feel free to squash the following (or something similar) in
when you re-roll.

diff --git a/t/perf/p3000-stash.sh b/t/perf/p3000-stash.sh
new file mode 100755
index 000..e6e1153
--- /dev/null
+++ b/t/perf/p3000-stash.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+test_description="Test performance of git stash"
+
+. ./perf-lib.sh
+
+test_perf_default_repo
+
+file=$(git ls-files | tail -n 30 | head -1)
+
+test_expect_success "prepare repository" "
+   echo x >$file
+"
+
+test_perf "stash/stash pop" "
+   git stash &&
+   git stash pop
+"
+
+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 0/9] Handle errors when setting configs

[Jeff King]

On Thu, Jan 28, 2016 at 10:00:28AM +0100, Patrick Steinhardt wrote:

> I've finally got around to producing version two of my previous
> patch to handle errors when setting configs. Back in September
> I've posted a single patch to handle errors when
> `install_branch_config` fails due to configuration failures [1].

Thanks for following up.

Having read through the series, I don't see anything _too_ wrong with
it. And certainly catching these errors and dying is better than letting
them go unnoticed.

Regarding this:

> Version two of this patch is somewhat more involved in that I
> tried to track down all relevant places where we set configs
> without checking for error conditions. My current approach to
> most of those cases is to just die with an error message, this
> remains up to discussion though for the individual cases.

I was a little surprised to see all of the effort in patch 2 to carry
the return value up the call stack, just to die a little later. Having
re-read our original thread, I did say that possibly "checkout -b"
should not directly die when failing to set the upstream. But looking at
the code again and thinking on it more, I don't really think that buys
us anything interesting (unless it is to roll back the branch creation,
but as before, I don't think it's really worth the effort).

So I wondered if patch 2 could simply use the "or_die" variant.

Which then made me wonder: doesn't basically everybody want to die if
setting config fails? The exception might be builtin/config.c, just
because it wants to return a custom exit code for some errors.

So would this series be a lot more pleasant if we went the other way?
That is, make git_config_set() die by default, and add a "_gently" form.

The end result is roughly the same, but it's a lot less churn, and it's
more likely for new callers to get it right, because they have to go the
extra mile to ignore the error. I say "roughly" because it treats cases
we missed as "die", whereas yours leaves them as "ignore". I find it
highly unlikely that any of them actually _want_ the ignore behavior,
though.

I'm just pondering, though. I don't find the "or_die" variant bad at
all, so if you really prefer it, I don't mind.

Just to get a sense of what the reverse would look like, I worked up the
patch below (which compiles but does not link, as I did not actually
implement the "gently" form). Some error-checking call-sites are
converted to the "die" form, because that's essentially what happens
anyway (and I'd venture to say that the config code can provide a much
better error message).

---
diff --git a/builtin/branch.c b/builtin/branch.c
index 3f6c825..4ab8b35 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -570,7 +570,6 @@ static const char edit_description[] = "BRANCH_DESCRIPTION";
 
 static int edit_branch_description(const char *branch_name)
 {
-   int status;
struct strbuf buf = STRBUF_INIT;
struct strbuf name = STRBUF_INIT;
 
@@ -595,11 +594,10 @@ static int edit_branch_description(const char 
*branch_name)
strbuf_stripspace(, 1);
 
strbuf_addf(, "branch.%s.description", branch_name);
-   status = git_config_set(name.buf, buf.len ? buf.buf : NULL);
+   git_config_set(name.buf, buf.len ? buf.buf : NULL);
strbuf_release();
strbuf_release();
-
-   return status;
+   return 0;
 }
 
 int cmd_branch(int argc, const char **argv, const char *prefix)
diff --git a/builtin/config.c b/builtin/config.c
index adc7727..2e6fd3c 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -582,7 +582,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
check_write();
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
-   ret = git_config_set_in_file(given_config_source.file, argv[0], 
value);
+   ret = git_config_set_in_file_gently(given_config_source.file, 
argv[0], value);
if (ret == CONFIG_NOTHING_SET)
error("cannot overwrite multiple values with a single 
value\n"
"   Use a regexp, --add or --replace-all to change 
%s.", argv[0]);
@@ -637,7 +637,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
return 
git_config_set_multivar_in_file(given_config_source.file,
   argv[0], NULL, 
argv[1], 0);
else
-   return git_config_set_in_file(given_config_source.file,
+   return 
git_config_set_in_file_gently(given_config_source.file,
  argv[0], NULL);
}
else if (actions == ACTION_UNSET_ALL) {
diff --git a/builtin/remote.c b/builtin/remote.c
index 2b2ff9b..0f69c30 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -197,8 +197,7 @@ static int add(int argc, const char **argv)

[PATCH v2] convert: legitimately disable clean/smudge filter with an empty override

[larsxschneider]

From: Lars Schneider 

diff to v1:
* improve commit message (Thanks Junio & Torsten)
* check for empty filter strings in apply_filter to catch all use cases (Thanks 
Peff)
* use more idiomatic style to check for an empty string (Thanks Eric)
* use test_config/test_config_global to set configs (Thanks Eric)
* use test_must_be_empty to check for empty err file (Thanks Eric)

Cheers,
Lars


Lars Schneider (1):
  convert: legitimately disable clean/smudge filter with an empty
override

 convert.c |  2 +-
 t/t0021-conversion.sh | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

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

[PATCH v2] convert: legitimately disable clean/smudge filter with an empty override

[larsxschneider]

From: Lars Schneider 

If the clean/smudge command of a Git filter driver (filter..smudge and
filter..clean) is set to an empty string ("") and the filter driver is
not required (filter..required=false) then Git will run successfully.
However, Git will print an error for every file that is affected by the filter.

Teach Git to consider an empty clean/smudge filter as legitimately disabled
and do not print an error message if the filter is not required.

Signed-off-by: Lars Schneider 
---
 convert.c |  2 +-
 t/t0021-conversion.sh | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/convert.c b/convert.c
index 814e814..02d5f1e 100644
--- a/convert.c
+++ b/convert.c
@@ -395,7 +395,7 @@ static int apply_filter(const char *path, const char *src, 
size_t len, int fd,
struct async async;
struct filter_params params;
 
-   if (!cmd)
+   if (!cmd || !*cmd)
return 0;
 
if (!dst)
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 718efa0..7bac2bc 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -252,4 +252,20 @@ test_expect_success "filter: smudge empty file" '
test_cmp expected filtered-empty-in-repo
 '
 
+test_expect_success 'disable filter with empty override' '
+   test_config_global filter.disable.smudge false &&
+   test_config_global filter.disable.clean false &&
+   test_config filter.disable.smudge false &&
+   test_config filter.disable.clean false &&
+
+   echo "*.disable filter=disable" >.gitattributes &&
+
+   echo test >test.disable &&
+   git -c filter.disable.clean= add test.disable 2>err &&
+   test_must_be_empty err &&
+   rm -f test.disable &&
+   git -c filter.disable.smudge= checkout -- test.disable 2>err &&
+   test_must_be_empty err
+'
+
 test_done
-- 
2.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

Re: [PATCH] pass transport verbosity down to git_connect

[Junio C Hamano]

Jeff King  writes:

> On Thu, Jan 28, 2016 at 07:19:30PM -0800, Junio C Hamano wrote:
>
>> I just reviewed the output that are protected by CONNECT_VERBOSE;
>> they look somewhere between pure debugging aid (like the protocol
>> dump that are shown by "fetch -vv") and progress display, and at
>> least to me they are much closer to the latter than the former, in
>> the sense that they are not _so_ annoying as the protocol dump that
>> are clearly not meant for the end users, and that they say "I am
>> looking up this host's address", "Now connecting to this host:port",
>> etc.
>> 
>> So, I personally find this addtional output not _too_ bad if we give
>> it with "fetch -v" (not limiting to "fetch -vv").
>
> Yeah, I do not feel that strongly, and am OK if it is attached to a
> single "-v". I don't think we make any promises about scraping stderr,
> so it is really just about end-user experience.  It is mostly just my
> gut feeling on what I'd expect based on other parts of git (especially
> "fetch -vv" in other circumstances).

Yeah, after re-reading the messages in this thread, I realize that I
missed the fact that you do consider these CONNECT_VERBOSE messages
as debugging aid and from that point of view "fetch -v" that shows
these messagse in addition to what you get from "fetch" may be a bad
idea.

But after inspecting what CONNECT_VERBOSE would add to the output, I
am inclined to say that, especially if some of these steps can
exhibit multi-second stalls, they fall more into the "progress
indicator" (aka "do not worry, we are not stuck, be patient")
category than "debugging aid" category.  The former includes
"remote: Counting objects..." that is shown by default (you need to
give --quiet to squelch).  So I think it is OK to show the
CONNECT_VERBOSE messages with "fetch -v"; if somebody feels strongly
that these messages should be shown unless --quiet is given, I might
even be persuaded to agree, but I am not that somebody, so...
--
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] pass transport verbosity down to git_connect

[Jeff King]

On Fri, Jan 29, 2016 at 09:34:27AM -0800, Junio C Hamano wrote:

> Yeah, after re-reading the messages in this thread, I realize that I
> missed the fact that you do consider these CONNECT_VERBOSE messages
> as debugging aid and from that point of view "fetch -v" that shows
> these messagse in addition to what you get from "fetch" may be a bad
> idea.
> 
> But after inspecting what CONNECT_VERBOSE would add to the output, I
> am inclined to say that, especially if some of these steps can
> exhibit multi-second stalls, they fall more into the "progress
> indicator" (aka "do not worry, we are not stuck, be patient")
> category than "debugging aid" category.

OK, I can buy that line of reasoning (and I agree it implies showing
with a single "-v").

-Peff
--
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] convert: legitimately disable clean/smudge filter with an empty override

[Junio C Hamano]

larsxschnei...@gmail.com writes:

> From: Lars Schneider 
>
> If the clean/smudge command of a Git filter driver (filter..smudge and
> filter..clean) is set to an empty string ("") and the filter driver is
> not required (filter..required=false) then Git will run successfully.
> However, Git will print an error for every file that is affected by the 
> filter.
>
> Teach Git to consider an empty clean/smudge filter as legitimately disabled
> and do not print an error message if the filter is not required.
>
> Signed-off-by: Lars Schneider 
> ---
>  convert.c |  2 +-
>  t/t0021-conversion.sh | 16 
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/convert.c b/convert.c
> index 814e814..02d5f1e 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -395,7 +395,7 @@ static int apply_filter(const char *path, const char 
> *src, size_t len, int fd,
>   struct async async;
>   struct filter_params params;
>  
> - if (!cmd)
> + if (!cmd || !*cmd)
>   return 0;

This is certainly simpler than v1.  I was initially worried about
the fact that slightly changes the semantics around the "required"
variable relative to v1, which said:

if (ca.drv && ca.drv->clean && *ca.drv->clean) {
filter = ca.drv->clean;
required = ca.drv->required;
}
ret |= apply_filter(path, src, len, -1, dst, filter);
if (!ret && required)
die;

but in v2, this part of the code is just as before, i.e.

if (ca.drv) {
filter = ca.drv->clean;
required = ca.drv->required;
}
ret |= apply_filter(path, src, len, -1, dst, filter);
if (!ret && required)
die;

So unlike v1, 'required' is set to true in the function, which is a
good thing, but because in v2, apply_filter knows that an extrernal
filter command that is an empty string is a no-op success, the above
codepath behaves identically to v1 when observed from outside, i.e.
"an empty string given as clean/smudge filter is a no-op success".

Good.

By the way, I find it somewhat annoying to see "legitimately" twice
in the log message.  It makes it sound like there are legitimate way
and not-so-kosher way to disable the filters.  Perhaps something
like this instead?

-- >8 --
convert: treat an empty string for clean/smudge filters as "cat"

Once a lower-priority configuration file defines a clean or smudge
filter, there is no convenient way to override it.  Even though the
configuration mechanism implements "the last one wins" semantics,
you cannot set them to an empty string and expect them to work, as
apply_filter() would try to run the empty string as an external
command and fail.  The conversion is not done, but the function
would still report a failure to convert.

Even though resetting the variable to "cat" (i.e. pass the data back
as-is and report success) is an obvious and a viable way to solve
this, it is wasteful to spawn an external process just as a
workaround.

Instead, teach apply_filter() to treat an empty string given as a
filter means the input must be returned as-is without conversion,
and the operation must always succeed.
-- >8 --

>  
>   if (!dst)
> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> index 718efa0..7bac2bc 100755
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
> @@ -252,4 +252,20 @@ test_expect_success "filter: smudge empty file" '
>   test_cmp expected filtered-empty-in-repo
>  '
>  
> +test_expect_success 'disable filter with empty override' '
> + test_config_global filter.disable.smudge false &&
> + test_config_global filter.disable.clean false &&
> + test_config filter.disable.smudge false &&
> + test_config filter.disable.clean false &&
> +
> + echo "*.disable filter=disable" >.gitattributes &&
> +
> + echo test >test.disable &&
> + git -c filter.disable.clean= add test.disable 2>err &&
> + test_must_be_empty err &&
> + rm -f test.disable &&
> + git -c filter.disable.smudge= checkout -- test.disable 2>err &&
> + test_must_be_empty err
> +'
> +
>  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: Bugs in git filter-branch (git replace related)

[Anatoly Borodin]

Hi Jeff,


I've created a gist with the script
https://gist.github.com/anatolyborodin/6505a364a68584f13846

I've added some changes and a second test (will be discussed in the
comments).


Jeff King  wrote:
> I'm not sure if this is a bug or not. The "empty commit" check works by
> checking the tree sha1s, without doing a full diff respecting replace
> refs.
> 
> You're expecting git to notice a tree change, even though it never even
> examined the tree in the first place (because you didn't give it a tree
> or index filter).

When git-filter-branch(1) says "If you have any grafts or replacement
refs defined, running this command will make them permanent.", and it
doesn't work like that because of some optimization, it *is* a bug.

> Try:
> 
>   git filter-branch --prune-empty --tree-filter true master
> 
> which will force git to go through the motions of checking out the
> replaced content and re-examining it.

Thank you, I've added this command to the script, and it works! I think
it should be added to git-filter-branch(1), if there is no other way to
rewrite the optimization.

>> Bug 2: the replace refs are not ignored (they can epresent blobs, trees etc,
>> but even if they represent commits - should they be rewritten?).
> 
> You told it "--all", which is passed to rev-list, where it means "all
> refs". I agree that running filter-branch on refs/replace is probably
> not going to yield useful results, but I'm not sure if it is
> filter-branch's responsibility to second-guess the rev-list options.

Look how `git log --all` works (see the second test in the script): it
ignores (without any messages) the blobs, and writes only the commits.
For example, the same commit log message is printed twice in the second
testcase.

Maybe it makes sence, I don't know. I would suggest that all
refs/replace/* heads should be ignored by `git log`. `git rev-list
--no-replace` maybe?

> Probably the documentation for filter-branch should recommend
> "--branches --tags" instead of "--all", though.

Or redefine `--all` as "all refs excepting refs/replace/*". Who would
really want to run `--all` the way it works now?

The blobs replaces should be ignored, as in `git log --all`. Is there
any reason to rewrite refs/rebase/hash if it's a replace commit?


-- 
Mit freundlichen Grüßen,
Anatoly Borodin

--
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] push --force-with-lease: Fix ref status reporting

[Andrew Wheeler]

> These all look OK (I am not sure about message i18n, though).
>
> Do we not test a case where --force-with-lease push is rejected due
> to REF_STATUS_REJECT_STALE?

Good idea, new patch on the way.


-andrew
--
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 v4] push --force-with-lease: Fix ref status reporting

[Andrew Wheeler]

From: Andrew Wheeler 

The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.

Modify the --force-with-lease ref status logic to leverage
the --force ref status logic when the "lease" conditions
are met.

Also, enhance tests to validate output status reporting.

Signed-off-by: Andrew Wheeler 
---
 remote.c| 15 ---
 t/t5533-push-cas.sh | 15 ++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/remote.c b/remote.c
index 9d34b5a..3ceac07 100644
--- a/remote.c
+++ b/remote.c
@@ -1545,11 +1545,8 @@ void set_ref_status_for_push(struct ref *remote_refs, 
int send_mirror,
}
 
/*
-* Bypass the usual "must fast-forward" check but
-* replace it with a weaker "the old value must be
-* this value we observed".  If the remote ref has
-* moved and is now different from what we expect,
-* reject any push.
+* If the remote ref has moved and is now different
+* from what we expect, reject any push.
 *
 * It also is an error if the user told us to check
 * with the remote-tracking branch to find the value
@@ -1560,10 +1557,14 @@ void set_ref_status_for_push(struct ref *remote_refs, 
int send_mirror,
if (ref->expect_old_no_trackback ||
oidcmp(>old_oid, >old_oid_expect))
reject_reason = REF_STATUS_REJECT_STALE;
+   else
+   /* If the ref isn't stale then force the 
update. */
+   force_ref_update = 1;
}
 
/*
-* The usual "must fast-forward" rules.
+* If the update isn't already rejected then check
+* the usual "must fast-forward" rules.
 *
 * Decide whether an individual refspec A:B can be
 * pushed.  The push will succeed if any of the
@@ -1582,7 +1583,7 @@ void set_ref_status_for_push(struct ref *remote_refs, int 
send_mirror,
 * passing the --force argument
 */
 
-   else if (!ref->deletion && !is_null_oid(>old_oid)) {
+   if (!reject_reason && !ref->deletion && 
!is_null_oid(>old_oid)) {
if (starts_with(ref->name, "refs/tags/"))
reject_reason = 
REF_STATUS_REJECT_ALREADY_EXISTS;
else if (!has_object_file(>old_oid))
diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
index c402d8d..c732012 100755
--- a/t/t5533-push-cas.sh
+++ b/t/t5533-push-cas.sh
@@ -25,7 +25,8 @@ test_expect_success 'push to update (protected)' '
(
cd dst &&
test_commit D &&
-   test_must_fail git push --force-with-lease=master:master origin 
master
+   test_must_fail git push --force-with-lease=master:master origin 
master 2>err &&
+   grep "stale info" err
) &&
git ls-remote . refs/heads/master >expect &&
git ls-remote src refs/heads/master >actual &&
@@ -37,7 +38,8 @@ test_expect_success 'push to update (protected, forced)' '
(
cd dst &&
test_commit D &&
-   git push --force --force-with-lease=master:master origin master
+   git push --force --force-with-lease=master:master origin master 
2>err &&
+   grep "forced update" err
) &&
git ls-remote dst refs/heads/master >expect &&
git ls-remote src refs/heads/master >actual &&
@@ -101,7 +103,8 @@ test_expect_success 'push to update (allowed, tracking)' '
(
cd dst &&
test_commit D &&
-   git push --force-with-lease=master origin master
+   git push --force-with-lease=master origin master 2>err &&
+   ! grep "forced update" err
) &&
git ls-remote dst refs/heads/master >expect &&
git ls-remote src refs/heads/master >actual &&
@@ -114,7 +117,8 @@ test_expect_success 'push to update (allowed even though 
no-ff)' '
cd dst &&
git reset --hard HEAD^ &&
test_commit D &&
-   git push --force-with-lease=master origin master
+   git push --force-with-lease=master origin master 2>err &&
+   grep "forced update" err
) &&
git ls-remote dst refs/heads/master >expect &&
git ls-remote src refs/heads/master >actual &&
@@ -147,7 +151,8 @@ test_expect_success 'push to delete (allowed)' '
setup_srcdst_basic &&
(
cd dst &&
-   git push 

Re: Bugs in git filter-branch (git replace related)

[Jeff King]

On Fri, Jan 29, 2016 at 06:24:07PM +, Anatoly Borodin wrote:

> > You're expecting git to notice a tree change, even though it never even
> > examined the tree in the first place (because you didn't give it a tree
> > or index filter).
> 
> When git-filter-branch(1) says "If you have any grafts or replacement
> refs defined, running this command will make them permanent.", and it
> doesn't work like that because of some optimization, it *is* a bug.

I think the bug is in the documentation. That has always worked for
commit grafts and replacements, but never for blob and tree replacements
(and in fact, filter-branch quite predates refs/replace).

I don't think this is just an optimization; filter-branch does not touch
or rewrite bits that you did not ask it to touch, and that is a
user-visible behavior.

> Thank you, I've added this command to the script, and it works! I think
> it should be added to git-filter-branch(1), if there is no other way to
> rewrite the optimization.

Yeah, I agree.  Documentation patches are welcome.

I think with an "--index-filter", you could cement a replacement tree
into place, but you need a "--tree-filter" to do a blob replacement
(because otherwise we insert only the name of the blob sha1 into the
index).

> > You told it "--all", which is passed to rev-list, where it means "all
> > refs". I agree that running filter-branch on refs/replace is probably
> > not going to yield useful results, but I'm not sure if it is
> > filter-branch's responsibility to second-guess the rev-list options.
> 
> Look how `git log --all` works (see the second test in the script): it
> ignores (without any messages) the blobs, and writes only the commits.
> For example, the same commit log message is printed twice in the second
> testcase.

I'm not sure what you mean here. "git log --all" is not looking at blobs
at all (you did not ask it do any diffs, nor simplify history based on
TREESAME commits). The "--all" here means "start traversing from commits
found at all ref tips". It _does_ look at refs/replace, but there are no
commits to traverse there.

Likewise, "git rev-list --all" would not show any. But "git rev-list
--objects --all" would (both the refs/replace tips, as well as objects
reachable from the other commits).

> Maybe it makes sence, I don't know. I would suggest that all
> refs/replace/* heads should be ignored by `git log`. `git rev-list
> --no-replace` maybe?

It is too late for that without an extra option. "rev-list --all"
already has a well-established meaning, and changing it would break
other uses (e.g., commit reachability done during object transfer and
repacking, not to mention any third-party scripts). But...

> > Probably the documentation for filter-branch should recommend
> > "--branches --tags" instead of "--all", though.
> 
> Or redefine `--all` as "all refs excepting refs/replace/*". Who would
> really want to run `--all` the way it works now?

If you mean "rev-list --all", then: lots of things that aren't
filter-branch. :)

If we were to change anything, it would be to intercept "--all" in
filter-branch and rewrite it to "--exclude=refs/replace/* --all". I'm
slightly negative on that, just because we advertise filter-branch as
taking arbitrary rev-list args, and this is violating that. I think I'd
be more in favor if it were done robustly and clearly, like:

  - teach rev-list --all-does-not-include-refs-replace (but with a less
horrible name)

  - advertise that filter-branch always passes that option to rev-list

Then at least it is robust (we are not mucking with rev-list options,
which we cannot do completely accurately without having the full
knowledge of all of its options), and simple to explain to the user (if
they want to work around it, they simple add "--glob=refs/replace/*" to
their invocation).

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

clones over rsync broken?

[Eric Wong]

I have not used rsync remotes in ages, but I was working on the
patch for -4/-6 support and decided to test it against rsync.kernel.org

Cloning git.git takes forever and failed with:

$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git
Checking connectivity... fatal: bad object 
ecdc6d8612df80e871ed34bb6c3b01b20b0b82e6
fatal: remote did not send all necessary objects

git.git is gigantic and I haven't looked closely, and that may not be
a git bug...

However, trying to clone a smaller repo like pahole.git via rsync fails
differently; this looks more like a git bug:

$ git clone rsync://rsync.kernel.org/pub/scm/devel/pahole/pahole.git
fatal: Multiple updates for ref 'refs/remotes/origin/master' not allowed.

Using rsync(1) manually to grab pahole.git and inspecting the bare
repo with yields no anomalies with "git fsck --full".
$GIT_DIR/info/refs and $GIT_DIR/packed-refs both look fine, but
perhaps it's confused by the existence of $GIT_DIR/refs/heads/master
as a loose ref?

I tried dumping the refnames with the following patch and can see
refs/remotes/origin/master is the only duplicated ref:

diff --git a/refs/files-backend.c b/refs/files-backend.c
index c648b5e..e0cb0ab 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -3112,6 +3112,8 @@ static int ref_update_reject_duplicates(struct 
string_list *refnames,
int i, n = refnames->nr;
 
assert(err);
+   for (i = 0; i < n; i++)
+   fprintf(stderr, "ref: %s\n", refnames->items[i].string);
 
for (i = 1; i < n; i++)
if (!strcmp(refnames->items[i - 1].string, 
refnames->items[i].string)) {

And the output is:

ref: refs/remotes/origin/master
ref: refs/remotes/origin/master
ref: refs/tags/v1.0
ref: refs/tags/v1.1
ref: refs/tags/v1.10
ref: refs/tags/v1.2
ref: refs/tags/v1.3
ref: refs/tags/v1.4
ref: refs/tags/v1.5
ref: refs/tags/v1.6
ref: refs/tags/v1.7
ref: refs/tags/v1.8
ref: refs/tags/v1.8pre1
ref: refs/tags/v1.9

Not sure what exactly is going on, my git internal API knowledge is not
great.  Anyways, this is without any of my pending patches, and I was
also able to reproduce a slightly different error with the Debian wheezy
version (1.7.10.4) with:

fatal: Duplicated ref, and SHA1s don't match: refs/remotes/origin/master
--
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] transport: drop support for git-over-rsync

[Jeff King]

On Sat, Jan 30, 2016 at 02:21:26AM -0500, Jeff King wrote:

> Even the commit porting rsync over to C from shell (cd547b4)
> lists it as deprecated! So between the 10 years of informal
> warnings, and the fact that it has been severely broken
> since 2007, it's probably safe to simply remove it without
> further deprecation warnings.

Obviously it would not be the end of the world to start with a
warning("git-over-rsync is going away!") patch, or to mention it in the
release notes and hold this patch back for a version or two. But after
seeing the extent of the breakage, I can't believe anybody has used it
for years. But I'm also open to erring on the conservative side.

> ---
>  Documentation/config.txt   |   2 +-
>  Documentation/git-bundle.txt   |   2 +-
>  Documentation/git-clone.txt|   3 +-
>  Documentation/git-repack.txt   |   2 +-
>  Documentation/git.txt  |   2 -
>  Documentation/gitcore-tutorial.txt |  18 +-
>  Documentation/gittutorial.txt  |   2 +-
>  Documentation/urls.txt |   6 +-
>  t/t5510-fetch.sh   |  36 
>  transport.c| 332 
> +
>  10 files changed, 10 insertions(+), 395 deletions(-)

I cleaned up all of the documentation references I could find, except
one: the git-svn manual notes that because SVN metadata is kept outside
of refs, you should use rsync for cloning. I'm not sure what to
recommend there. I don't eve nthink that "git clone rsync://" would copy
that metadata. So perhaps it just meant "rsync the whole thing yourself"
(in which case it is OK to leave it).

> @@ -984,11 +658,7 @@ struct transport *transport_get(struct remote *remote, 
> const char *url)
>   if (helper) {
>   transport_helper_init(ret, helper);
>   } else if (starts_with(url, "rsync:")) {
> - transport_check_allowed("rsync");
> - ret->get_refs_list = get_refs_via_rsync;
> - ret->fetch = fetch_objs_via_rsync;
> - ret->push = rsync_transport_push;
> - ret->smart_options = NULL;
> + die("git-over-rsync is no longer supported");

I added this as a convenience to anybody who does try to use it
(otherwise they get a more confusing "eh, what is rsync" message).

But if we drop this "if" entirely, then somebody can ship
git-remote-rsync, if they really wanted to (you can use it either way as
"rsync::whatever" but this blocks the fallback of "rsync:whatever").

-Peff
--
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: fast-import fails in read-only tree

[Jeff King]

On Fri, Jan 29, 2016 at 09:28:44AM -0500, Stefan Monnier wrote:

> > The primary goal of fast-import is to write that packfile.  It kind of
> > sounds like you are using the wrong tool for the job.
> 
> Yes, I realize that.  But in some cases it's the best tool available.
> `fast-import' is very close to being a "generic access API" which can be
> used instead of something like libgit.  I think it'd be good to push it
> yet a bit closer.

I'm not sure I agree. Git tries to make its innards available via
flexible plumbing commands. If we're not succeeding, I think that should
be fixed, rather than trying to shoe-horn an unrelated command to do the
job, even if it would be less code.

> > Can you elaborate on what you are sending to fast-import (preferably
> > with a concrete example)?
> 
> I'm sending a stream of "progress ; cat-blob ", basically.
> 
> The concrete example is in [BuGit](https://gitlab.com/monnier/bugit),
> see for example 
> https://gitlab.com/monnier/bugit/commit/3678dcb8830a9c79c6f3404d75d63e6dd07bfe4c

You can use custom cat-file formatting to output your "name" strings as
part of the same field. IOW, something like:

  git cat-file -p refs/heads/bugit-master:numbers |
  awk '{print $3 " " $4 }' |
  git cat-file --batch="%(rest)" |
  while read number; do
read id; # assuming blob contents are single-line
read _junk; # assumes blob ended in its own newline
$fun "$id" "$number"
  done

That's from a fairly cursory reading of that bugit patch, though, so I
might be missing some requirement.

> Yes, I switched to using "cat-file --batch" instead, but it's less
> convenient (I can't intersperse ad-hoc info in the output, the way I can
> with "progress" in fast-import) and there are cases where the list of
> files I need to extract cannot be determined without first looking at
> some of those extracted files (I currently have been able to avoid
> this in BuGit, luckily).

I think the example above should handle the "intersperse" thing.

If you're really going to do a lot of interactive back-and-forth access
of objects, though, I think you want to set up pipes to cat-file. It's a
little tedious to allocate fifos, but something like:

  mkfifo in out
  (exec git cat-file --batch out) &
  exec 8>in
  exec 9&8
  read mode type size <&9
  read content ;# or read $size, or read until newline
  echo $content >&8 ;# imagine content is another sha to look up
  ...read from &9, etc..

The fifos and numbered descriptors are annoying, but that's shell for
you. I suspect using "fast-import" wouldn't be much different.

One feature I do think would be useful (and almost implemented when I
added --batch-check=) is a formatter for the object content,
with a pretty modifier. I.e., it would be nice to do:

  echo $some_tree |
  git cat-file --batch-check="%(objectsize:pretty) %(contents:pretty)"

to work as the rough equivalent of "git cat-file -p" (but here you could
feed multiple trees and get multiple answers).

-Peff
--
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] transport: drop support for git-over-rsync

[Jeff King]

On Sat, Jan 30, 2016 at 01:30:36AM -0500, Jeff King wrote:

> I guess that doesn't handle subsequent fetches. But
> really...git-over-rsync is just an awful protocol. Nobody should be
> using it. Having looked at it in more detail, I'm more in favor than
> ever of removing it.

So here it is. I think this hasn't happened before simply because nobody
bothered. I tried to dig up relevant discussions; see below.

Also, it's Friday night and I'm reading (and enjoying!) 10-year-old
discussions on the git mailing list. That's got to be worth some kind of
nerd cred.

-- >8 --
Subject: transport: drop support for git-over-rsync

The git-over-rsync protocol is inefficient and broken, and
has been for a long time. It transfers way more objects than
it needs (grabbing all of the remote's "objects/",
regardless of which objects we need). It does its own ad-hoc
parsing of loose and packed refs from the remote, but
doesn't properly override packed refs with loose ones,
leading to garbage results (e.g., expecting the other side
to have an object pointed to by a stale packed-refs entry,
or complaining that the other side has two copies of the
refs[1]).

This latter breakage means that nobody could have
successfully pulled from a moderately active repository
since cd547b4 (fetch/push: readd rsync support, 2007-10-01).

We never made an official deprecation notice in the release
notes for git's rsync protocol, but the tutorial has marked
it as such since 914328a (Update tutorial., 2005-08-30).
And on the mailing list as far back as Oct 2005, we can find
Junio mentioning it as having "been deprecated for quite
some time."[2,3,4]. So it was old news then; cogito had
deprecated the transport in July of 2005[5] (though it did
come back briefly when Linus broke git-http-pull!).

Of course some people professed their love of rsync through
2006, but Linus clarified in his usual gentle manner[6]:

  > Thanks!  This is why I still use rsync, even though
  > everybody and their mother tells me "Linus says rsync is
  > deprecated."

  No. You're using rsync because you're actively doing
  something _wrong_.

The deprecation sentiment was reinforced in 2008, with a
mention that cloning via rsync is broken (with no fix)[7].

Even the commit porting rsync over to C from shell (cd547b4)
lists it as deprecated! So between the 10 years of informal
warnings, and the fact that it has been severely broken
since 2007, it's probably safe to simply remove it without
further deprecation warnings.

[1] http://article.gmane.org/gmane.comp.version-control.git/285101
[2] http://article.gmane.org/gmane.comp.version-control.git/10093
[3] http://article.gmane.org/gmane.comp.version-control.git/17734
[4] http://article.gmane.org/gmane.comp.version-control.git/18911
[5] http://article.gmane.org/gmane.comp.version-control.git/5617
[6] http://article.gmane.org/gmane.comp.version-control.git/19354
[7] http://article.gmane.org/gmane.comp.version-control.git/103635

Signed-off-by: Jeff King 
---
 Documentation/config.txt   |   2 +-
 Documentation/git-bundle.txt   |   2 +-
 Documentation/git-clone.txt|   3 +-
 Documentation/git-repack.txt   |   2 +-
 Documentation/git.txt  |   2 -
 Documentation/gitcore-tutorial.txt |  18 +-
 Documentation/gittutorial.txt  |   2 +-
 Documentation/urls.txt |   6 +-
 t/t5510-fetch.sh   |  36 
 transport.c| 332 +
 10 files changed, 10 insertions(+), 395 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 877cbc8..65fe684 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2088,7 +2088,7 @@ pack.indexVersion::
larger than 2 GB.
 +
 If you have an old Git that does not understand the version 2 `*.idx` file,
-cloning or fetching over a non native protocol (e.g. "http" and "rsync")
+cloning or fetching over a non native protocol (e.g. "http")
 that will copy both `*.pack` file and corresponding `*.idx` file from the
 other side may give you a repository that cannot be accessed with your
 older version of Git. If the `*.pack` file is smaller than 2 GB, however,
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 0417562..3a8120c 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -20,7 +20,7 @@ DESCRIPTION
 Some workflows require that one or more branches of development on one
 machine be replicated on another machine, but the two machines cannot
 be directly connected, and therefore the interactive Git protocols (git,
-ssh, rsync, http) cannot be used.  This command provides support for
+ssh, http) cannot be used.  This command provides support for
 'git fetch' and 'git pull' to operate by packaging objects and references
 in an archive at the originating machine, then importing those into
 another repository using 'git fetch' and 'git pull'
diff --git 

Fwd:

[Ершова Нила]

Привет.

Ищите качественный сервис поиска клиентов?

Заказать и узнать тарифы можно по тел 8 961 136 35 21 

E-mail lady.lachina1...@mail.ru 

--
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: clones over rsync broken?

[Jeff King]

On Sat, Jan 30, 2016 at 12:41:41AM -0500, Jeff King wrote:

> It looks like this has been broken since cd547b4 (fetch/push: readd
> rsync support, 2007-10-01). The fix is just to ignore packed-refs
> entries which duplicate loose ones. But given the length of time this
> has been broken with nobody complaining, I have to wonder if it is
> simply time to retire the rsync protocol. Even if was made to work, it
> is a horribly inefficient protocol.

I took a look at whether there would be an easy fix. There are three
obvious ways to go about this:

  1. Use the loose/packed reading code from refs/files-backend.c.

 This would require some refactoring, as we currently assume we are
 either reading the refs for _this_ repository, or for a submodule.
 This is sort-of like reading a submodule, but I think there are a
 few rough edges.

 Worse, though, is that the upcoming pluggable refs work will
 probably require that submodules and the main repo have the same
 ref backend. I'm a little dubious of that requirement in general,
 but certainly it would be a show-stopper here.

  2. Create a "struct transport" for the tempdir holding the data we
 rsynced from the other side, and just treat it like a local repo.
 We already do something like this to handle object "alternates"
 repositories (and we run "upload-pack" on the other directory and
 parse it just like a real remote).

 Unfortunately, what we bring over in get_refs_via_pack is not
 enough for this to work. It's _just_ the refs/ directories. We can
 use "git init" to make it more like a real repo, but ultimately we
 don't have any objects, so upload-pack will complain.

 We could fix that by just rsyncing the objects down at this stage,
 too. It's not like git is careful enough to do a real "what do we
 need" walk like it does for dumb-http. But we would end up rsyncing
 even in cases where we didn't need _any_ objects, though that is
 probably a vast minority case.

  3. Just teach the local ad-hoc loose and packed readers to do the
 proper deduplication. I started on this, but then realized that we
 really do implement a from-scratch packed-refs reader here. And
 it's missing some features, like parsing peeled tags.

 So it really would want to call into the regular packed-refs
 parsing code, which requires more refactoring as in (1).

Of all of these, I think (2) is the closest to sane, because it lets
upload-pack do the heavy-lifting, meaning we can understand whatever
formats we rsync from the other side. But given that rsync is already
naive about what objects it pulls (i.e., it gets everything), I have to
really question whether there is any value in using git-over-rsync
versus just:

  rsync $src tmp/
  git clone tmp my-repo ;# will hard-link, no extra space needed!
  rm -rf $tmp

I guess that doesn't handle subsequent fetches. But
really...git-over-rsync is just an awful protocol. Nobody should be
using it. Having looked at it in more detail, I'm more in favor than
ever of removing it.

-Peff
--
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: clones over rsync broken?

[Jeff King]

On Sat, Jan 30, 2016 at 05:11:33AM +, Eric Wong wrote:

> I have not used rsync remotes in ages, but I was working on the
> patch for -4/-6 support and decided to test it against rsync.kernel.org
> 
> Cloning git.git takes forever and failed with:

No kidding. There are over 95,000 unreachable loose objects consuming a
gigabyte. The rsync transport blindly pulls all of the data over, with
no idea that it doesn't need most of it.

> $ git clone rsync://rsync.kernel.org/pub/scm/git/git.git
> Checking connectivity... fatal: bad object 
> ecdc6d8612df80e871ed34bb6c3b01b20b0b82e6
> fatal: remote did not send all necessary objects

All those objects, and we still manage to miss one. :)

Interestingly, that object does not seem to exist at all on the remote!
I think this is the same bug as the one below. Read on...

> However, trying to clone a smaller repo like pahole.git via rsync fails
> differently; this looks more like a git bug:
> 
> $ git clone rsync://rsync.kernel.org/pub/scm/devel/pahole/pahole.git
> fatal: Multiple updates for ref 'refs/remotes/origin/master' not allowed.
> 
> Using rsync(1) manually to grab pahole.git and inspecting the bare
> repo with yields no anomalies with "git fsck --full".
> $GIT_DIR/info/refs and $GIT_DIR/packed-refs both look fine, but
> perhaps it's confused by the existence of $GIT_DIR/refs/heads/master
> as a loose ref?

Yes, that's exactly what's going on. In get_refs_via_rsync, we blindly
concatenate the list of loose refs and packed refs. But that's not
right, and never has been. If the same ref exists in both stores, the
loose ref takes precedence (that is how we can write new refs without
having to rewrite the whole packed-refs file).

So we erroneously believe that refs/heads/master exists _twice_ on the
remote, with two different values (and try to store it twice as
refs/remotes/origin/master). But we should be accepting only the loose
value.

This explains the git.git problem, too. There are two entries for
refs/heads/pu: one loose and one in packed-refs. The latter is a stale,
older value, and should never be looked at. But because pu gets rewound,
its older values are not necessarily reachable and may even have been
pruned!

So no, we do not have ecdc6d86, but neither does the upstream, and
nothing is referencing it.

It looks like this has been broken since cd547b4 (fetch/push: readd
rsync support, 2007-10-01). The fix is just to ignore packed-refs
entries which duplicate loose ones. But given the length of time this
has been broken with nobody complaining, I have to wonder if it is
simply time to retire the rsync protocol. Even if was made to work, it
is a horribly inefficient protocol.

-Peff
--
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 0/9] Handle errors when setting configs

[Junio C Hamano]

Jeff King  writes:

> The end result is roughly the same, but it's a lot less churn, and it's
> more likely for new callers to get it right, because they have to go the
> extra mile to ignore the error. I say "roughly" because it treats cases
> we missed as "die", whereas yours leaves them as "ignore". I find it
> highly unlikely that any of them actually _want_ the ignore behavior,
> though.

Yes, I like this approach better.  It admittedly is more risky in
that it would die if the conversion missed a case that should
ignore, but I suspect that such a breakage would be found rather
quickly (and the one that goes latent are the ones that do not
matter in practice because people would not encounter them).

> I'm just pondering, though. I don't find the "or_die" variant bad at
> all, so if you really prefer it, I don't mind.
>
> Just to get a sense of what the reverse would look like, I worked up the
> patch below (which compiles but does not link, as I did not actually
> implement the "gently" form). Some error-checking call-sites are
> converted to the "die" form, because that's essentially what happens
> anyway (and I'd venture to say that the config code can provide a much
> better error message).

This variant certainly looks nicer to me, for the reasons give above.
--
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: Gitignore file exceptions are not applied to untarcked files

[Junio C Hamano]

Assen Totin  writes:

> I'm not sure if the described issue is a bug or a feature; if it is the
> latter, please, excuse the report.
>
> I'm dealing with git 1.7.12.4. If this has been addressed in the later
> issue, please, point me so.

That is a bit too ancient version, so I am not sure how it behaved
back then.

> I'm only interested in /tracked_dir/.../config files. My .gitignore is as
> follows:
>
> # Ignore everything first
> *
> # Do not ignore tracked files
> !/tracked_dir/*/config
> # Don't ignore .gitignore
> !.gitignore
>
> This works fine until a new directory with a config file is created inside
> /tracked_dir:

I am not sure if that is "working fine".  First, aren't these 'config'
files tracked?  "!/tracked_dir/*/config" or whatever you have in the
gitignore files have no effect on what is already tracked.

That is, if you replace your .gitignore with a single line,

# ignore everything
*

your /tracked_dir/foo/config that is already in the index (i.e. "git
ls-files tracked_dir/foo/config" would show it) would not be ignored.

> Is it because the exclusion pattern is never
> applied to untracked files? Or is it because the directory new_subdir is
> itself untracked?

So my suspicion is that (1) you do see tracked_dir/subdir1/config is
not ignored not because of any of your !tracked_dir/*/config lines
but because tracked_dir/subdir1/config is already in the index, and
(2) your tracked_dir/new_subdir/config is shown as ignored because
it is not tracked yet, and '*' tells Git that new_subdir is ignored.

By the way, this area did have a recent regression at v2.7.0, to
which a fix is percolating down to the v2.7.x maintenance track.
--
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/2] stash: use "stash--helper"

[Junio C Hamano]

Thomas Gummerer  writes:

> Matthias, feel free to squash the following (or something similar) in
> when you re-roll.
>
> diff --git a/t/perf/p3000-stash.sh b/t/perf/p3000-stash.sh
> new file mode 100755
> index 000..e6e1153
> --- /dev/null
> +++ b/t/perf/p3000-stash.sh
> @@ -0,0 +1,20 @@
> +#!/bin/sh
> +
> +test_description="Test performance of git stash"
> +
> +. ./perf-lib.sh
> +
> +test_perf_default_repo
> +
> +file=$(git ls-files | tail -n 30 | head -1)

If you use "tail -n 30" not "tail -30", which is good manners, you
would want to be consistent and say "head -n 1".

> +
> +test_expect_success "prepare repository" "
> + echo x >$file
> +"
> +
> +test_perf "stash/stash pop" "
> + git stash &&
> + git stash pop
> +"
> +
> +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] mergetool: reorder vim/gvim buffers in three-way diffs

[Junio C Hamano]

Dickson Wong  writes:

> When invoking default (g)vimdiff three-way merge, the merged file is
> loaded as the first buffer but moved to the bottom as the fourth window.
> This causes a disconnect between vim commands that operate on window
> positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.
> do/dp).
>
> This change reorders the buffers to have the same index as windows while
> keeping the cursor default to the merged result as the bottom window.
>
> Signed-off-by: Dickson Wong 
> ---

David, I unfortunately do not use 'mergetools' myself and certainly
not vimdiff.

Opinions?

>  mergetools/vimdiff | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mergetools/vimdiff b/mergetools/vimdiff
> index 1ddfbfc..74ea6d5 100644
> --- a/mergetools/vimdiff
> +++ b/mergetools/vimdiff
> @@ -2,22 +2,22 @@ diff_cmd () {
>   "$merge_tool_path" -R -f -d \
>   -c 'wincmd l' -c 'cd $GIT_PREFIX' "$LOCAL" "$REMOTE"
>  }
>  
>  merge_cmd () {
>   touch "$BACKUP"
>   case "$1" in
>   gvimdiff|vimdiff)
>   if $base_present
>   then
> - "$merge_tool_path" -f -d -c 'wincmd J' \
> - "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
> + "$merge_tool_path" -f -d -c '4wincmd w | wincmd J' \
> + "$LOCAL" "$BASE" "$REMOTE" "$MERGED"
>   else
>   "$merge_tool_path" -f -d -c 'wincmd l' \
>   "$LOCAL" "$MERGED" "$REMOTE"
>   fi
>   ;;
>   gvimdiff2|vimdiff2)
>   "$merge_tool_path" -f -d -c 'wincmd l' \
>   "$LOCAL" "$MERGED" "$REMOTE"
>   ;;
>   gvimdiff3|vimdiff3)
--
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] convert: legitimately disable clean/smudge filter with an empty override

[Junio C Hamano]

Junio C Hamano  writes:

> Instead, teach apply_filter() to treat an empty string given as a
> filter means the input must be returned as-is without conversion,
> and the operation must always succeed.

Ugh, that was a non-sentence.  

  Instead, teach apply_filter() to treat an empty string as a no-op
  filter that always returns successfully its input as-is without
  conversion.

was what I meant to say.

> -- >8 --
>
>>  
>>  if (!dst)
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 718efa0..7bac2bc 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -252,4 +252,20 @@ test_expect_success "filter: smudge empty file" '
>>  test_cmp expected filtered-empty-in-repo
>>  '
>>  
>> +test_expect_success 'disable filter with empty override' '
>> +test_config_global filter.disable.smudge false &&
>> +test_config_global filter.disable.clean false &&
>> +test_config filter.disable.smudge false &&
>> +test_config filter.disable.clean false &&
>> +
>> +echo "*.disable filter=disable" >.gitattributes &&
>> +
>> +echo test >test.disable &&
>> +git -c filter.disable.clean= add test.disable 2>err &&
>> +test_must_be_empty err &&
>> +rm -f test.disable &&
>> +git -c filter.disable.smudge= checkout -- test.disable 2>err &&
>> +test_must_be_empty err
>> +'
>> +
>>  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

AW: [PATCH 1/2] stash--helper: implement "git stash--helper"

[Matthias Aßhauer]

> Hmph, why not have everything inside builtin/stash--helper.c?  I do not quite 
> see a point of having the other two "library-ish" looking files.
> 
> Also I personally feel that it would be easier to review when these two 
> patches are squashed into one.  I had to go back and forth while reading the 
> "non-patch" C function to see what logic from the scripted version it is 
> trying to replace.

I can certainly do that.

> This is meant to replace this sequence:
>
>   git read-tree --index-output="$TMPindex" -m $i_tree &&
>   GIT_INDEX_FILE="$TMPindex" &&
>   export GIT_INDEX_FILE &&
>   git diff --name-only -z HEAD -- >"$TMP-stagenames" &&
>   git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
>   git write-tree &&
>   rm -f "$TMPindex"
>
> And outside of this section of the script, $TMPindex is never looked at after 
> this part finishes (which is obvious as the last thing the section does is to 
> remove it).  As you are rewriting this whole section in C, you should wonder 
> if you can do it without using a temporary file in the filesystem at all.

I assumed the path to $TMPindex was still available in GIT_INDEX_FILE after 
this, as it gets exported, but I guess the surrounding $() imply a subshell.

> Honestly, I had high hopes after seeing the "we are rewriting it in C" but I 
> am not enthused after seeing this.  I was hoping that the rewritten version 
> would do this all in-core, by calling these functions that we already have:

These functions might be obvious to you, but I'm new to git's source code, so I 
worked with the things I found documented and those that were brought to my 
attention by Johannes Schindelin. The run-command API is documented and seemed 
to be the "official" method of calling any git commands from within native git  
code. On the other hand, the documentation for the in-core index API boils down 
to "TODO: document this". This lead me to believe I did this the intended way 
and just calling random functions that sound  similar to the  original command 
may be frowned upon at best.

> A C rewrite that works all in-core does not even need to write out a 
> temporary; it can just read the current index and do various things up to 
> writing the contents of the in-core index as a tree, and the result would be 
> correct as long as you do not forget *NOT* to write the in-core index out to 
> $GIT_INDEX_FILE.

I'll be working on a v2 that incorporates the feedback from you, Thomas 
Gummerer  and Stefan Beller then. Further feedback is of course welcome.

-Ursprüngliche Nachricht-
Von: Junio C Hamano [mailto:gits...@pobox.com] 
Gesendet: Freitag, 29. Januar 2016 00:06
An: Matthias Asshauer 
Cc: git@vger.kernel.org
Betreff: Re: [PATCH 1/2] stash--helper: implement "git stash--helper"

Matthias Asshauer  writes:

> From: Matthias Aßhauer 
>
> This patch implements a new "git stash--helper" builtin plumbing 
> command that will be used to migrate "git-stash.sh" to C.
>
> We start by implementing only the "--non-patch" option that will 
> handle the core part of the non-patch stashing.
>
> Signed-off-by: Matthias Aßhauer 
> ---
>  Makefile|  2 ++
>  builtin.h   |  1 +
>  builtin/stash--helper.c | 13 ++
>  git.c   |  1 +
>  stash.c | 65 
> +
>  stash.h | 11 +

Hmph, why not have everything inside builtin/stash--helper.c?  I do not quite 
see a point of having the other two "library-ish" looking files.

Also I personally feel that it would be easier to review when these two patches 
are squashed into one.  I had to go back and forth while reading the 
"non-patch" C function to see what logic from the scripted version it is trying 
to replace.

> diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c new 
> file mode 100644 index 000..542e782
> --- /dev/null
> +++ b/builtin/stash--helper.c
> @@ -0,0 +1,13 @@
> +#include "../stash.h"
> +#include 
> +
> +static const char builtin_stash__helper_usage[] = {
> + "Usage: git stash--helper --non-patch  "
> +};
> +
> +int cmd_stash__helper(int argc, const char **argv, const char 
> +*prefix) {
> + if (argc == 4 && !strcmp("--non-patch", argv[1]))
> + return stash_non_patch(argv[2], argv[3], prefix);
> + usage(builtin_stash__helper_usage);
> +}

This is meant to replace this sequence:

git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
git diff --name-only -z HEAD -- >"$TMP-stagenames" &&
git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"

And outside of this section of the script, $TMPindex is never looked at after 
this part finishes (which is obvious as the last thing the section does 

Re: [PATCH v2] convert: legitimately disable clean/smudge filter with an empty override

[Lars Schneider]

> On 29 Jan 2016, at 19:20, Junio C Hamano  wrote:
> 
> larsxschnei...@gmail.com writes:
> 
>> From: Lars Schneider 
>> 
>> If the clean/smudge command of a Git filter driver (filter..smudge 
>> and
>> filter..clean) is set to an empty string ("") and the filter driver 
>> is
>> not required (filter..required=false) then Git will run successfully.
>> However, Git will print an error for every file that is affected by the 
>> filter.
>> 
>> Teach Git to consider an empty clean/smudge filter as legitimately disabled
>> and do not print an error message if the filter is not required.
>> 
>> Signed-off-by: Lars Schneider 
>> ---
>> convert.c |  2 +-
>> t/t0021-conversion.sh | 16 
>> 2 files changed, 17 insertions(+), 1 deletion(-)
>> 
>> diff --git a/convert.c b/convert.c
>> index 814e814..02d5f1e 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -395,7 +395,7 @@ static int apply_filter(const char *path, const char 
>> *src, size_t len, int fd,
>>struct async async;
>>struct filter_params params;
>> 
>> -if (!cmd)
>> +if (!cmd || !*cmd)
>>return 0;
> 
> This is certainly simpler than v1.  I was initially worried about
> the fact that slightly changes the semantics around the "required"
> variable relative to v1, which said:
> 
>if (ca.drv && ca.drv->clean && *ca.drv->clean) {
>filter = ca.drv->clean;
>required = ca.drv->required;
>}
>ret |= apply_filter(path, src, len, -1, dst, filter);
>if (!ret && required)
>die;
> 
> but in v2, this part of the code is just as before, i.e.
> 
>if (ca.drv) {
>filter = ca.drv->clean;
>required = ca.drv->required;
>}
>ret |= apply_filter(path, src, len, -1, dst, filter);
>if (!ret && required)
>die;
> 
> So unlike v1, 'required' is set to true in the function, which is a
> good thing, but because in v2, apply_filter knows that an extrernal
> filter command that is an empty string is a no-op success, the above
> codepath behaves identically to v1 when observed from outside, i.e.
> "an empty string given as clean/smudge filter is a no-op success".
> 
> Good.
> 
> By the way, I find it somewhat annoying to see "legitimately" twice
> in the log message.  It makes it sound like there are legitimate way
> and not-so-kosher way to disable the filters.  Perhaps something
> like this instead?
> 
> -- >8 --
> convert: treat an empty string for clean/smudge filters as "cat"
> 
> Once a lower-priority configuration file defines a clean or smudge
> filter, there is no convenient way to override it.  Even though the
> configuration mechanism implements "the last one wins" semantics,
> you cannot set them to an empty string and expect them to work, as
> apply_filter() would try to run the empty string as an external
> command and fail.  The conversion is not done, but the function
> would still report a failure to convert.
> 
> Even though resetting the variable to "cat" (i.e. pass the data back
> as-is and report success) is an obvious and a viable way to solve
> this, it is wasteful to spawn an external process just as a
> workaround.
> 
> Instead, teach apply_filter() to treat an empty string given as a
> filter means the input must be returned as-is without conversion,
> and the operation must always succeed.
> -- >8 --

That reads perfect. I am sorry that I caused so much work for you with this 
patch. 

I really appreciate your editing as this helps me to improve my commit message 
writing skills!

Thanks,
Lars

> 
>> 
>>if (!dst)
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 718efa0..7bac2bc 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -252,4 +252,20 @@ test_expect_success "filter: smudge empty file" '
>>test_cmp expected filtered-empty-in-repo
>> '
>> 
>> +test_expect_success 'disable filter with empty override' '
>> +test_config_global filter.disable.smudge false &&
>> +test_config_global filter.disable.clean false &&
>> +test_config filter.disable.smudge false &&
>> +test_config filter.disable.clean false &&
>> +
>> +echo "*.disable filter=disable" >.gitattributes &&
>> +
>> +echo test >test.disable &&
>> +git -c filter.disable.clean= add test.disable 2>err &&
>> +test_must_be_empty err &&
>> +rm -f test.disable &&
>> +git -c filter.disable.smudge= checkout -- test.disable 2>err &&
>> +test_must_be_empty err
>> +'
>> +
>> 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

AW: [PATCH 2/2] stash: use "stash--helper"

[Matthias Aßhauer]

>>> Yes, I did. It definitly makes things easier if you are not used to mailing 
>>> lists, but it was also a bit of a kerfuffle. I tried to start working on 
>>> coverletter support, but I couldn't get it to accept the amazon SES 
>>> credentials I provided. I ended up manually submiting the coverletter. It 
>>> also didn't like my name.

> Apologies for that - https://github.com/rtyley/submitgit/pull/26 has just 
> been deployed, which should resolve the encoding for non-US ASCII characters 
> - if you feel like submitting another patch, and want to put the eszett back 
> into your GitHub account display name, I'd be interested to know how that 
> goes.

You don't need to apologise. I knew the tool was WIP and had seen the Isuue 
before Iattempted to submit this. I will try out the patched version when I 
submit v2 of this.

--
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: AW: [PATCH 1/2] stash--helper: implement "git stash--helper"

[Junio C Hamano]

Matthias Aßhauer  writes:

[administrivia: please wrap your lines to reasonable lengths]

>> Honestly, I had high hopes after seeing the "we are rewriting it
>> in C" but I am not enthused after seeing this.  I was hoping that
>> the rewritten version would do this all in-core, by calling these
>> functions that we already have:
>
> These functions might be obvious to you, but I'm new to git's
> source code, ...

Ahh, I didn't realize I was talking with somebody unfamiliar with
the codebase.  Apologies.

Nevertheless, the list of functions I gave are a good starting
point; they are widely used building blocks in the codebase.

> I'll be working on a v2 that incorporates the feedback from you,
> Thomas Gummerer and Stefan Beller then. Further feedback is of
> course welcome.

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

[PATCH 1/2] gitk: fr.po: Update translation (311t)

[Jean-Noel Avila]

Signed-off-by: Jean-Noel Avila 
---
 po/fr.po | 761 +++
 1 file changed, 373 insertions(+), 388 deletions(-)

diff --git a/po/fr.po b/po/fr.po
index 80f72fb..2e55c89 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -3,14 +3,14 @@
 # This file is distributed under the same license as the gitk package.
 # Translators:
 # Emmanuel Trillaud 
-#
+# Jean-Noël Avila 
 msgid ""
 msgstr ""
 "Project-Id-Version: gitk\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2015-05-17 14:32+1000\n"
-"PO-Revision-Date: 2009-11-19 22:13+0100\n"
-"Last-Translator: Emmanuel Trillaud \n"
+"POT-Creation-Date: 2016-01-22 22:04+0100\n"
+"PO-Revision-Date: 2016-01-22 23:05+0100\n"
+"Last-Translator: Jean-Noël Avila \n"
 "Language-Team: git@vger.kernel.org\n"
 "Language: \n"
 "MIME-Version: 1.0\n"
@@ -23,13 +23,13 @@ msgstr ""
 msgid "Couldn't get list of unmerged files:"
 msgstr "Impossible de récupérer la liste des fichiers non fusionnés :"
 
-#: gitk:212 gitk:2381
+#: gitk:212 gitk:2399
 msgid "Color words"
-msgstr ""
+msgstr "Colorier les mots différents"
 
-#: gitk:217 gitk:2381 gitk:8220 gitk:8253
+#: gitk:217 gitk:2399 gitk:8239 gitk:8272
 msgid "Markup words"
-msgstr ""
+msgstr "Marquer les mots différents"
 
 #: gitk:324
 msgid "Error parsing revisions:"
@@ -47,13 +47,10 @@ msgstr ""
 
 # FIXME : améliorer la traduction de 'file limite'
 #: gitk:396
-#, fuzzy
 msgid ""
 "No files selected: --merge specified but no unmerged files are within file "
 "limit."
-msgstr ""
-"Aucun fichier sélectionné : --merge précisé mais aucun fichier non fusionné "
-"n'est dans la limite des fichiers."
+msgstr "Aucun fichier sélectionné : --merge précisé mais aucun fichier non 
fusionné n'est dans la limite des fichiers."
 
 #: gitk:418 gitk:566
 msgid "Error executing git log:"
@@ -63,15 +60,15 @@ msgstr "Erreur à l'exécution de git log :"
 msgid "Reading"
 msgstr "Lecture en cours"
 
-#: gitk:496 gitk:4525
+#: gitk:496 gitk:4544
 msgid "Reading commits..."
 msgstr "Lecture des commits..."
 
-#: gitk:499 gitk:1637 gitk:4528
+#: gitk:499 gitk:1637 gitk:4547
 msgid "No commits selected"
 msgstr "Aucun commit sélectionné"
 
-#: gitk:1445 gitk:4045 gitk:12432
+#: gitk:1445 gitk:4064 gitk:12469
 msgid "Command line"
 msgstr "Ligne de commande"
 
@@ -83,290 +80,294 @@ msgstr "Impossible de lire la sortie de git log :"
 msgid "No commit information available"
 msgstr "Aucune information disponible sur le commit"
 
-#: gitk:1903 gitk:1932 gitk:4315 gitk:9669 gitk:11241 gitk:11521
+#: gitk:1903 gitk:1932 gitk:4334 gitk:9702 gitk:11274 gitk:11554
 msgid "OK"
 msgstr "OK"
 
-#: gitk:1934 gitk:4317 gitk:9196 gitk:9275 gitk:9391 gitk:9440 gitk:9671
-#: gitk:11242 gitk:11522
+#: gitk:1934 gitk:4336 gitk:9215 gitk:9294 gitk:9424 gitk:9473 gitk:9704
+#: gitk:11275 gitk:11555
 msgid "Cancel"
 msgstr "Annuler"
 
-#: gitk:2069
+#: gitk:2083
 msgid ""
 msgstr "Mise à jour"
 
-#: gitk:2070
+#: gitk:2084
 msgid ""
 msgstr "Recharger"
 
-#: gitk:2071
+#: gitk:2085
 msgid "Reread re"
 msgstr "Relire les références"
 
-#: gitk:2072
+#: gitk:2086
 msgid " references"
 msgstr "Lister les références"
 
-#: gitk:2074
+#: gitk:2088
 msgid "Start git "
 msgstr "Démarrer git gui"
 
-#: gitk:2076
+#: gitk:2090
 msgid ""
 msgstr "Quitter"
 
-#: gitk:2068
+#: gitk:2082
 msgid ""
 msgstr "Fichier"
 
-#: gitk:2080
+#: gitk:2094
 msgid ""
 msgstr "Préférences"
 
-#: gitk:2079
+#: gitk:2093
 msgid ""
 msgstr "Éditer"
 
-#: gitk:2084
+#: gitk:2098
 msgid " view..."
 msgstr "Nouvelle vue..."
 
-#: gitk:2085
+#: gitk:2099
 msgid " view..."
 msgstr "Éditer la vue..."
 
-#: gitk:2086
+#: gitk:2100
 msgid " view"
 msgstr "Supprimer la vue"
 
-#: gitk:2088 gitk:4043
+#: gitk:2102
 msgid " files"
 msgstr "Tous les fichiers"
 
-#: gitk:2083 gitk:4067
+#: gitk:2097
 msgid ""
 msgstr "Vue"
 
-#: gitk:2093 gitk:2103 gitk:3012
+#: gitk:2107 gitk:2117
 msgid " gitk"
 msgstr "À propos de gitk"
 
-#: gitk:2094 gitk:2108
+#: gitk:2108 gitk:2122
 msgid " bindings"
 msgstr "Raccourcis clavier"
 
-#: gitk:2092 gitk:2107
+#: gitk:2106 gitk:2121
 msgid ""
 msgstr "Aide"
 
-#: gitk:2185 gitk:8652
+#: gitk:2199 gitk:8671
 msgid "SHA1 ID:"
 msgstr "Id SHA1 :"
 
-#: gitk:2229
+#: gitk:2243
 msgid "Row"
 msgstr "Colonne"
 
-#: gitk:2267
+#: gitk:2281
 msgid "Find"
 msgstr "Recherche"
 
-#: gitk:2295
+#: gitk:2309
 msgid "commit"
 msgstr "commit"
 
-#: gitk:2299 gitk:2301 gitk:4687 gitk:4710 gitk:4734 gitk:6755 gitk:6827
-#: gitk:6912
+#: gitk:2313 gitk:2315 gitk:4706 gitk:4729 gitk:4753 gitk:6774 gitk:6846
+#: gitk:6931
 msgid "containing:"
 msgstr "contient :"
 
-#: gitk:2302 gitk:3526 gitk:3531 gitk:4763
+#: gitk:2316 gitk:3545 gitk:3550 gitk:4782
 msgid "touching paths:"
 msgstr "chemins modifiés :"
 
-#: gitk:2303 gitk:4777
+#: gitk:2317 gitk:4796
 msgid "adding/removing string:"
 msgstr "ajoute/supprime la chaîne :"
 
-#: gitk:2304 gitk:4779
+#: gitk:2318 

[PATCH 2/2] gitk: fr.po: Sync translations with git

[Jean-Noel Avila]

Signed-off-by: Jean-Noel Avila 
---
 po/fr.po | 96 +++-
 1 file changed, 46 insertions(+), 50 deletions(-)

diff --git a/po/fr.po b/po/fr.po
index 2e55c89..c44f994 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -9,7 +9,7 @@ msgstr ""
 "Project-Id-Version: gitk\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2016-01-22 22:04+0100\n"
-"PO-Revision-Date: 2016-01-22 23:05+0100\n"
+"PO-Revision-Date: 2016-01-22 23:28+0100\n"
 "Last-Translator: Jean-Noël Avila \n"
 "Language-Team: git@vger.kernel.org\n"
 "Language: \n"
@@ -95,27 +95,27 @@ msgstr "Mise à jour"
 
 #: gitk:2084
 msgid ""
-msgstr "Recharger"
+msgstr ""
 
 #: gitk:2085
 msgid "Reread re"
-msgstr "Relire les références"
+msgstr "Relire les réérences"
 
 #: gitk:2086
 msgid " references"
-msgstr "Lister les références"
+msgstr " les références"
 
 #: gitk:2088
 msgid "Start git "
-msgstr "Démarrer git gui"
+msgstr "Démarrer git "
 
 #: gitk:2090
 msgid ""
-msgstr "Quitter"
+msgstr ""
 
 #: gitk:2082
 msgid ""
-msgstr "Fichier"
+msgstr ""
 
 #: gitk:2094
 msgid ""
@@ -123,15 +123,15 @@ msgstr "Préférences"
 
 #: gitk:2093
 msgid ""
-msgstr "Éditer"
+msgstr "&Éditer"
 
 #: gitk:2098
 msgid " view..."
-msgstr "Nouvelle vue..."
+msgstr " vue..."
 
 #: gitk:2099
 msgid " view..."
-msgstr "Éditer la vue..."
+msgstr "&Éditer la vue..."
 
 #: gitk:2100
 msgid " view"
@@ -143,7 +143,7 @@ msgstr "Tous les fichiers"
 
 #: gitk:2097
 msgid ""
-msgstr "Vue"
+msgstr ""
 
 #: gitk:2107 gitk:2117
 msgid " gitk"
@@ -208,7 +208,7 @@ msgstr "Tous les champs"
 
 #: gitk:2332 gitk:4890 gitk:4923 gitk:6805
 msgid "Headline"
-msgstr "Surligner"
+msgstr "Titre"
 
 #: gitk:2333 gitk:4890 gitk:6805 gitk:6935 gitk:7408
 msgid "Comments"
@@ -221,7 +221,7 @@ msgstr "Auteur"
 
 #: gitk:2333 gitk:4890 gitk:6805 gitk:7345
 msgid "Committer"
-msgstr "Auteur du commit"
+msgstr "Validateur"
 
 #: gitk:2367
 msgid "Search"
@@ -261,11 +261,11 @@ msgstr "Arbre"
 
 #: gitk:2635 gitk:2656
 msgid "Diff this -> selected"
-msgstr "Diff entre ceci et la sélection"
+msgstr "Diff ceci -> la sélection"
 
 #: gitk:2636 gitk:2657
 msgid "Diff selected -> this"
-msgstr "Diff entre sélection et ceci"
+msgstr "Diff sélection -> ceci"
 
 #: gitk:2637 gitk:2658
 msgid "Make patch"
@@ -273,7 +273,7 @@ msgstr "Créer patch"
 
 #: gitk:2638 gitk:9273
 msgid "Create tag"
-msgstr "Créer tag"
+msgstr "Créer étiquette"
 
 #: gitk:2639
 msgid "Copy commit summary"
@@ -643,7 +643,7 @@ msgstr "Références (liste d'éléments séparés par des 
espaces) :"
 
 #: gitk:4095
 msgid "Branches & tags:"
-msgstr "Branches & tags :"
+msgstr "Branches & étiquettes :"
 
 #: gitk:4096
 msgid "All refs"
@@ -655,7 +655,7 @@ msgstr "Toutes les branches (locales)"
 
 #: gitk:4098
 msgid "All tags"
-msgstr "Tous les tags"
+msgstr "Toutes les étiquettes"
 
 #: gitk:4099
 msgid "All remote-tracking branches"
@@ -671,7 +671,7 @@ msgstr "Auteur :"
 
 #: gitk:4102
 msgid "Committer:"
-msgstr "Commiteur :"
+msgstr "Validateur :"
 
 #: gitk:4103
 msgid "Commit Message:"
@@ -711,7 +711,7 @@ msgstr ""
 
 #: gitk:4111
 msgid "Since:"
-msgstr "De :"
+msgstr "Depuis :"
 
 #: gitk:4112
 msgid "Until:"
@@ -737,7 +737,6 @@ msgstr "Options diverses :"
 msgid "Strictly sort by date"
 msgstr "Trier par date"
 
-# FIXME : traduction de "branch sides"
 #: gitk:4118
 msgid "Mark branch sides"
 msgstr "Indiquer les côtés des branches"
@@ -804,11 +803,11 @@ msgstr "Pas un ancêtre"
 
 #: gitk:5343
 msgid "Local changes checked in to index but not committed"
-msgstr "Modifications locales enregistrées dans l'index mais non commitées"
+msgstr "Modifications locales enregistrées dans l'index mais non validées"
 
 #: gitk:5379
 msgid "Local uncommitted changes, not checked in to index"
-msgstr "Modifications locales non enregistrées dans l'index et non commitées"
+msgstr "Modifications locales non enregistrées dans l'index et non validées"
 
 #: gitk:7153
 msgid "and many more"
@@ -820,7 +819,7 @@ msgstr "nombreux"
 
 #: gitk:7347
 msgid "Tags:"
-msgstr "Tags :"
+msgstr "Étiquettes :"
 
 #: gitk:7364 gitk:7370 gitk:8844
 msgid "Parent"
@@ -854,17 +853,17 @@ msgstr "Aller à :"
 #: gitk:8690
 #, tcl-format
 msgid "Short SHA1 id %s is ambiguous"
-msgstr "Id SHA1 court %s est ambigu"
+msgstr "L'id SHA1 court %s est ambigu"
 
 #: gitk:8697
 #, tcl-format
 msgid "Revision %s is not known"
-msgstr "Id SHA1 %s est inconnu"
+msgstr "La révision %s est inconnu"
 
 #: gitk:8707
 #, tcl-format
 msgid "SHA1 id %s is not known"
-msgstr "Id SHA1 %s est inconnu"
+msgstr "L'id SHA1 %s est inconnu"
 
 #: gitk:8709
 #, tcl-format
@@ -987,15 +986,15 @@ msgstr "ID :"
 
 #: gitk:9284
 msgid "Tag name:"
-msgstr "Nom du Tag :"
+msgstr "Nom de l'étiquette :"
 
 #: gitk:9287
 msgid "Tag message is optional"
-msgstr "Le message du tag est optionnel"
+msgstr "Le message d'étiquette est optionnel"
 
 #: gitk:9289
 msgid "Tag message:"
-msgstr "Message du Tag :"
+msgstr "Message d'étiquette :"
 
 #: 

Re: Gitignore file exceptions are not applied to untarcked files

[Anatoly Borodin]

Hi Junio,


I've tested it with many older versions of git, as well as with the recent
v2.7.0 - it seems like this feature has been never working properly.

The script https://gist.github.com/anatolyborodin/9c581b50c584534fff28

#!/bin/sh

set -e

# a
# b
# c
# D/a
# D/b
# D/c
# E/F/a
# E/F/b
# E/F/c

mkdir -p D E/F
touch a b c D/a D/b D/c E/F/a E/F/b E/F/c

echo && echo '.gitignore' && echo '--'
echo '*\n!b\n!D/b\n!/D/b\n!/E/*/b' > .gitignore
cat .gitignore

echo && echo 'With `--ignored`' && echo '--'
git status --ignored

echo && echo 'Without `--ignored`' && echo '--'
git status


The output:


.gitignore
--
*
!b
/D/b
!/D/b
!/E/*/b

With `--ignored`
--
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add ..." to include in what will be committed)

b

Ignored files:
  (use "git add -f ..." to include in what will be committed)

.gitignore
D/
E/
a
c

nothing added to commit but untracked files present (use "git add" to track)

Without `--ignored`
--
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add ..." to include in what will be committed)

b

nothing added to commit but untracked files present (use "git add" to track)



All files in the subdirectories are ignored, no matter what.


-- 
Mit freundlichen Grüßen,
Anatoly Borodin

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