On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Assuming that the above guess is correct (which is a huge
>> assumption, given the lack of clarity in the description), I think
>> the feature might make sense. The example would have been a lot
>> easier to foll
Johannes Sixt writes:
> Am 10/9/2012 7:08, schrieb Junio C Hamano:
>> Imagine if we allowed only one attribute per line, instead of
>> multiple attributes on one line.
>>
>> - If you want to unset the attribute, you would write "path -attr".
>>
>> - If you want to reset the attribute to u
On Mon, Oct 8, 2012 at 8:05 AM, Johannes Sixt wrote:
> Am 05.10.2012 18:57, schrieb Shawn Pearce:
>> On Thu, Oct 4, 2012 at 11:24 PM, Johannes Sixt wrote:
>>> Upload-pack can just start
>>> advertising refs in the "v1" way and announce a "v2" capability and listen
>>> for response in parallel. A
Junio C Hamano writes:
> Assuming that the above guess is correct (which is a huge
> assumption, given the lack of clarity in the description), I think
> the feature might make sense. The example would have been a lot
> easier to follow if it were something like this:
>
> $ git submodule for
Am 10/9/2012 7:08, schrieb Junio C Hamano:
> Imagine if we allowed only one attribute per line, instead of
> multiple attributes on one line.
>
> - If you want to unset the attribute, you would write "path -attr".
>
> - If you want to reset the attribute to unspecified, you would
>write
David Aguilar writes:
> I would advise against the file locking, though. You ain't gonna need
> it ;-)
What do you suggest to merge Word files?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
Jay Soffian writes:
> Teach "git submodule foreach" a --revision option. This
> is useful in combination with $sha1 to perform git commands that
> take a revision argument.
The above says:
- "--revision T" is added.
OK. There is no information whatsoever what it does to convince
us wh
Nguyễn Thái Ngọc Duy writes:
> .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 attr. Basicall
On Mon, Oct 8, 2012 at 11:30 AM, Matthieu Moy
wrote:
> Ramkumar Ramachandra writes:
>
>>> So, is it possible to lock a file while someone work on it ?
>>
>> No, and I honestly think it's a bad idea.
>
> If you work on non-mergeable files (e.g. *.doc files. There are merge
> tools for MS Word and
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 38 ++
t/t3001-ls-files-others
"foo/**/bar" matches "foo/x/bar", "foo/x/y/bar"... but not
"foo/bar". We make a special case, when foo/**/ is detected (and
"foo/" part is already matched), try matching "bar" with the rest of
the string.
"Match one or more directories" semantics can be easily achieved using
"foo/*/**/bar".
This
Standard wildmatch() sees consecutive asterisks as "*" that can also
match slashes. But that may be hard to explain to users as
"abc/**/def" can match "abcdef", "abcxyzdef", "abc/def", "abc/x/def",
"abc/x/y/def"...
This patch changes wildmatch so that users can do
- "**/def" -> all paths ending w
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
One place less to worry about thread safety. Also combine wildmatch
and iwildmatch into one.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-wildmatch.c | 4 ++--
wildmatch.c | 23 ++-
wildmatch.h | 3 +--
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git
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
---
.gitignore
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 161
wildmatch.h | 2 -
2 files changed, 9 insertions(+), 154 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index f3a1731..71dba76 100644
--- a/wildmatch.c
+++ b/wildmatch.
These files are from rsync.git commit
f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit
before rsync turned GPL-3. All files are imported as-is and
no-op. Adaptation is done in a separate patch.
rsync.git -> git.git
lib/wildmatch.[ch] wildmatch.[ch]
wildtest.txt
Still experimental but the semantics is getting better, I think.
Please point out what you think still does not make sense. Quote from
the last patch:
Two consecutive asterisks ("`**`") in patterns matched against
full pathname may have special meaning:
- A leading "`**`" followed by a s
.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 attr. Basically it tries to
avoid fnmatch as much as poss
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
Signed-off-by: Junio C Hamano
---
No changes.
dir.c | 71 ++-
dir.h | 2 +-
2 files changed, 50 insertions(
On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano wrote:
> * Unify pathspec semantics
>
>This has happened and commands that used to take only path prefix
>style pathspecs now take globs as well [ND]
I've been thinking about it lately and will probably restart soon with
a different approach
Marcel Partap writes:
> Dear Git Devs,
> I love GIT, but since a couple of months I'm on 3G and after my traffic
> limit is transcended, things slow down to a feeble 8KiB/s. Jst like
> back then - things moved somewhat slower. And I'm fine with that - as
> long as things just keep moving.
> U
Teach "git submodule foreach" a --revision option. This
is useful in combination with $sha1 to perform git commands that
take a revision argument. For example:
$ git submodule foreach --revision v1.0 'git tag v1.0 $sha1'
Previously, this would have required multiple steps:
$ git checkout v1
Junio C Hamano writes:
> In other words, you can do this from the command line if you want
> to do the update.
>
> $ git fetch origin master:refs/remotes/origin/master
Now having said all that, we should probably revisit this and
possibly other issues and for the ones we can reach concensus, s
From: "Thomas Ackermann"
There are "patched QT" and "unpatched QT" versions of wkhtmltopdf
(see http://code.google.com/p/wkhtmltopdf/). I am using V0.9.9 for
Windows
which is "patched QT".
There is one drawback with wkhtmltopdf: At least on my Netbook (Win7
64bit,
Pentium 1.5GHz) it is very
On 10/08/12 17:36, Thiago Farina wrote:
> OK, after running ./configure I tried the make command again.
>
> CC credential-store.o
> /bin/sh: clang: not found
> make: *** [credential-store.o] Error 127
>
> $ which clang
> /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang
>
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
>
> Instead of using a pip
(Not sure if you guys are using Google Code's Issue Tracker; if so, I
originally filed this here:
https://code.google.com/p/git-core/issues/detail?id=18 )
What steps will reproduce the problem?
1. Build git from source.
2. Download git-manpages-*.
3. Install both.
4. Attempt to build and install c
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
On Mon, Oct 8, 2012 at 6:36 PM, Thiago Farina wrote:
> On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong wrote:
>> On 10/07/12 20:39, Thiago Farina wrote:
>>> When trying to build from source but it's failing:
>>>
>>> $ sudo make prefix=/usr/local all
>>> LINK git-credential-store
>>> gcc: @CHARSET
On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong wrote:
> On 10/07/12 20:39, Thiago Farina wrote:
>> When trying to build from source but it's failing:
>>
>> $ sudo make prefix=/usr/local all
>> LINK git-credential-store
>> gcc: @CHARSET_LIB@: No such file or directory
>> make: *** [git-credential-
Ben Walton writes:
> On Mon, Oct 8, 2012 at 6:45 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
Thanks, but is "-p" essential for this test to pass, or can we get
away with just "-R"?
>>>
>>> Besides, when you spot a potential problem, please ask "git grep"
>>> to catch them a
Simon Oosthoek writes:
> How about "This has advantages for using color without running
> into prompt-wrapping issues. Only by assigning \[ and \] to PS1
> directly can bash know these and the color codes in between don't
> count in the length of the prompt."?
>
> I'll rewrite the patch later on.
Hi,
(Sorry for the delayed reply, was out of town.)
On Tue, Oct 02, 2012 at 11:04:43AM -0400, Andrew Wong wrote:
> Refactored the code for binding modified function keys as Junio suggested.
>
> Andrew Wong (2):
> gitk: Refactor code for binding modified function keys
> gitk: Use bindshiftfu
Junio C Hamano wrote:
> Let's do this, then.
I think it would be nicer to start with the important info (git
supports ssh, git, http, https) and deal with less important parts
like rsync support later in the document, but this looks like a good
minimal fix. Thanks for pushing it to completion.
The latest maintenance release Git v1.7.12.3 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
a071f03f6aab76b283828db1fdedbedb90085eb5 git-1.7.12.3.tar.gz
6f976c27aab7250f1a35b2b002ac7a0
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
A release candidate Git v1.8.0-rc1 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
625f820554f19f76da86258b7cc67408da032fea git-1.8.0.rc1.tar.gz
47be50c68d9fcd1c83bfea01c18a
On Mon, Oct 8, 2012 at 6:45 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Thanks, but is "-p" essential for this test to pass, or can we get
>>> away with just "-R"?
>>
>> Besides, when you spot a potential problem, please ask "git grep"
>> to catch them all.
>
> In other words, how ab
Hi Junio
thanks for your feedback!
On 08/10/12 20:12, Junio C Hamano wrote:
> Simon Oosthoek writes:
>
>> 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
'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
Instead of using a pipe, we separate 'format-patch' and
Here's an alternate method for handling 'format-patch' failing. We remove the
pipe between 'format-patch' and 'am' by storing the patch in an intermediate
file. This means we can gurantee that 'am' is always invokved with the complete
input.
I did some timing on rebasing 500 commits from the git
Junio C Hamano writes:
> Angelo Borsotti writes:
>
>> git fetch does not create the remote refs in
>> the current (local)
>> repository...
>> However, if a git fetch origin is executed, the refs are properly created:
>
> Working as designed and documented.
>
> $ git fetch origin master
>
> is
Angelo Borsotti writes:
> git fetch does not create the remote refs in
> the current (local)
> repository...
> However, if a git fetch origin is executed, the refs are properly created:
Working as designed and documented.
$ git fetch origin master
is giving the refspec "master" from the com
Ramkumar Ramachandra writes:
>> So, is it possible to lock a file while someone work on it ?
>
> No, and I honestly think it's a bad idea.
If you work on non-mergeable files (e.g. *.doc files. There are merge
tools for MS Word and LibreOffice, but my experience with them was not
really pleasant)
Dear Git Devs,
I love GIT, but since a couple of months I'm on 3G and after my traffic
limit is transcended, things slow down to a feeble 8KiB/s. Jst like
back then - things moved somewhat slower. And I'm fine with that - as
long as things just keep moving.
Unfortunately, git does not scale dow
Johannes Sixt writes:
> Am 08.10.2012 18:13, schrieb Junio C Hamano:
>> Michael Haggerty writes:
>>> 2. Does there need to be any special related to DOS paths?
>>
>> The ceiling computation may need special case for dos. What does
>> the getcwd() give us? Do we learn only the path within the
Am 08.10.2012 18:13, schrieb Junio C Hamano:
> Michael Haggerty writes:
>> 2. Does there need to be any special related to DOS paths?
>
> The ceiling computation may need special case for dos. What does
> the getcwd() give us? Do we learn only the path within the "current
> drive" and need to p
Simon Oosthoek writes:
> 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
Is "and I think" necessary? I do n
From: Jan H. Schönherr
Encoded characters add more than one character at once to an encoded
header. Include all characters that are about to be added in the length
calculation for wrapping.
Additionally, RFC 2047 imposes a maximum line length of 76 characters
if that line contains an rfc2047 enc
From: Jan H. Schönherr
Currently, an open-coded loop to calculate the length of the last
line of a string buffer is used in multiple places.
Move that code into a function of its own.
Signed-off-by: Jan H. Schönherr
---
pretty.c | 25 +
1 Datei geändert, 13 Zeilen hinz
From: Jan H. Schönherr
Do not wrap the second and later lines of an ASCII header substantially
before the 78 character limit.
Signed-off-by: Jan H. Schönherr
---
pretty.c| 2 +-
t/t4014-format-patch.sh | 60 -
2 Dateien geändert,
Junio C Hamano writes:
>> Thanks, but is "-p" essential for this test to pass, or can we get
>> away with just "-R"?
>
> Besides, when you spot a potential problem, please ask "git grep"
> to catch them all.
In other words, how about doing this instead?
-- >8 --
Subject: tests: "cp -a" is a GNU
Hi all.
The main point of this series is to teach git to encode my name
correctly, see patch 4, so that the decoded version is actually
my name, so that send-email does not insist on adding a wrong
superfluous From: line to the mail body.
But as always, you notice some other things going wrong. H
From: Jan H. Schönherr
Do some checks for RFC 822 and RFC 2047 support in To:
and Cc: headers and fix ambiguous old checks.
Signed-off-by: Jan H. Schönherr
---
t/t4014-format-patch.sh | 98 +
1 Datei geändert, 66 Zeilen hinzugefügt(+), 32 Zeilen
From: Jan H. Schönherr
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822
quoted strings do not mix.
Be more strict about rfc2047 encoded words in addresses, so that it is a
bit more conform to RFC 2047.
(Especially, my own name gets correctly decoded as Jan H. Schönherr
(w
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> I'd suggest dropping ", and will soon be removed." or replacing it
>> with ". Don't use them." to avoid the question of how soon "soon" is.
>>
>> With that change and with a clearer commit message, this will probably
>> be good to go imho.
>
Jeff King writes:
> On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:
>
>> Please do not label the list as "These variables affect this
>> command" to give a false impression that it is the complete list if
>> it isn't.
>>
>> Unless somebody promises to keep an up-to-date complete
Junio C Hamano writes:
> Ben Walton writes:
>
>> Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a
>> to -pR.
>>
>> Signed-off-by: Ben Walton
>> ---
>
> Thanks, but is "-p" essential for this test to pass, or can we get
> away with just "-R"?
Besides, when you spot a potent
Mark Hills writes:
> We make extensive use of unix permissions and core.sharedRepository --
> multiple developers push to the same repo.
>
> I have often wondered why core.sharedRepository is needed at all as a
> separate configuration?
>
> It looks like it might be easier (and less confusing t
Hi,
is there a way to tell git diff about lines that are uninteresting?
I mean lines which do not contain a lot of information and
appear several times in pre and post image.
For example whitespace or language dependent stuff like.
{
}
END_IF;
END_FOR;
end sub
I have seen diffs that containing
Ben Walton writes:
> Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a
> to -pR.
>
> Signed-off-by: Ben Walton
> ---
Thanks, but is "-p" essential for this test to pass, or can we get
away with just "-R"?
> t/t5400-send-pack.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 d
Junio C Hamano writes:
> Jeff King writes:
>
>> On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote:
>>
>>> Yeah, modulo that the "defaults" is tracked and does not have to
>>> have the dash before "include" (it is an error if it is missing,
>>> no?). It may want to be named with s/d
Andreas Ericsson writes:
> You'll want that to be a single "wants" message to avoid incurring
> insane amounts of roundtrip latency with lots of refs. github and
> other hosted services are quite popular, but with my 120ms ping
> rtt I'd be spending half a minute just telling the other side what
Michael Haggerty writes:
> On 10/01/2012 06:51 AM, Michael Haggerty wrote:
>> I think I would advocate that the prefix has to match the front of the
>> path exactly (including any trailing slashes) and either
>>
>> strlen(prefix) == 0
>> or the prefix ended with a '/'
>> or the prefi
On 10/07/12 20:39, Thiago Farina wrote:
> When trying to build from source but it's failing:
>
> $ sudo make prefix=/usr/local all
> LINK git-credential-store
> gcc: @CHARSET_LIB@: No such file or directory
> make: *** [git-credential-store] Error 1
Did you run the "configure" script?
In the so
Nguyen Thai Ngoc Duy writes:
> My objection is no-op lines are timed bombs. But users can already do
> "dir attr" (no slashes), which is no-op. So yeah, no-op is fine.
Exactly. If you are not catching and barfing the no-slashed variant
at the syntax level (and you shouldn't), you shouldn't do so
Jonathan Nieder writes:
> I'd suggest dropping ", and will soon be removed." or replacing it
> with ". Don't use them." to avoid the question of how soon "soon" is.
>
> With that change and with a clearer commit message, this will probably
> be good to go imho.
Yup; thanks.
--
To unsubscribe fro
Am 05.10.2012 18:57, schrieb Shawn Pearce:
> On Thu, Oct 4, 2012 at 11:24 PM, Johannes Sixt wrote:
>> Upload-pack can just start
>> advertising refs in the "v1" way and announce a "v2" capability and listen
>> for response in parallel. A v2 capable client can start sending "wants" or
>> some other
Hi Junio
I hope you found my patches, if not, I'll try to send them out again.
(Unfortunately my current mail setup is a mess and I need time to figure
out what to fix...)
As for the zsh support, I found out a little bit more.
ZSH doesn't have a variable like PROMPT_COMMAND in bash. The precm
2012/10/6 Junio C Hamano :
> Ramsay Jones writes:
>
>> The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK
>> variable, either from the environment or command line of an
>> 'make test' invocation. In order to allow the malloc checks to be
>> disabled from the 'config.mak' file, we add
We make extensive use of unix permissions and core.sharedRepository --
multiple developers push to the same repo.
I have often wondered why core.sharedRepository is needed at all as a
separate configuration?
It looks like it might be easier (and less confusing to users) to derive
this attribut
On 10/07/2012 09:57 PM, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> I'm creating a system where a lot of remotes constantly fetch from a
>>> central repository for deployment purposes, but I've noticed that even
Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a
to -pR.
Signed-off-by: Ben Walton
---
t/t5400-send-pack.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 250c720..65b3b0f 100755
--- a/t/t5400-send-pack.s
Ramkumar Ramachandra wrote:
> I see. Will we remove ftp[s] support too? I hope this is in order.
I don't see why that would be desirable, as long as libcurl continues
to support it for free.
[...]
> Fetching and pushing over rsync, and fetching over ftp or ftps are
> deprecated, and will soon
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>>
>>> With a weaker phrase, e.g. "These configuration variables may be of
>>> interest", such a list may not hurt readers, but personally I do not
>>> think it adds much value to have a list of variables without even
Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Ramkumar Ramachandra wrote:
Thomas Ferris Nicolaisen writes:
>>
> At least according to the documentation[1], "Git natively supports [...]
> ftp".
>
> This could need some clarification if pushing over ftp is not supported
77 matches
Mail list logo