skip_stat_unmatch flag is added in fb13227 (git-diff: squelch "empty"
diffs - 2007-08-03) to ignore empty diffs caused by stat-only
dirtiness. In "diff --cached" case, stat is not invovled at all. While
the code is written in a way that no expensive I/O is done, we still
need to move all file pairs
When QUICK is set (i.e. with --quiet) we try to do as little work as
possible, stopping after seeing the first change. stat-dirty is
considered a "change" but it may turn out not, if no actual content is
changed. The actual content test is performed too late in the process
and the shortcut may be t
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diff.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/diff.c b/diff.c
index 6b4cd0e..19460ff 100644
--- a/diff.c
+++ b/diff.c
@@ -4697,6 +4697,33 @@ static int diff_filespec_is_identic
On Sat, Jan 25, 2014 at 4:22 AM, Eric Sunshine wrote:
> On Fri, Jan 24, 2014 at 8:40 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
>> index af5134b..167af53 100755
>> --- a/t/t4010-diff-pathspec.sh
>> +++ b/t/t4010-diff-pathspec.sh
>> @@ -1
On Sat, Jan 25, 2014 at 10:34 AM, Yuri wrote:
> The fragment of 'git diff' output looks like this:
> - Ошибка: адрес %1 содержит запрещенные символы. Пожалуйста,
> перепро�
> + Ошибка: адрес %1 содержит запрещённые символы. Пожалуйста,
> перепро�
>
> Two issues here:
> 1. Cyrilic text in utf8 got
On Thu, Jan 23, 2014 at 11:45:25AM +0900, IWAMOTO Toshihiro wrote:
> I found "git-diff --quiet" returns a zero exit status even if there's
> a change. The following sequence reproduces the bug:
>
> $ mkdir foo
> $ cd foo
> $ git init
> $ echo a > a.txt
> $ echo b >b.txt
> $ git add ?.
The fragment of 'git diff' output looks like this:
- Ошибка: адрес %1 содержит запрещенные символы.
Пожалуйста, перепро�
+ Ошибка: адрес %1 содержит запрещённые символы.
Пожалуйста, перепро�
Two issues here:
1. Cyrilic text in utf8 got truncated not at utf8 boundary, causing this
garbage symb
On Fri, Jan 24, 2014 at 01:08:42PM -0800, Junio C Hamano wrote:
> Not really. You do not have to view it as "'not refs/heads/foo' is
> affecting the previous '+refs/heads/*:refs/remotes/origin/*'".
>
> You can think of two refspecs "refs/heads/foo refs/heads/bar" are
> both affecting the "end re
On Sat, Jan 25, 2014 at 2:22 AM, Junio C Hamano wrote:
> How does "git status '[b]/'" behave?
It outputs "b/" (like "git status b"). I think that's because
common_prefix_len() stops looking at the first wildcard char, '['. So
common prefix is empty, just like "b".
--
Duy
--
To unsubscribe from t
On Fri, Jan 24, 2014 at 10:49:13PM +, brian m. carlson wrote:
> On Fri, Jan 24, 2014 at 11:24:36PM +0100, Johannes Schindelin wrote:
> > > In general, I'm wary of changing permissions on a file to suit Windows's
> > > rename because of the symlink issue and the security issues that can
> > > re
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Junio, since you prepare such tarballs[1] anyway for kernel.org, it
> > might be worth uploading them to the "Releases" page of git/git. I
> > imagine there is a programmatic way to do so via GitHub's API,
Johannes Schindelin writes:
> In any case, I'd rather change the permissions only when the rename
> failed. *And* I feel uncomfortable ignoring the return value...
Good judgement I'd agree with 100%.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
Torsten Bögershausen writes:
> Another solution could be to do the "chmod +x" in mingw_rename().
> This may be done in another commit, because
> a) It improves git gc only when Git for Windows is used
>on the client machine
> b) Windows refuses to delete a file when the file is read-only.
>
Ramkumar Ramachandra writes:
> On that note, can you hold off graduating
> jk/branch-at-publish-rebased, Junio? Hopefully, I'll come up with a
> replacement over the weekend.
Sure.
This close to the feature freeze, I'd rather see all contributors,
not limited to you, not rush on new and shiny t
On Fri, Jan 24, 2014 at 11:24:36PM +0100, Johannes Schindelin wrote:
> > In general, I'm wary of changing permissions on a file to suit Windows's
> > rename because of the symlink issue and the security issues that can
> > result.
>
> I agree on the Windows issue.
I personally feel that if Window
"brian m. carlson" writes:
> On Fri, Jan 24, 2014 at 01:00:06PM -0800, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > +-S[]::
>> > +--gpg-sign[=]::
>> > + GPG-sign commits.
>> > +
>>
>> Does this accept --no-gpg-sign? If not, shouldn't it?
>
> It does not. I took Nicolas's patc
2014/1/24 Ralf Thielow :
> Translate 27 new messages came from git.pot update in
> df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed).
>
> Signed-off-by: Ralf Thielow
> ---
> po/de.po | 90
>
> 1 file changed, 45 insertions(
Hi Brian,
On Fri, 24 Jan 2014, brian m. carlson wrote:
> On Fri, Jan 24, 2014 at 10:05:14PM +0100, Torsten Bögershausen wrote:
> > diff --git a/builtin/repack.c b/builtin/repack.c
> > index ba66c6e..033b4c2 100644
> > --- a/builtin/repack.c
> > +++ b/builtin/repack.c
> > @@ -324,6 +324,10 @@ int
Jeff King wrote:
> As far as merging it to 'next', I had not really intended it to go that
> far. :) It was more for Ram to use as a base.
Sorry about not having posted a follow-up yet; I'm adjusting to a new
timezone and environment.
> I find some of the
> refactoring questionable, including:
>
On Fri, Jan 24, 2014 at 10:05:14PM +0100, Torsten Bögershausen wrote:
> commit a1bbc6c0 "repack: rewrite the shell script in C" introduced
> a possible regression, when a Git repo is located on a Windows network share.
>
> When git gc is called on an already packed repository, it could fail like
On Thu, Jan 23, 2014 at 04:16:06PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > In a triangular workflow, you may have a distinct
> > @{upstream} that you pull changes from, but publish by
> > default (if you typed "git push") to a different remote (or
> > a different branch on the rem
On Fri, Jan 24, 2014 at 8:40 AM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
> index af5134b..167af53 100755
> --- a/t/t4010-diff-pathspec.sh
> +++ b/t/t4010-diff-pathspec.sh
> @@ -110,4 +110,21 @@ test_expect_success 'diff-tree -r with wildcard'
Jeff King writes:
> I had imagined a "not" token at the front of the refspec, like:
>
> git fetch origin +refs/heads/*:refs/remotes/origin/* ^refs/heads/foo
>
> In this case, a colon in the refspec would be an error. An alternative
> would be:
>
> git fetch origin +refs/heads/*:refs/remotes/o
On Fri, Jan 24, 2014 at 01:00:06PM -0800, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > +-S[]::
> > +--gpg-sign[=]::
> > + GPG-sign commits.
> > +
>
> Does this accept --no-gpg-sign? If not, shouldn't it?
It does not. I took Nicolas's patches from the list and applied them to
mas
commit a1bbc6c0 "repack: rewrite the shell script in C" introduced
a possible regression, when a Git repo is located on a Windows network share.
When git gc is called on an already packed repository, it could fail like this:
"fatal: renaming '.git/objects/pack/.tmp-xyz.pack' failed: Permission den
"brian m. carlson" writes:
> +-S[]::
> +--gpg-sign[=]::
> + GPG-sign commits.
> +
Does this accept --no-gpg-sign? If not, shouldn't it?
> diff --git a/sequencer.c b/sequencer.c
> index 90cac7b..bde5f04 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -392,11 +392,18 @@ static int run_gi
On 2014.01.24 at 12:44 -0800, Junio C Hamano wrote:
> Markus Trippelsdorf writes:
>
> > On 2014.01.24 at 12:00 -0800, Junio C Hamano wrote:
> >> Jeff King writes:
> >>
> >> > On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
> >> >
> >> >> > However, you do have to specify ea
On Fri, Jan 24, 2014 at 12:00:16PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
> >
> >> > However, you do have to specify each branch individually. You probably
> >> > want to say "all branches except X", and you can
Markus Trippelsdorf writes:
> On 2014.01.24 at 12:00 -0800, Junio C Hamano wrote:
>> Jeff King writes:
>>
>> > On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
>> >
>> >> > However, you do have to specify each branch individually. You probably
>> >> > want to say "all branch
Brad King writes:
> +extern struct cache_entry *make_cache_entry(unsigned int mode, const
> unsigned char *sha1, const char *path, int stage, int refresh, int
> refresh_flags);
Why a new parameter? If refresh_flags can be ANY when refresh=NoThanks,
shouldn't they be a single variable that tel
On 2014.01.24 at 12:00 -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
> >
> >> > However, you do have to specify each branch individually. You probably
> >> > want to say "all branches except X", and you cannot currently
Linus Torvalds writes:
> So I don't actually think anybody should need to be retrained, or
> "always use the local:remote" syntax. The local:remote syntax exists
> only for that special insane case where you used (the same)
> local:remote syntax to push out a branch under a different name.
>
> [
Add an 'int refresh_flags' argument to make_cache_entry to tell the
refresh step about caller preferences. Teach it to honor the
REFRESH_IGNORE_MISSING flag to skip refreshing stat information when a
file is missing from the work tree on disk.
Signed-off-by: Brad King
---
builtin/apply.c|
Hi Folks,
Here is the second revision of this series. The previous
revision can be found at $gmane/241009.
Updates since the previous revision of the series:
* Patch 1 test indentation and commit message updated thanks to
comments from Jonathan.
* Patch 2 now adds a different new argument to
Sometimes when working with a large repository it can be useful to try
out a merge and only check out conflicting files to disk (for example as
a speed optimization on a server). Until v1.7.7-rc1~28^2~20
(merge-recursive: When we detect we can skip an update, actually skip
it, 2011-08-11), it was
Teach add_cacheinfo to tell make_cache_entry to skip refreshing stat
information when a file is missing from the work tree. We do not want
the index to be stat-dirty after the merge but also do not want to fail
when a file happens to be missing.
This fixes the 'merge-recursive w/ empty work tree
Nicolas Vigier writes:
> On Fri, 24 Jan 2014, brian m. carlson wrote:
>
>> This series was posted to the list some time back, but it fell through
>> the cracks. This is a re-send of Nicolas Vigier's work with an
>> additional patch that adds --gpg-sign to pull as well. I added my
>> sign-off to
On Fri, Jan 24, 2014 at 2:50 PM, Junio C Hamano wrote:
> It somehow feels wrong to force callers of make_cache_entry() to be
> so intimate with the implementation details of refresh_cache_ent()
[snip]
> option bit CE_MATCH_MISSING_OK that asks it to treat a path that is
> missing from the working
Jeff King writes:
> On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
>
>> > However, you do have to specify each branch individually. You probably
>> > want to say "all branches except X", and you cannot currently specify
>> > a negative refspec like that.
>>
>> Yes, that was
On 01/24/2014 01:42 PM, Elijah Newren wrote:
> While this change does work for the particular new testcase you provided,
> there's a more complex case where merge-recursive is failing
I'm not surprised. The change felt much like covering a symptom.
> it's just that we want the stat information r
Brad King writes:
> Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
> the reason is ENOENT from lstat. Tell it to do so in the call path when
> the entry from HEAD is known to be up to date.
It somehow feels wrong to force callers of make_cache_entry() to be
so intimate
[The copy of my message to the list bounced; trying to resend...]
Hi,
Thanks for flagging this problem, providing a clear testcase, and working on it.
On Fri, Jan 24, 2014 at 7:01 AM, Brad King wrote:
>
> Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
> the reason is E
Nguyễn Thái Ngọc Duy writes:
> While looking at this, I found a funny behavior of fill_directory.
>
> $ git init
> $ mkdir b
> $ >b/c
> $ >b/d
> $ git status b
> Untracked files:
> b/
> $ git status b/
> Untracked files:
> b/c b/d
>
> Notice how the trailing s
On Fri, Jan 24, 2014 at 07:32:22PM +0100, Markus Trippelsdorf wrote:
> > However, you do have to specify each branch individually. You probably
> > want to say "all branches except X", and you cannot currently specify
> > a negative refspec like that.
>
> Yes, that was the question I wanted to as
On 2014.01.24 at 13:23 -0500, Jeff King wrote:
> On Fri, Jan 24, 2014 at 06:09:09PM +0100, Markus Trippelsdorf wrote:
>
> > > > If you mean "ignore" in some other scenario you need to be more
> > > > specific about what you want.
> > >
> > > I want to them when I run "git pull".
> >ig
On Fri, Jan 24, 2014 at 06:09:09PM +0100, Markus Trippelsdorf wrote:
> > > If you mean "ignore" in some other scenario you need to be more
> > > specific about what you want.
> >
> > I want to them when I run "git pull".
>ignore
I assume you mean that you do not want to fetch them at
On 01/24/2014 11:51 AM, Jonathan Nieder wrote:
> a quick summary of the symptoms and when it came up?
You're suggested commit message correctly explains it:
> Do you mean something like the following?
>
> Sometimes when working with a large repository it can be useful to
> try out a
On 2014.01.24 at 16:37 +, Jim Garrison wrote:
> > -Original Message-
> > Behalf Of Markus Trippelsdorf
> > Sent: Friday, January 24, 2014 1:01 AM
> > Subject: Globbing for ignored branches?
> >
> > I would like to ignore branches that match a certain pattern, e.g.:
> [snip]
> >
> > Is
On 2014.01.24 at 18:07 +0100, Markus Trippelsdorf wrote:
> On 2014.01.24 at 16:37 +, Jim Garrison wrote:
> > > -Original Message-
> > > Behalf Of Markus Trippelsdorf
> > > Sent: Friday, January 24, 2014 1:01 AM
> > > Subject: Globbing for ignored branches?
> > >
> > > I would like to i
Hallo,
Mein Name ist Miss Jocelyn. entschied ich mich zu schreiben, weil ich wurde für
dich interessiert und ich werde wie uns Freunde sein. ich werde gerne mehr über
Sie wissen sehr gut, weil ich glaube, dass es schöne Menschen gibt, die die
Werte der Freundschaft zu schätzen wissen. Alter spie
Hi,
Brad King wrote:
> Add test cases that use 'merge-recursive' plumbing with a temporary
> index and empty work tree. Populate the index using 'read-tree' and
> 'update-index --ignore-missing --refresh' to prepare for merge without
> actually checking all files out to disk. Verify that each m
> -Original Message-
> Behalf Of Markus Trippelsdorf
> Sent: Friday, January 24, 2014 1:01 AM
> Subject: Globbing for ignored branches?
>
> I would like to ignore branches that match a certain pattern, e.g.:
[snip]
>
> Is it possible to ignore all branches that match "hjl"?
If you mean
Add an 'int *err' argument to make_cache_entry to receive any error
that occurred when matching stat information for a file on disk.
Thread it through to the same argument of refresh_cache_ent.
This will allow callers of make_cache_entry to determine whether
failure was due to a missing file on dis
Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
the reason is ENOENT from lstat. Tell it to do so in the call path when
the entry from HEAD is known to be up to date.
This fixes the 'merge-recursive w/ empty work tree - ours has rename'
case in t3030-merge-recursive.
Sig
On 01/23/2014 07:24 PM, Elijah Newren wrote:
> Two options are just doing a stat to determine whether the file
> is present (which means we'll be stat'ing the file multiple times
> in these cases, which feels wasteful), or perhaps writing a
> modified make_cache_entry() with the behavior we want
>
Add test cases that use 'merge-recursive' plumbing with a temporary
index and empty work tree. Populate the index using 'read-tree' and
'update-index --ignore-missing --refresh' to prepare for merge without
actually checking all files out to disk. Verify that each merge
produces its expected tree
A long time ago, for some reason I was not happy with
match_pathspec(). I created a better version, match_pathspec_depth()
that was suppose to replace match_pathspec()
eventually. match_pathspec() has finally been gone since 6 months
ago. Use the shorter name for match_pathspec_depth().
Signed-off
Currently we do support matching pathspec "foo/" against directory
"foo". That is because match_pathspec() has no way to tell "foo" is a
directory and matching "foo/" against _file_ "foo" is wrong.
The callers can now tell match_pathspec if "foo" is a directory, we
could make an exception for this
This helps reduce the number of match_pathspec_depth() call sites and
show how m_p_d() is used. And it usage is:
- match against an index entry (ce_path_match or match_pathspec_depth
in ls-files)
- match against a dir_entry from read_directory (dir_path_match and
match_pathspec_depth in c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index 8960ea1..35e09bd 100644
--- a/dir.c
+++ b/dir.c
@@ -195,6 +195,8 @@ int within_depth(const char *name, int namelen,
return 1;
}
+#d
This helps reduce the number of match_pathspec_depth() call sites and
show how match_pathspec_depth() is used.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 3 +--
builtin/commit.c | 2 +-
builtin/grep.c | 2 +-
builtin/rm.c | 2 +-
builtin/update-index
cmd_clean() has the exact same code of index_name_is_other(). Reduce
code duplication.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/clean.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 5adb52d..cb02a53 10064
This patch activates the DO_MATCH_DIRECTORY code in m_p_i(), which
makes "git diff HEAD submodule/" and "git diff HEAD submodule" produce
the same output. Previously only the version without trailing slash
returns the difference (if any).
That's the effect of new ce_path_match(). dir_path_match()
We do ignore trailing slash on a directory, so pathspec "abc/" matches
directory "abc". A submodule is also a directory. Apply the same logic
to it. This makes "git log submodule-path" and "git log submodule-path/"
produce the same output.
Reported-by: Paweł Sikora
Signed-off-by: Nguyễn Thái Ngọc
This instance was left out when many match_pathspec() call sites that
take input from dir_entry were converted to dir_path_match() because
it passed a path with the trailing slash stripped out to match_pathspec()
while the others did not. Stripping for all call sites back then would
be a regression
So this is the reroll that makes
git diff HEAD submodule
git diff HEAD submodule/
and
git diff HEAD HEAD^ submodule
git diff HEAD HEAD^ submodule/
behave the same way. The main patches are 04/09 and 09/09. The rest is
just refactoring and cleaning up.
While looking at this, I found a f
On Fri, 24 Jan 2014, brian m. carlson wrote:
> This series was posted to the list some time back, but it fell through
> the cracks. This is a re-send of Nicolas Vigier's work with an
> additional patch that adds --gpg-sign to pull as well. I added my
> sign-off to his patches because SubmittingP
I would like to ignore branches that match a certain pattern, e.g.:
markus@x4 gcc % git branch -a
gcc-4.8
* master
remotes/origin/HEAD -> origin/master
remotes/origin/aldyh/cilk-in-gomp
...
remotes/origin/hjl/arch
remotes/origin/hjl/asan
...
remotes/origin/hjl/x86/m16
remotes/origin/
68 matches
Mail list logo
