On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano wrote:
>> Or the user might think "path/ attr1" sets attr1 for all files under
>> "path/" because it does not make sense to attach attributes to a
>> directory in git.
>
>...
>
>We may not have a need to assign a real attribute to a directory
Jeff King writes:
> Actually, I am not sure that thread or feature is to blame. Certainly it
> would have been an opportune time to notice the problem. But this issue
> goes back much further for "git commit --interactive", which has always
> assumed "-i" rather than "-o". This even predates the
Eric Wong writes:
> Jonathan Nieder wrote:
>> Noticed by forcing the fallback on and running tests. Without this
>> patch, t9101.4 fails:
>>
>> Bad URL passed to RA layer: Unable to open an ra_local session to \
>> URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\
>> t9101-
Nguyen Thai Ngoc Duy writes:
> On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> +Unlike `.gitignore`, negative patterns are not supported.
>>> +Patterns that match directories are also not supported.
>>
>> Is "are not supported" the right phrasing?
>>
Jeff King writes:
>> > @@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
>> > commit *one, int n, struc
>> >
>> >one->object.flags |= PARENT1;
>> >commit_list_insert_by_date(one, &list);
>> > + if (!n)
>> > + return list;
>> >for (i = 0; i < n; i+
On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +Unlike `.gitignore`, negative patterns are not supported.
>> +Patterns that match directories are also not supported.
>
> Is "are not supported" the right phrasing?
>
> I think it makes perfect sense not to
On Fri, Oct 05, 2012 at 01:34:02PM -0700, Junio C Hamano wrote:
> OK, I think I am convinced myself that this patch is the right fix.
>
> The performance regression Markus saw is in fmt-merge-message, and
> it is caused by the updated remove_redundant() that is used by
> get_merge_bases_many() an
Jonathan Nieder wrote:
> Noticed by forcing the fallback on and running tests. Without this
> patch, t9101.4 fails:
>
> Bad URL passed to RA layer: Unable to open an ra_local session to \
> URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\
> t9101-git-svn-props/svnrepo' conta
On Fri, Oct 05, 2012 at 03:29:10PM -0700, Junio C Hamano wrote:
> Assuming that the last step of what Horst did was "git commit -pm",
> I think Git is wrong in this case. When you tell "git commit" what
> to commit, unless you give "-i" (aka "also") option, the command
> makes a commit to record
"Frans Klaver" writes:
> On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
> wrote:
>
>> What I did:
>>
>> - New file images/coins.asy ~~-> 'git add images/coins.asy'
>> - Started adding new stuff to fg.tex
>> - Noticed a old bug in fg.tex, fixed that one
>> - Did 'git -pm "Some message"' a
Thomas Ferris Nicolaisen writes:
> On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher
> wrote:
>>
>> > On the git-users mailing list we're trying someone to help with
>> > running `git push` over FTP. That person is runnig Git 1.7.9.5
>> > on Ubuntu 12.04.
>>
>> I don't think vanilla git supports
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy wrote:
> This makes wildmatch.c part of libgit.a and builds test-wildmatch; the
> dependency on libpopt in the original has been replaced with the use
> of our parse-options. Global variables in test-wildmatch are marked
> static to avoid sparse
changes __git_ps1 to not just allow use in setting PS1
with __git_ps1 in a command substitution, but also allows
__git_ps1 to be used as PROMPT_COMMAND in bash.
This has advantages for using color and I think it is more
elegant
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh |
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.)
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh | 42 +++---
1 file changed, 39 insertions(+),
Junio C Hamano writes:
> Here is a tested (in the sense that it passes the test suite, and
> also in the sense that an empty pull in the kernel history gives
> quick turnaround) patch. As I do not think we would want to revert
> 5802f81 (fmt-merge-msg: discard needless merge parents, 2012-04-18)
Andrew Wong writes:
> 'format-patch' could fail due to reasons such as out of memory. Such
> failures are not detected or handled, which causes rebase to incorrectly
> think that it completed successfully and continue with cleanup. i.e.
> calling move_to_original_branch
>
> Since only the exit st
Nguyen Thai Ngoc Duy writes:
> On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano wrote:
>> Nguyen Thai Ngoc Duy writes:
>>
>>> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano wrote:
I would recommend against listing any advice.* in the command manual
pages. They are meant to give an ad
On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
wrote:
What I did:
- New file images/coins.asy ~~-> 'git add images/coins.asy'
- Started adding new stuff to fg.tex
- Noticed a old bug in fg.tex, fixed that one
- Did 'git -pm "Some message"' and selected just the bugfix
But git create
Jeff King writes:
> Agreed. Maybe the simplest thing would be to have grep_config fill in a
> "static struct grep_opt grep_defaults", and then memcpy that into place
> during init_revisions?
Yes, I was doing that for a bit last night, but then realized that
the grep_config() should be split into
Nguyễn Thái Ngọc Duy writes:
> +Unlike `.gitignore`, negative patterns are not supported.
> +Patterns that match directories are also not supported.
Is "are not supported" the right phrasing?
I think it makes perfect sense not to forbid "!path attr1", because
it is unclear what it means (e.g. "
On Fri, 5 Oct 2012 15:46:33 +0200
Philippe Vaucher wrote:
> > On the git-users mailing list we're trying someone to help with
> > running `git push` over FTP. That person is runnig Git 1.7.9.5
> > on Ubuntu 12.04.
>
> I don't think vanilla git supports pushing over ftp.
>
> There are plugins l
On Thu, Oct 4, 2012 at 11:24 PM, Johannes Sixt wrote:
> Am 10/3/2012 21:41, schrieb Shawn Pearce:
>> On Wed, Oct 3, 2012 at 11:55 AM, Jeff King wrote:
>>> On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
Jeff King writes:
>> Has there been any work on extending the p
On Fri, Oct 05, 2012 at 10:36:52AM +1000, Andrew Ardill wrote:
> On 5 October 2012 10:29, Jeff King wrote:
> >...
> >
> >but it feels a little fake. Why 200? Because that will test the config
> >limit, but will not overflow the NAME_MAX limit (at least not on
> >Linux! No clue on other platforms)
On Thu, Oct 04, 2012 at 09:16:14PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > So we would need to do something like:
> >
> > - call git_log_config() first to let diff_context_default
> > updated from the configuration as before. find the values of
> > grep.* def
On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher
wrote:
>
> > On the git-users mailing list we're trying someone to help with
> > running `git push` over FTP. That person is runnig Git 1.7.9.5
> > on Ubuntu 12.04.
>
> I don't think vanilla git supports pushing over ftp.
>
At least according to t
What I did:
- New file images/coins.asy ~~-> 'git add images/coins.asy'
- Started adding new stuff to fg.tex
- Noticed a old bug in fg.tex, fixed that one
- Did 'git -pm "Some message"' and selected just the bugfix
But git created a commit _including_ the new file. Tried to go back:
- 'git reset
Matthieu Moy writes:
> Andreas Schwab writes:
>
>> Junio C Hamano writes:
>>
>>> When we require "x/**/y", I think we still want it to match "x/y".
>>
>> FWIW, in bash (+extglob), ksh and zsh it doesn't.
>
> You're right about bash, but I see the opposite for zsh and ksh:
>
> zsh$ echo x/**/y
>
> On the git-users mailing list we're trying someone to help with
> running `git push` over FTP. That person is runnig Git 1.7.9.5
> on Ubuntu 12.04.
I don't think vanilla git supports pushing over ftp.
There are plugins like https://github.com/resmo/git-ftp tho.
Philippe
--
To unsubscribe from
On the git-users mailing list we're trying someone to help with
running `git push` over FTP. That person is runnig Git 1.7.9.5
on Ubuntu 12.04.
Below is the trace captured while trying to perform such a faulty push.
The oddity (in my eyes) is that after uploading the files, Git executes
`git http
Marco,
> Similar but not quite; the idea is that you know that there is some
> code (I'm just talking about files here, so lets ignore hunks for the
> moment) which is normally checked in but for a period of time you want
> it ignored.
Got it thanks! Would be useful some time indeed.
--
Pa
On Thu, Oct 04, 2012 at 09:39:02AM -0700, Junio C Hamano wrote:
> Assuming that we do want to match "x/y" with "x/**/y", I suspect
> that "'**' matches anything including a slash" would not give us
> that semantics. Is it something we can easily fix in the wildmatch
> code?
Something like this may
Andreas Schwab writes:
> Junio C Hamano writes:
>
>> When we require "x/**/y", I think we still want it to match "x/y".
>
> FWIW, in bash (+extglob), ksh and zsh it doesn't.
You're right about bash, but I see the opposite for zsh and ksh:
zsh$ echo x/**/y
x/y x/z/y
ksh$ echo x/**/y
x/y x/z/y
Junio C Hamano writes:
> When we require "x/**/y", I think we still want it to match "x/y".
FWIW, in bash (+extglob), ksh and zsh it doesn't.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something compl
On Fri, Oct 5, 2012 at 2:01 PM, Johannes Sixt wrote:
> Am 10/4/2012 9:39, schrieb Nguyễn Thái Ngọc Duy:
>> - - If the pattern does not contain a slash '/', git treats it as
>> - a shell glob pattern and checks for a match against the
>> - pathname relative to the location of the `.gitignore` f
On Fri, Oct 5, 2012 at 5:30 PM, Peter Krefting wrote:
>> These files are from rsync.git commit
>> f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
>> before rsync turned GPL-3.
>
>
> However:
>
>> diff --git a/test-wildmatch.c b/test-wildmatch.c
>
> [...]
>
>> + * This program i
Carlos, thank you very much, core.precomposeunicode works just like you said.
And you're right, it seems the problem is in HFS+, 'git add .' worked as well,
so did even 'git add test_*'.
The problem seems solved.
05.10.2012, в 14:47, c...@elego.de (Carlos Martín Nieto) написал(а):
> Konstantin K
Hey, Konstantin!
Thanks for your reply. My bad, I described the problem not very well. I don't
mind displaying escapes etc. (core.quotepath just makes "\320\270\314\206" be
"й" and that's it), the problem is that git cannot track files with cyrillic
"й" in their name. I created a file, added it
Konstantin Khomoutov writes:
> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил wrote:
>
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>>
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root
On Fri, 5 Oct 2012 14:13:49 +0400
Муковников Михаил wrote:
> There's a problem using git with files having cyrillic 'й' in their
> name, git just can't track them.
>
> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 g
These files are from rsync.git commit
f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
before rsync turned GPL-3.
However:
diff --git a/test-wildmatch.c b/test-wildmatch.c
[...]
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms
There's a problem using git with files having cyrillic 'й' in their name, git
just can't track them.
uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT
2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
git version: 1.7.12.1 (from macports)
Steps to reproduce:
- git init
Angelo Borsotti gmail.com> writes:
> take a git commit without --allow-empty: if the trees are equal, it
> creates no commit,
> and if the trees are different it creates one.
> Take then a git commit --allow-empty: if the trees are equal it may
> create a commit or
> not depending on the parent, m
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/gitignore.txt| 3 +++
attr.c | 4 +++-
dir.c | 5 -
t/t0003-attributes.sh | 17 +
t/t3001-ls-files-others-exclu
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/attr.c b/attr.c
index 2942bf6..aeac564 100644
--- a/attr.c
+++ b/attr.c
@@ -644,13 +644,11 @@ static void prepare_attr_stack(const char *path)
}
static int path_
One place less to worry about thread safety
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
wildmatch.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index f3a1731..e824eb2 100644
--- a/wildmatch.c
+++ b/wi
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to .gitattributes. Basically it
tries to avoid fnmatch/wildm
This function can later be reused by attr.c. Also turn to_exclude
field into a flag.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
If we go with glob->regex conversion way, this is where we could
rewrite the pattern (and set EXC_FLAG_REGEX).
dir.c | 71 ++
Hello,
When I try to complete a branch name containing @, it doesn't expand
as expected.
Running git on Windows 7.
$ git --version
git version 1.7.11.msysgit.1
$ git branch
* master
master@feature
If I write
$ git checkout master@
and press tab, the above expands to
$ git checkout masterm
This makes wildmatch.c part of libgit.a and builds test-wildmatch; the
dependency on libpopt in the original has been replaced with the use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramsa
Deep down wildmatch() sees "**" as "*" that can also match slashes. On
the surface, it may be confusing to users as the above pattern can
match "abcdef", "abcxyzdef", "abc/def", "abc/x/def",
"abc/x/y/def"... For now we just forbid it. Users can only do
"**/def", "abc/**" or "abc/**/def". The syntax
The first four patches are ignore/attr cleanups. The following imports
wildmatch, nothing new there. The last patch limits allowed syntax to
a safe subset: "abc/**", "**/def" and "abc/**/def".
Nguyễn Thái Ngọc Duy (10):
gitignore: make pattern parsing code a separate function
attr: avoid strle
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/attr.c b/attr.c
index b52efb5..2942bf6 100644
--- a/attr.c
+++ b/attr.c
@@ -277,6 +277,7 @@ static struct match_attr *parse_attr_line(const char *line,
const char *src,
stat
On Wed, Oct 3, 2012 at 6:14 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Junio C Hamano writes:
>>
>>> * "git grep" learned to use a non-standard pattern type by default if
>>>a configuration variable tells it to.
>>
>> This addition makes
>>
>> git grep -e "(integer|buffer)"
dowild() does case insensitive matching by lower-casing the text. That
means lower case letters in patterns imply case-insensitive matching,
but upper case means exact matching.
We do not want that subtlety. Lower case pattern too so iwildmatch()
always does what we expect it to do.
Signed-off-by
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize()
APIs keep a leading slash in the return value if one was present on
the argument, which can be useful since it allows relative and
absolute paths to be distinguished.
When git-svn's canonicalize_path() learned to use these function
Am 10/4/2012 9:39, schrieb Nguyễn Thái Ngọc Duy:
> - - If the pattern does not contain a slash '/', git treats it as
> - a shell glob pattern and checks for a match against the
> - pathname relative to the location of the `.gitignore` file
> - (relative to the toplevel of the work tree if not
> From the help page:
>
> --assume-unchanged, --no-assume-unchanged
> ...
>
> This option can be also used as a coarse file-level mechanism to
> ignore uncommitted changes in tracked files (akin to what .gitignore
> does for untracked files).
>
> Seems like it does everything required.
From: "Andrew Ardill"
On 5 October 2012 07:20, Marco Craveiro
wrote:
...
Similar but not quite; the idea is that you know that there is some
code (I'm just talking about files here, so lets ignore hunks for the
moment) which is normally checked in but for a period of time you
want
it ignored
58 matches
Mail list logo
