Re: Fw: [git-users] How do I git-push to an FTP server?
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Ramkumar Ramachandra wrote:
Thomas Ferris Nicolaisen tfn...@gmail.com writes:
At least according to the documentation[1], Git natively supports [...]
ftp.
This could need some clarification if pushing over ftp is not supported.
[...]
-Git natively supports ssh, git, http, https, ftp, ftps, and rsync
-protocols. The following syntaxes may be used with them:
+Git natively supports ssh, git, http, https, and rsync protocols. The
+following syntaxes may be used with them:
Perhaps the initial list should not be exhaustive, in which case we
could say:
Git natively supports ssh, git, http, and https protocols. The
following syntaxes may be used with them:
...
Git also has (less efficient) support for fetching and pushing
over rsync protocol and fetching over ftp or ftps, using the
same protocol://host/path/to/repo.git/ syntax.
Yeah, that, possibly with These are deprecated; do not use them.,
would be a better way forward. As we deprecated rsync long time
ago, perhaps we should remove it at Git 2.0 or somewhere around
that.
I see. Will we remove ftp[s] support too? I hope this is in order.
-- 8 --
From: Ramkumar Ramachandra artag...@gmail.com
Date: Sun, 7 Oct 2012 20:57:15 +0530
Subject: [PATCH] Documentation/urls: mark rsync and ftp[s] as deprecated
Fetching and pushing over rsync, and fetching over ftp or ftps are
deprecated, and will soon be removed. Add a note saying this.
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/urls.txt | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 2890194..653b61c 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -6,14 +6,12 @@ address of the remote server, and the path to the repository.
Depending on the transport protocol, some of this information may be
absent.
-Git natively supports ssh, git, http, https, ftp, ftps, and rsync
-protocols. The following syntaxes may be used with them:
+Git natively supports ssh, git, http, and https protocols. The
+following syntaxes may be used with them:
- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
- git://host.xz{startsb}:port{endsb}/path/to/repo.git/
- http{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/
-- ftp{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/
-- rsync://host.xz/path/to/repo.git/
An alternative scp-like syntax may also be used with the ssh protocol:
@@ -31,6 +29,11 @@ syntaxes may be used:
- /path/to/repo.git/
- file:///path/to/repo.git/
+ Git also has (less efficient) support for fetching and pushing over
+ rsync protocol and fetching over ftp or ftps, using the same
+ protocol://host/path/to/repo.git/ syntax. However, these are
+ deprecated, and will soon be removed.
+
ifndef::git-clone[]
These two syntaxes are mostly equivalent, except when cloning, when
the former implies --local option. See linkgit:git-clone[1] for
--
1.7.12.1.428.g652398a.dirty
--
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: push.default documented in man git-push?
Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com 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 a single line description of what each is used for. Okay. Does this work? Hrm, is it useful without even a single line description of what each is used for? Should we replicate the description from git-config[1]? That seems like a waste. Besides, how does it appear in the formatted documents? A thick paragraph that lists names of variables enumerated without comma in between? Oops; I didn't build it and check. Ram -- 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: Fw: [git-users] How do I git-push to an FTP server?
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 be removed. Add a note saying this. I thought the real rationale was to avoid creating the illusion of supporting push over ftp. Having a paper trail to comfort people who notice when rsync support vanishes is just an added bonus. [...] @@ -31,6 +29,11 @@ syntaxes may be used: - /path/to/repo.git/ - file:///path/to/repo.git/ + Git also has (less efficient) support for fetching and pushing over + rsync protocol and fetching over ftp or ftps, using the same + protocol://host/path/to/repo.git/ syntax. However, these are + deprecated, and will soon be removed. 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. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t/t5400-send-pack: Use POSIX options to cp for portability
Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a to -pR. Signed-off-by: Ben Walton bdwal...@gmail.com --- 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.sh +++ b/t/t5400-send-pack.sh @@ -159,7 +159,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' ' git commit -a -m Second commit git repack ) - cp -a parent child + cp -pR parent child ( # Set the child to auto-pack if more than one pack exists cd child -- 1.7.12 -- 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: Is anyone working on a next-gen Git protocol?
On 10/07/2012 09:57 PM, Ævar Arnfjörð Bjarmason wrote: On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com 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 with a remote.$name.fetch configuration to only get certain refs a git fetch will still call git-upload pack which will provide a list of all references. It has been observed that the sender has to advertise megabytes of refs because it has to speak first before knowing what the receiver wants, even when the receiver is interested in getting updates from only one of them, or worse yet, when the receiver is only trying to peek the ref it is interested has been updated. Has anyone started working on a next-gen Git protocol as a result of this discussion? If not I thought I'd give it a shot if/when I have time. The current protocol is basically (S = Server, C = Client) S: Spew out first ref S: Advertisement of capabilities S: Dump of all our refs C/S: Declare wanted refs, negotiate with server S: Send pack to client, if needed And I thought I'd basically turn it into: C: Connect to server, declare what protocol we understand C: Advertisement of capabilities S: Advertisement of capabilities C/S: Negotiate what we want C/S: Same as v1, without the advertisement of capabilities, and maybe don't dump refs at all Basically future-proofing it by having the client say what it supports to begin with along with what it can handle (like in HTTP). Then in the negotiation phase the client server would go back forth about what they want how they want it. I'd planned to implement something like: C: want_refs refs/heads/* S: OK to that C: want_refs refs/tags/* S: OK to that Or: C: want_refs refs/heads/master S: OK to that C: want_refs refs/tags/v* S: OK to that 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 I want when I fetch from a repo with 250 refs. It's a flagday and a half to change the protocol though, so I expect it'll have to wait for 2.0, unless the current client-side part of it is dumb and ignores existing refs when requesting its wants, in which case the server can just stop advertising existing refs and most of the speedup is already done. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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
sharedRepository derived from file permissions
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 attribute from the top-level .git directory? For many years in our organisation we have been using the scripts below to make it easier for users to configure a repository -- a one-time operation. Is there a reason why Git doesn't just follow (and echo) the top-level permissions? Many thanks -- Mark #!/bin/bash # # Propagate permissions of the top-level directory through a repository, # and configure it for use. # if [ $1 = --help ]; then echo Usage: $0 bare_git_repo.git echo Fix permissions on a Git repository, based on the permissions echo at the top level directory. exit 0 fi if [ -z $1 ]; then echo Repository argument is mandatory (see --help); aborting. exit 1 fi REPO=$1 if [ ! -d $REPO/objects -o ! -f $REPO/config -o ! -f $REPO/HEAD ]; then echo $REPO does not look like a bare Git repository; aborting. exit 1 fi # Fix ownership chown -cR --reference=$REPO $REPO/* # Fix all the directory permissions after ownership (setting ownership # removes setgid bit) find $REPO -type d | xargs chmod -c --reference=$REPO # Fix files find $REPO -type f | xargs chmod --reference=$REPO find $REPO -type f | xargs chmod a-sx # Tidy up; permissions on object files are always 444 find $REPO/objects -type f | xargs chmod 0444 # Configure the repository to remove the need for further fixes # by basing core.SharedRepository on the top level permissions PERM=0`stat -c '%a' $REPO` MODE=`printf %04o $(($PERM0666))` # bash required if [ $MODE = 0660 ]; then MODE=group elif [ $MODE = 0666 ]; then MODE=all fi git --git-dir $REPO repo-config core.sharedRepository $MODE chmod --reference=$REPO $REPO/config chmod a-sx $REPO/config -- 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] MALLOC_CHECK: Allow checking to be disabled from config.mak
2012/10/6 Junio C Hamano gits...@pobox.com: Ramsay Jones ram...@ramsay1.demon.co.uk 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 TEST_NO_MALLOC_CHECK to the environment using an export directive. We would want to encourage people to test with cheap but effective checks when available. I do not see malloc: using debugging hooks message anywhere when I run tests, but if you do, I'd rather see us check if we can tell glibc to stop doing so first without disabling the whole test. Your patch feels like the first step to a slipperly slope whose destination would make us say we get too many messages so let's do nothing in make test with this configuration. when taken to the extreme, and obviously we would not want to go there ;-). Elia, you brought the MALLOC_CHECK_ up. Did you hear about this issue elsewhere before, and if you did, do you know how other projects solves it? Ok. I have found. For me this is not a problem any more these days. Was fixed in glibc 2.8.90-9 2008 * Wed Jul 16 2008 Jakub Jelinek ja...@redhat.com 2.8.90-9 - update from trunk - fix unbuffered vfprintf if writing to the stream fails (#455360) - remove useless malloc: using debugging hooks message (#455355) - nscd fixes (from glibc rpm changelog) This is the bugzilla filled and closed https://bugzilla.redhat.com/show_bug.cgi?id=455355 Ramsay, what version of glibc you have and in what distro? thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND
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 precmd name is a function the user has to define herself to have it called before the prompt is shown. Functionally this is almost, but not quite, the same as PROMPT_COMMAND. The subtle difference is that with PROMPT_COMMAND you can use parameters to customize the prompt, so in bash you can say: PROMPT_COMMAND=__git_ps1 '\u@\[\e[1;34m\]\h\[\e[0m\]:\w' '\\\$ ' where in zsh, if you want the status in the prompt, you can either use $(__git_ps1 (%s)) or something like it in setting the PS1 (and forget about the color hints!) or you can copy the __git_ps1 function and modify and rename it as precmd to set PS1 via that function. Obviously it is probably even more complicated, but I'd have to try it to be certain. An alternative way might be to set special variables from __git_set_vars function which may be used in a custom precmd to set the prompt. e.g. say __git_set_vars sets __GIT_VAR_STATE=dirty|stage|clean in precmd you could do case $__GIT_VAR_STATE in (dirty) PS1=$PS1 files modified in __GIT_VAR_BRANCHNAME ;; (stage) PS1=$PS1 files staged in __GIT_VAR_BRANCHNAME ;; (clean) PS1=$PS1 __GIT_VAR_BRANCHNAME clean ;; esac (more or less of course).. In that way it would be possible to add the colors relatively easily based on the state of the tree in a custom precmd function of zsh. /Simon -- 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: upload-pack is slow with lots of refs
Am 05.10.2012 18:57, schrieb Shawn Pearce:
On Thu, Oct 4, 2012 at 11:24 PM, Johannes Sixt j.s...@viscovery.net 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 signal as soon as it sees the v2 capability. Upload-pack,
which was listening for responses in parallel, can interrupt its
advertisements and continue with v2 protocol from here.
This sounds so simple (not the implementation, of course) - I must be
missing something.
Smart HTTP is not bidirectional. The client can't cut off the server.
Smart HTTP does not need it: you already posted a better solution (I'm
refering to v=2).
Its also more complex to code the server to listen for a stop command
from the client at the same time the server is blasting out useless
references to the client.
At least the server side does not seem to be that complex. See below.
Of course, the server blasted out some refs, but I'm confident that in
practice the client will be able to signal v2 capability after a few packets
of advertisements. You can switch on TCP_NODELAY for the first line with
the capabilities to ensure it goes out on the wire ASAP.
diff --git a/upload-pack.c b/upload-pack.c
index 2e90ccb..c29ae04 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -720,11 +720,20 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int client_spoke(void)
+{
+ struct pollfd pfd;
+ pfd.fd = 0;
+ pfd.events = POLLIN;
+ return poll(pfd, 1, 0) 0
+ (pfd.revents (POLLIN|POLLHUP));
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
side-band-64k ofs-delta shallow no-progress
-include-tag multi_ack_detailed;
+include-tag multi_ack_detailed version2;
struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
@@ -752,7 +761,8 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
if (o)
packet_write(1, %s %s^{}\n, sha1_to_hex(o-sha1),
refname_nons);
}
- return 0;
+
+ return client_spoke();
}
static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
@@ -771,8 +781,14 @@ static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
- head_ref_namespaced(send_ref, NULL);
- for_each_namespaced_ref(send_ref, NULL);
+ if (head_ref_namespaced(send_ref, NULL) ||
+ for_each_namespaced_ref(send_ref, NULL)) {
+ /*
+* TODO: continue with protocol version 2
+* optimization: do not send refs
+* that were already sent
+*/
+ }
packet_flush(1);
} else {
head_ref_namespaced(mark_our_ref, NULL);
--
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: Fw: [git-users] How do I git-push to an FTP server?
Jonathan Nieder jrnie...@gmail.com 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 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 04/10] attr: more matching optimizations from .gitignore
Nguyen Thai Ngoc Duy pclo...@gmail.com 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 for slashed ones. -- 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: Proposed function path_in_directory()
Michael Haggerty mhag...@alum.mit.edu 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 prefix and path are identical or the character in path following the matching part is a '/' This would allow the is path its own prefix policy to be decided by the caller by either including or omitting a trailing slash on the prefix argument. Thinking about this more, I don't think it will work. As usual, the special cases around / and // make things awkward. I think it is necessary to have a separate argument to specify whether path is its own prefix. So I am trying to decide how a function path_in_directory() should work, and would like to get some feedback, especially on the following two points: 1. How should // be handled? I don't really have experience with the peculiar paths that start with //, so I'm not sure how they should be handled (or even if the handling needs to be platform-dependent). My working hypothesis is that the inputs should be normalized by the caller, so if the caller wants // to be treated as equivalent to / then the caller should normalize them *before* calling this function. Conversely, if the caller passes // to the function, that implies that // is distinct from / and // is considered a proper subdirectory of /. See the cases marked with ?? below. I think POSIX essentially says that anything that begins with // is up to the platform, but in practice, the only real-life variant we see is //dosshare/path/from/root. I agree with your caller should normalize for the semantics it wants to see. If our lazy programming creates paths with duplicated slashes, we should be fixing such codepaths anyway, so assuming that all paths we create ourselves are free of double-slashes _inside_ a path (i.e. when concatenating a subdirectory name to a directory name), the only case we need to worry about is the double-slashes given by the user (either from the command line, environment, or configuration). The path normalizing logic removes double-slashes inside a path, and I think it should do so while keeping the leading slashes, so that we do not lose distinction between //dosshare/ and /dosshare/. 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 prefix C: (or D: or X:) ourselves if we really want to tell C:\bin and D:\bin apart? Assuming that is the case, the ceiling computation would need a helper function that hides the gory details of prefixing getcwd() result with drive letter or whatever needed, and another that normalizes the elements of the environment variables (I presume that if an element in it without the drive prefix should be normalized to add the current drive letter to it so that the normalized getcwd() result can be compared with it). E.g. if the ceiling list is D:/a/b;/trash/ then getcwd() returning /a alone does not make it outside the ceiling due to D:/a/b---our current drive must be D for that pattern to kick in. The unqualified /trash would apply to any drive. Does that make sense? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anyone working on a next-gen Git protocol?
Andreas Ericsson a...@op5.se 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 I want when I fetch from a repo with 250 refs. Peff's recent patch when applied on the server side would help alleviate the load to produce these refs, but it obviously would not cut the network cost. In order to change this, we need to swap who speaks first. Once we go into want/have phase, I do not think there is a need for fundamental change in the protocol (by this, I am not counting a change to send haves sparsely and possibly backtracking to bisect history, etc. as fundamental). -- 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] Allow generating a non-default set of documentation
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net 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/defaults/autodetect/, though. diff --git a/Makefile b/Makefile index e3e3cd5..c00fd32 100644 --- a/Makefile +++ b/Makefile ... -endif - +-include config.mak.defaults -include config.mak.autogen -include config.mak Yeah, sorry, mindless copying on my part from the lines below. It clearly should not have the -. I'm fine with something besides defaults. I meant it to be these are the config defaults before you tweak them, but yeah, it is more like these are the config options we picked up from uname. Let's put this on hold in the possibly a good direction to go in pile, and defer it to post 1.8.0; I haven't even looked at (and do not plan to before the release) these auto-detect bits are all safe to be included in Makefiles in subdirectories. Oh by the way, by this (on hold) I meant not just your move the default-by-platform to a separate include, but the whole a platform may not want manpages topic. The patch posted was merely me wanting to format git-push.txt and nothing else when sanity checking a patch to that file, and it is insufficient for the purpose of a platform may not want manpages without a matching change to the install target. Even though your include thing was primarily done to make it easier to include it from Makefiles in subdirectories, I very much like it even without that benefit. The change makes it clear that there is another platform specific bit after '-include config.mak' (yes, I am looking at you, Darwin), which is a huge eyesore we would want to do something about. -- 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] t/t5400-send-pack: Use POSIX options to cp for portability
Ben Walton bdwal...@gmail.com writes: Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a to -pR. Signed-off-by: Ben Walton bdwal...@gmail.com --- 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 deletion(-) diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index 250c720..65b3b0f 100755 --- a/t/t5400-send-pack.sh +++ b/t/t5400-send-pack.sh @@ -159,7 +159,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' ' git commit -a -m Second commit git repack ) - cp -a parent child + cp -pR parent child ( # Set the child to auto-pack if more than one pack exists cd child -- 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
Ignoring boring lines(that do not contain information) in git diff
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 2 interesting hunks splitted by such
boring lines.
(I have attached a anonymized version of a real world example where this
happens)
I think the diff would be clearer when this boring line was added to the
surrounding hunks.
I already tried patience diff but in my test case it changed nothing.
I am using git 1.7.10.
Thanks,
Greetings Peter
diff --git a/Source/Frobble/Blabber.txt b/Source/Frobble/Blabber.txt
index 87ccddb..627bc3e 100644
--- a/Source/Frobble/Blabber.txt
+++ b/Source/Frobble/Blabber.txt
@@ -138,73 +138,74 @@ END_VAR
- //frobble immediately if immediately flag is set
- IF bImmediately AND NOT Array[i].bDisabled THEN
-aFrobble(i, Entry);
+ IF Entry.bBlah THEN
+ Alarm.Alarm := SomeAlarm;
+ ELSE
+ Alarm := Entry;
END_IF;
- // signal if frobble count has changed
- iChanged := iChanged + 1;
- EXIT;
+ IF Array[i].Alarm = Alarm THEN
+//do not brabble if alarm is gobbled
+ EXIT;
+ END_IF;
END_IF;
- END_FOR;
-ELSE
- aExample(Name := 'aaa',
-ID1 := 1);
-END_IF;
+ ELSE
+ //entry not found, adding
Re: sharedRepository derived from file permissions
Mark Hills m...@pogo.org.uk 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 to users) to derive this attribute from the top-level .git directory? Hrm, clever ;-) Is there a reason why Git doesn't just follow (and echo) the top-level permissions? Other than we did not trust that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git, with a little bit of we didn't think of that when we wrote the system, I do not recall any. -- 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] t/t5400-send-pack: Use POSIX options to cp for portability
Junio C Hamano gits...@pobox.com writes: Ben Walton bdwal...@gmail.com writes: Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a to -pR. Signed-off-by: Ben Walton bdwal...@gmail.com --- 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. $ git grep cp -a t/ t/t5400-send-pack.sh: cp -a parent child t/t5550-http-fetch.sh: cp -a .git$HTTPD_DOCUMENT_ROOT_PATH/repo.git t/t5800-remote-helpers.sh: cp -a server server2 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.sh +++ b/t/t5400-send-pack.sh @@ -159,7 +159,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' ' git commit -a -m Second commit git repack ) -cp -a parent child +cp -pR parent child ( # Set the child to auto-pack if more than one pack exists cd child -- 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: push.default documented in man git-push?
Jeff King p...@peff.net 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 list there
(or even better, come up with a mechanism to help us keep that
promise automatically, perhaps by annotating pieces with structured
comments in config.txt and automatically appending such a section to
manual pages of relevant commands), that is.
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 a
single line description of what each is used for.
We talked a while ago about actually moving the config options into the
individual manpages, and generating config.txt to simply contain an
index of keys and where their definitions may be found. That also has
the list without description characteristic. But presumably you would
be looking for keys in the manual of the command you want to affect, and
the master list would mostly be for redirecting you to the right
manpage.
That cuts both ways for configuration variables that affects or are
affected by multiple commands, and that would range from the trivial
example of configuration variables for fetch and merge that appear
to take effect in git pull from the end users' perspective, to the
more complex ones like remotes.*.merge and remotes.*.url that are
set to make the @{upstream} notation work.
It does break down a little when you have keys that could go in multiple
pages. In many cases, this can be solved by a canonical location that
describes the shared concepts. For example, `diff.*` should probably go
into a `gitdiff(7)` that talks about the various diff options and
formats.
Of course, that only works if you think pulling out the shared diff bits
from git-diff*, git-log, etc into a separate manpage is a good idea. I
do, because I think it makes it more clear to the reader how the
concepts connect (as opposed to simply including shared bits inline in
the manpages, as we do now, with no indication that the same content is
going to apply in many places). But it does have a downside that
individual manpages are not as easily searchable via the pager, as you
may have to follow a cross-reference to find what you want.
I suspect that approach would make individual manual pages less
approacheable by new people, as they will have more required
reading.
git(1) currently guides people to user manual, and then points at
individual pages, assuming that these shared concepts (e.g. the one
for diff you discuss in the above paragraph) are fully mastered
once the user manual is read. Perhaps we would need to replace it
with a concepts manual, or enhance it with more concepts
material?
--
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: Fw: [git-users] How do I git-push to an FTP server?
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com 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.
Let's do this, then.
-- 8 --
From: Ramkumar Ramachandra artag...@gmail.com
Subject: Git url doc: mark ftp/ftps as read-only and deprecate them
It is not even worth mentioning their removal; just discourage
people from using them.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/urls.txt | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git i/Documentation/urls.txt w/Documentation/urls.txt
index 2890194..1d15ee7 100644
--- i/Documentation/urls.txt
+++ w/Documentation/urls.txt
@@ -6,8 +6,12 @@ address of the remote server, and the path to the repository.
Depending on the transport protocol, some of this information may be
absent.
-Git natively supports ssh, git, http, https, ftp, ftps, and rsync
-protocols. The following syntaxes may be used with them:
+Git supports ssh, git, http, and https protocols (in addition, ftp,
+and ftps can be used for fetching and rsync can be used for fetching
+and pushing, but these are inefficient and deprecated; do not use
+them).
+
+The following syntaxes may be used with them:
- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
- git://host.xz{startsb}:port{endsb}/path/to/repo.git/
--
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 4/5] format-patch: fix rfc2047 address encoding with respect to rfc822 specials
From: Jan H. Schönherr schn...@cs.tu-berlin.de
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
(without quotes) and not as Jan H. Schönherr (with quotes).)
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
pretty.c| 80 ++---
t/t4014-format-patch.sh | 11 +--
2 Dateien geändert, 71 Zeilen hinzugefügt(+), 20 Zeilen entfernt(-)
diff --git a/pretty.c b/pretty.c
index ee76219..f3a7383 100644
--- a/pretty.c
+++ b/pretty.c
@@ -231,7 +231,7 @@ static int is_rfc822_special(char ch)
}
}
-static int has_rfc822_specials(const char *s, int len)
+static int needs_rfc822_quoting(const char *s, int len)
{
int i;
for (i = 0; i len; i++)
@@ -272,7 +272,12 @@ static void add_rfc822_quoted(struct strbuf *out, const
char *s, int len)
strbuf_addch(out, '');
}
-static int is_rfc2047_special(char ch)
+enum rfc2047_type {
+ RFC2047_SUBJECT,
+ RFC2047_ADDRESS,
+};
+
+static int is_rfc2047_special(char ch, enum rfc2047_type type)
{
/*
* We encode ' ' using '=20' even though rfc2047
@@ -283,33 +288,62 @@ static int is_rfc2047_special(char ch)
if (ch == ' ' || ch == '\n')
return 1;
- return (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_'));
+ if (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_'))
+ return 1;
+
+ if (type != RFC2047_ADDRESS)
+ return 0;
+
+ /*
+* rfc2047, section 5.3:
+*
+*As a replacement for a 'word' entity within a 'phrase', for
example,
+*one that precedes an address in a From, To, or Cc header. The
ABNF
+*definition for 'phrase' from RFC 822 thus becomes:
+*
+*phrase = 1*( encoded-word / word )
+*
+*In this case the set of characters that may be used in a
Q-encoded
+*'encoded-word' is restricted to: upper and lower case ASCII
+*letters, decimal digits, !, *, +, -, /, =, and _
+*(underscore, ASCII 95.). An 'encoded-word' that appears within a
+*'phrase' MUST be separated from any adjacent 'word', 'text' or
+*'special' by 'linear-white-space'.
+*/
+
+ /* '=' and '_' are special cases and have been checked above */
+ return !(isalnum(ch) || ch == '!' || ch == '*' || ch == '+' || ch ==
'-' || ch == '/');
}
-static void add_rfc2047(struct strbuf *sb, const char *line, int len,
- const char *encoding)
+static int needs_rfc2047_encoding(const char *line, int len,
+ enum rfc2047_type type)
{
- static const int max_length = 76; /* per rfc2047 */
int i;
- int line_len = last_line_length(sb);
for (i = 0; i len; i++) {
int ch = line[i];
if (non_ascii(ch) || ch == '\n')
- goto needquote;
+ return 1;
if ((i + 1 len) (ch == '=' line[i+1] == '?'))
- goto needquote;
+ return 1;
}
- strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, 78+1);
- return;
-needquote:
+ return 0;
+}
+
+static void add_rfc2047(struct strbuf *sb, const char *line, int len,
+ const char *encoding, enum rfc2047_type type)
+{
+ static const int max_length = 76; /* per rfc2047 */
+ int i;
+ int line_len = last_line_length(sb);
+
strbuf_grow(sb, len * 3 + strlen(encoding) + 100);
strbuf_addf(sb, =?%s?q?, encoding);
line_len += strlen(encoding) + 5; /* 5 for =??q? */
for (i = 0; i len; i++) {
unsigned ch = line[i] 0xFF;
- int is_special = is_rfc2047_special(ch);
+ int is_special = is_rfc2047_special(ch, type);
if (line_len + 2 + (is_special ? 3 : 1) max_length) {
strbuf_addf(sb, ?=\n =?%s?q?, encoding);
@@ -355,13 +389,18 @@ void pp_user_info(const struct pretty_print_context *pp,
name_tail--;
display_name_length = name_tail - line;
strbuf_addstr(sb, From: );
- if (!has_rfc822_specials(line, display_name_length)) {
- add_rfc2047(sb, line, display_name_length, encoding);
- } else {
+ if (needs_rfc2047_encoding(line, display_name_length,
RFC2047_ADDRESS)) {
+ add_rfc2047(sb, line, display_name_length,
+ encoding, RFC2047_ADDRESS);
+ } else if (needs_rfc822_quoting(line, display_name_length)) {
[PATCH 5/5] format-patch: tests: check rfc822+rfc2047 in to+cc headers
From: Jan H. Schönherr schn...@cs.tu-berlin.de 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 schn...@cs.tu-berlin.de --- t/t4014-format-patch.sh | 98 + 1 Datei geändert, 66 Zeilen hinzugefügt(+), 32 Zeilen entfernt(-) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 1a3b6e8..65ab4c9 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -110,73 +110,107 @@ test_expect_success 'replay did not screw up the log message' ' test_expect_success 'extra headers' ' - git config format.headers To: R. E. Cipient rcipi...@example.com + git config format.headers To: R E Cipient rcipi...@example.com - git config --add format.headers Cc: S. E. Cipient scipi...@example.com + git config --add format.headers Cc: S E Cipient scipi...@example.com git format-patch --stdout master..side patch2 sed -e /^\$/q patch2 hdrs2 - grep ^To: R. E. Cipient rcipi...@example.com\$ hdrs2 - grep ^Cc: S. E. Cipient scipi...@example.com\$ hdrs2 + grep ^To: R E Cipient rcipi...@example.com\$ hdrs2 + grep ^Cc: S E Cipient scipi...@example.com\$ hdrs2 ' test_expect_success 'extra headers without newlines' ' - git config --replace-all format.headers To: R. E. Cipient rcipi...@example.com - git config --add format.headers Cc: S. E. Cipient scipi...@example.com + git config --replace-all format.headers To: R E Cipient rcipi...@example.com + git config --add format.headers Cc: S E Cipient scipi...@example.com git format-patch --stdout master..side patch3 sed -e /^\$/q patch3 hdrs3 - grep ^To: R. E. Cipient rcipi...@example.com\$ hdrs3 - grep ^Cc: S. E. Cipient scipi...@example.com\$ hdrs3 + grep ^To: R E Cipient rcipi...@example.com\$ hdrs3 + grep ^Cc: S E Cipient scipi...@example.com\$ hdrs3 ' test_expect_success 'extra headers with multiple To:s' ' - git config --replace-all format.headers To: R. E. Cipient rcipi...@example.com - git config --add format.headers To: S. E. Cipient scipi...@example.com + git config --replace-all format.headers To: R E Cipient rcipi...@example.com + git config --add format.headers To: S E Cipient scipi...@example.com git format-patch --stdout master..side patch4 sed -e /^\$/q patch4 hdrs4 - grep ^To: R. E. Cipient rcipi...@example.com,\$ hdrs4 - grep ^ *S. E. Cipient scipi...@example.com\$ hdrs4 + grep ^To: R E Cipient rcipi...@example.com,\$ hdrs4 + grep ^ *S E Cipient scipi...@example.com\$ hdrs4 ' -test_expect_success 'additional command line cc' ' +test_expect_success 'additional command line cc (ascii)' ' - git config --replace-all format.headers Cc: R. E. Cipient rcipi...@example.com + git config --replace-all format.headers Cc: R E Cipient rcipi...@example.com + git format-patch --cc=S E Cipient scipi...@example.com --stdout master..side | sed -e /^\$/q patch5 + grep ^Cc: R E Cipient rcipi...@example.com,\$ patch5 + grep ^ *S E Cipient scipi...@example.com\$ patch5 +' + +test_expect_failure 'additional command line cc (rfc822)' ' + + git config --replace-all format.headers Cc: R E Cipient rcipi...@example.com git format-patch --cc=S. E. Cipient scipi...@example.com --stdout master..side | sed -e /^\$/q patch5 - grep ^Cc: R. E. Cipient rcipi...@example.com,\$ patch5 - grep ^ *S. E. Cipient scipi...@example.com\$ patch5 + grep ^Cc: R E Cipient rcipi...@example.com,\$ patch5 + grep ^ *S. E. Cipient scipi...@example.com\$ patch5 ' test_expect_success 'command line headers' ' git config --unset-all format.headers - git format-patch --add-header=Cc: R. E. Cipient rcipi...@example.com --stdout master..side | sed -e /^\$/q patch6 - grep ^Cc: R. E. Cipient rcipi...@example.com\$ patch6 + git format-patch --add-header=Cc: R E Cipient rcipi...@example.com --stdout master..side | sed -e /^\$/q patch6 + grep ^Cc: R E Cipient rcipi...@example.com\$ patch6 ' test_expect_success 'configuration headers and command line headers' ' - git config --replace-all format.headers Cc: R. E. Cipient rcipi...@example.com - git format-patch --add-header=Cc: S. E. Cipient scipi...@example.com --stdout master..side | sed -e /^\$/q patch7 - grep ^Cc: R. E. Cipient rcipi...@example.com,\$ patch7 - grep ^ *S. E. Cipient scipi...@example.com\$ patch7 + git config --replace-all format.headers Cc: R E Cipient rcipi...@example.com + git format-patch --add-header=Cc: S E Cipient scipi...@example.com --stdout master..side | sed -e /^\$/q patch7 + grep ^Cc: R E Cipient rcipi...@example.com,\$ patch7 + grep ^ *S E Cipient scipi...@example.com\$
[PATCH 0/5] Cure some format-patch wrapping and encoding issues
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. Here, patches 1 and 2 make the wrapping of header lines more correct, i. e., neither too early nor too late. Patch 3 does some refactoring, which is too unrelated to be included in patch 4 itself. Patch 5 points out further problems, but leaves the actual fixing to someone else. The series is currently based on the maint branch, but it applies to the others as well. During the creation of this series, I came across the strbuf wrapping functions, and I wonder if there is an off-by-one issue. Consider the following excerpt from t4202: cat expect EOF This is the sixth commit. This is the fifth commit. EOF test_expect_success 'format %w(12,1,2)' ' git log -2 --format=%w(12,1,2)This is the %s commit. actual test_cmp expect actual ' So this sets a maximum width of 12 characters. Is that 12 character limit supposed to include the final newline, or not? Because the test above and my series are only correct if the final newline is included, i. e., at most eleven visible characters. If this should mean at most 12 visible characters instead, then the output should look like this: This is the sixth commit. This is the fifth commit. (In that case, I would repost an updated version of this series.) Regards Jan Jan H. Schönherr (5): format-patch: do not wrap non-rfc2047 headers too early format-patch: do not wrap rfc2047 encoded headers too late format-patch: introduce helper function last_line_length() format-patch: fix rfc2047 address encoding with respect to rfc822 specials format-patch: tests: check rfc822+rfc2047 in to+cc headers pretty.c| 121 ++ t/t4014-format-patch.sh | 227 ++-- 2 Dateien geändert, 229 Zeilen hinzugefügt(+), 119 Zeilen entfernt(-) -- 1.7.12 -- 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] t/t5400-send-pack: Use POSIX options to cp for portability
Junio C Hamano gits...@pobox.com 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 GNUism
These tests just wants a bit-for-bit identical copy; they do not
need -H (there is no symbolic link involved) nor -p (there is no
funny permission or ownership issues involved). Just use cp -R
instead.
---
t/t5400-send-pack.sh | 2 +-
t/t5550-http-fetch.sh | 2 +-
t/t5800-remote-helpers.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 250c720..418f515 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -159,7 +159,7 @@ test_expect_success 'receive-pack runs auto-gc in remote
repo' '
git commit -a -m Second commit
git repack
)
- cp -a parent child
+ cp -R parent child
(
# Set the child to auto-pack if more than one pack exists
cd child
diff --git a/t/t5550-http-fetch.sh b/t/t5550-http-fetch.sh
index 16ef041..80d20c8 100755
--- a/t/t5550-http-fetch.sh
+++ b/t/t5550-http-fetch.sh
@@ -22,7 +22,7 @@ test_expect_success 'setup repository' '
'
test_expect_success 'create http-accessible bare repository with loose
objects' '
- cp -a .git $HTTPD_DOCUMENT_ROOT_PATH/repo.git
+ cp -R .git $HTTPD_DOCUMENT_ROOT_PATH/repo.git
(cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git
git config core.bare true
mkdir -p hooks
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index 5702334..e7dc668 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -76,7 +76,7 @@ test_expect_success 'pushing to local repo' '
# git-remote-testgit, but is too slow to leave in for general use.
: test_expect_success 'racily pushing to local repo' '
test_when_finished rm -rf server2 localclone2
- cp -a server server2
+ cp -R server server2
git clone testgit::${PWD}/server2 localclone2
(cd localclone2
echo content file
--
1.8.0.rc0.95.g9b3a052
--
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/5] format-patch: do not wrap non-rfc2047 headers too early
From: Jan H. Schönherr schn...@cs.tu-berlin.de
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 schn...@cs.tu-berlin.de
---
pretty.c| 2 +-
t/t4014-format-patch.sh | 60 -
2 Dateien geändert, 35 Zeilen hinzugefügt(+), 27 Zeilen entfernt(-)
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..f5caecb 100644
--- a/pretty.c
+++ b/pretty.c
@@ -286,7 +286,7 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
if ((i + 1 len) (ch == '=' line[i+1] == '?'))
goto needquote;
}
- strbuf_add_wrapped_bytes(sb, line, len, 0, 1, max_length - line_len);
+ strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, max_length+1);
return;
needquote:
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 959aa26..d66e358 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -752,16 +752,14 @@ M64=$M8$M8$M8$M8$M8$M8$M8$M8
M512=$M64$M64$M64$M64$M64$M64$M64$M64
cat expect 'EOF'
Subject: [PATCH] foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
- bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
- foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
- bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
- foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
- bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
- foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
- bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
- foo bar foo bar foo bar foo bar
+ bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
+ foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
+ bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
+ foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo
+ bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
+ foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar
EOF
-test_expect_success 'format-patch wraps extremely long headers (ascii)' '
+test_expect_success 'format-patch wraps extremely long subject (ascii)' '
echo content file
git add file
git commit -m $M512
@@ -807,28 +805,12 @@ test_expect_success 'format-patch wraps extremely long
headers (rfc2047)' '
test_cmp expect subject
'
-M8=foo_bar_
-M64=$M8$M8$M8$M8$M8$M8$M8$M8
-cat expect EOF
-From: $M64
- foo...@foo.bar
-EOF
-test_expect_success 'format-patch wraps non-quotable headers' '
- rm -rf patches/
- echo content file
- git add file
- git commit -mfoo --author $M64 foo...@foo.bar
- git format-patch --stdout -1 patch
- sed -n /^From: /p; /^ /p; /^$/q patch from
- test_cmp expect from
-'
-
check_author() {
echo content file
git add file
GIT_AUTHOR_NAME=$1 git commit -m author-check
git format-patch --stdout -1 patch
- grep ^From: patch actual
+ sed -n /^From: /p; /^ /p; /^$/q patch actual
test_cmp expect actual
}
@@ -853,6 +835,32 @@ test_expect_success 'rfc2047-encoded headers also
double-quote 822 specials' '
check_author Föo B. Bar
'
+cat expect EOF
+From: foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_
+ aut...@example.com
+EOF
+test_expect_success 'format-patch wraps moderately long from-header (ascii)' '
+ check_author
foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_foo_bar_
+'
+
+cat expect 'EOF'
+From: Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
+ Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo
+ Bar Foo Bar Foo Bar Foo Bar aut...@example.com
+EOF
+test_expect_success 'format-patch wraps extremely long from-header (ascii)' '
+ check_author Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
+'
+
+cat expect 'EOF'
+From: Foo.Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
+ Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo
+ Bar Foo Bar Foo Bar Foo Bar aut...@example.com
+EOF
+test_expect_success 'format-patch wraps extremely long from-header (rfc822)' '
+ check_author Foo.Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
Foo Bar Foo Bar Foo Bar Foo Bar Foo Bar
+'
+
cat expect 'EOF'
Subject: header with . in it
EOF
--
1.7.12
--
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 3/5] format-patch: introduce helper function last_line_length()
From: Jan H. Schönherr schn...@cs.tu-berlin.de
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 schn...@cs.tu-berlin.de
---
pretty.c | 25 +
1 Datei geändert, 13 Zeilen hinzugefügt(+), 12 Zeilen entfernt(-)
diff --git a/pretty.c b/pretty.c
index daf8581..ee76219 100644
--- a/pretty.c
+++ b/pretty.c
@@ -240,6 +240,17 @@ static int has_rfc822_specials(const char *s, int len)
return 0;
}
+static int last_line_length(struct strbuf *sb)
+{
+ int i;
+
+ /* How many bytes are already used on the last line? */
+ for (i = sb-len - 1; i = 0; i--)
+ if (sb-buf[i] == '\n')
+ break;
+ return sb-len - (i + 1);
+}
+
static void add_rfc822_quoted(struct strbuf *out, const char *s, int len)
{
int i;
@@ -280,13 +291,7 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
{
static const int max_length = 76; /* per rfc2047 */
int i;
- int line_len;
-
- /* How many bytes are already used on the current line? */
- for (i = sb-len - 1; i = 0; i--)
- if (sb-buf[i] == '\n')
- break;
- line_len = sb-len - (i+1);
+ int line_len = last_line_length(sb);
for (i = 0; i len; i++) {
int ch = line[i];
@@ -344,7 +349,6 @@ void pp_user_info(const struct pretty_print_context *pp,
if (pp-fmt == CMIT_FMT_EMAIL) {
char *name_tail = strchr(line, '');
int display_name_length;
- int final_line;
if (!name_tail)
return;
while (line name_tail isspace(name_tail[-1]))
@@ -359,10 +363,7 @@ void pp_user_info(const struct pretty_print_context *pp,
add_rfc2047(sb, quoted.buf, quoted.len, encoding);
strbuf_release(quoted);
}
- for (final_line = 0; final_line sb-len; final_line++)
- if (sb-buf[sb-len - final_line - 1] == '\n')
- break;
- if (namelen - display_name_length + final_line 78) {
+ if (namelen - display_name_length + last_line_length(sb) 78) {
strbuf_addch(sb, '\n');
if (!isspace(name_tail[0]))
strbuf_addch(sb, ' ');
--
1.7.12
--
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 2/5] format-patch: do not wrap rfc2047 encoded headers too late
From: Jan H. Schönherr schn...@cs.tu-berlin.de
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 encoded word.
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
pretty.c| 24 +++-
t/t4014-format-patch.sh | 58 +
2 Dateien geändert, 49 Zeilen hinzugefügt(+), 33 Zeilen entfernt(-)
diff --git a/pretty.c b/pretty.c
index f5caecb..daf8581 100644
--- a/pretty.c
+++ b/pretty.c
@@ -263,13 +263,22 @@ static void add_rfc822_quoted(struct strbuf *out, const
char *s, int len)
static int is_rfc2047_special(char ch)
{
+ /*
+* We encode ' ' using '=20' even though rfc2047
+* allows using '_' for readability. Unfortunately,
+* many programs do not understand this and just
+* leave the underscore in place.
+*/
+ if (ch == ' ' || ch == '\n')
+ return 1;
+
return (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_'));
}
static void add_rfc2047(struct strbuf *sb, const char *line, int len,
const char *encoding)
{
- static const int max_length = 78; /* per rfc2822 */
+ static const int max_length = 76; /* per rfc2047 */
int i;
int line_len;
@@ -286,7 +295,7 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
if ((i + 1 len) (ch == '=' line[i+1] == '?'))
goto needquote;
}
- strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, max_length+1);
+ strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, 78+1);
return;
needquote:
@@ -295,19 +304,14 @@ needquote:
line_len += strlen(encoding) + 5; /* 5 for =??q? */
for (i = 0; i len; i++) {
unsigned ch = line[i] 0xFF;
+ int is_special = is_rfc2047_special(ch);
- if (line_len = max_length - 2) {
+ if (line_len + 2 + (is_special ? 3 : 1) max_length) {
strbuf_addf(sb, ?=\n =?%s?q?, encoding);
line_len = strlen(encoding) + 5 + 1; /* =??q? plus SP */
}
- /*
-* We encode ' ' using '=20' even though rfc2047
-* allows using '_' for readability. Unfortunately,
-* many programs do not understand this and just
-* leave the underscore in place.
-*/
- if (is_rfc2047_special(ch) || ch == ' ' || ch == '\n') {
+ if (is_special) {
strbuf_addf(sb, =%02X, ch);
line_len += 3;
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index d66e358..1d5636d 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -772,30 +772,31 @@ M8=föö bar
M64=$M8$M8$M8$M8$M8$M8$M8$M8
M512=$M64$M64$M64$M64$M64$M64$M64$M64
cat expect 'EOF'
-Subject: [PATCH]
=?UTF-8?q?f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
+Subject: [PATCH]
Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Simon Oosthoek s.oosth...@xs4all.nl 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 not think it matters what _you_
think when judging it is worth including in the future releases ;-)
A lot more important thing to say is why it has advantages for using
color (remember, it took a few rounds of back and forth with me).
Unless you are going to explain the same to all the people who are
reading the git log output 6 months down the road, that is a more
appropriate thing to write here.
contrib/completion/git-prompt.sh | 51
+-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 29b1ec9..c50c94a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
#1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
#2) Add the following line to your .bashrc/.zshrc:
#source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
-# ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND=__git_ps1 '\u@\h:\w (' ')\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
+#ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#the optional argument will be used as format string
#
# The argument to __git_ps1 will be displayed only if you are currently
# in a git repository. The %s token will be the name of the current
@@ -194,11 +199,41 @@ __git_ps1_show_upstream ()
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
+# when called from PS1 using command substitution
+# in this mode it returns text to add to bash PS1 prompt (includes branch
name) or
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second
appended
+# to the state string when assigned to PS1, otherwise default start/end
strings
+# are used.
Sorry, but I cannot parse this. Is this meant to be a two-item list,
one describing the command substitution mode (zero or 1 arguments) and
the other describing the prompt command mode? If so, perhaps replacing
the or at the end of the first item with .\n#\n would make it readable.
__git_ps1 ()
{
+ local pcmode=yes
+ local ps1pc_start='\u@\h:\w '
+ local ps1pc_end='\$ '
+
+ case $PROMPT_COMMAND in
+ __git_ps1*)
+ if [ $# = 2 ]; then
+ ps1pc_start=$1
+ ps1pc_end=$2
+ fi
+ case $PS1 in
+ *__git_ps1*)
+ echo '__git_ps1: overwriting PS1 due to
PROMPT_COMMAND'
Is this supposed to be an error and/or warning message? Why is it
worth warning only when you are overwriting __git_ps1 style of PS1
and not other user customization?
+ ;;
+ esac
+ ;;
+ *) pcmode=no ;; #no output
+ esac
Please align outer case its arms) and esac at the same column,
like you did for the inner case/esac.
Auto-detetction based on PROMPT_COMMAND is a flaky approach. In
practice, nobody will call PROMPT_COMMAND with the __git_ps1 without
any parameter (100% people want their prompt to end with some sort
of whitespace so they want the what comes after what is computed,
aka $2), and even more importantly, nobody has been relying on use
of 0 argument form of __git_ps1 in PROMPT_COMMAND. So why not
always require 2 args and take that as a cue to go into the pc mode?
+
local g=$(__gitdir)
- if [ -n $g ]; then
+ if [ -z $g ]; then
+ if [ $pcmode = yes ]; then
+ #In PC mode PS1 always needs to be set
+ PS1=$ps1pc_start$ps1pc_end
+ fi
+ else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +319,10 @@ __git_ps1 ()
fi
local f=$w$i$s$u
- printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+ if [ $pcmode = yes ]; then
+ PS1=$ps1pc_start($c${b##refs/heads/}${f:+
$f}$r$p)$ps1pc_end
+ elif [ $pcmode = no ]; then
+ printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+
$f}$r$p
+
Re: Proposed function path_in_directory()
Am 08.10.2012 18:13, schrieb Junio C Hamano: Michael Haggerty mhag...@alum.mit.edu 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 prefix C: (or D: or X:) ourselves if we really want to tell C:\bin and D:\bin apart? We don't have to do that. getcwd() returns the drive letter. Assuming that is the case, the ceiling computation would need a helper function that hides the gory details of prefixing getcwd() result with drive letter or whatever needed, and another that normalizes the elements of the environment variables (I presume that if an element in it without the drive prefix should be normalized to add the current drive letter to it so that the normalized getcwd() result can be compared with it). E.g. if the ceiling list is D:/a/b;/trash/ then getcwd() returning /a alone does not make it outside the ceiling due to D:/a/b---our current drive must be D for that pattern to kick in. The unqualified /trash would apply to any drive. A component in an path list like GIT_CEILING_DIRECTORIES or PATH that does not contain the drive letter is a user error. Do not cater for it. It is more important to take into account that those components can contain backslash as directory separators, while our mingw_getcwd() returns forward slashes. -- Hannes -- 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: Proposed function path_in_directory()
Johannes Sixt j...@kdbg.org writes: Am 08.10.2012 18:13, schrieb Junio C Hamano: Michael Haggerty mhag...@alum.mit.edu 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 prefix C: (or D: or X:) ourselves if we really want to tell C:\bin and D:\bin apart? We don't have to do that. getcwd() returns the drive letter. ... A component in an path list like GIT_CEILING_DIRECTORIES or PATH that does not contain the drive letter is a user error. Do not cater for it. That makes it much simpler and saner. 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
Git ~unusable on slow lines :,'C
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 down very well, so for ten more days I will be unable to get the newest commits onto my machine. Which is very, very sad :/ git fetch --verbose --all Fetching origin POST git-upload-pack (1023 bytes) POST git-upload-pack (gzip 1123 to 614 bytes) POST git-upload-pack (gzip 1973 to 1030 bytes) POST git-upload-pack (gzip 5173 to 2639 bytes) POST git-upload-pack (gzip 7978 to 4042 bytes) remote: Counting objects: 24504, done. remote: Compressing objects: 100% (10705/10705), done. error: RPC failed; result=56, HTTP code = 200iB | 10 KiB/s fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed error: Could not fetch origin Bam, the server kicked me off after taking to long to sync my copy. Multiple potential points of action: - git fetch should show the total amount of data it is about to transfer! - when ab^H^Horting, the cursor should be moved down (tput cud1) to not overwrite previous output - would be nice to be able to tell git fetch to get the next chunk of say 500 commits instead of trying to receive ALL commits, then b0rking after umpteen percent on server timeout. Not? #Regards!Marcel c: -- 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: In search of a version control system
Ramkumar Ramachandra artag...@gmail.com 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), then file locking is indeed not such a bad idea. -- 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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
Angelo Borsotti angelo.borso...@gmail.com writes: git fetch repository refspec 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 command line which is a short-hand for refs/heads/master. When you run $ git fetch origin configured refspec is looked up from your config (because you didn't give any from the command line). The default refspec in your config is likely to be refs/heads/*:refs/remotes/origin/*. The former, refs/heads/master refspec, tells Git not to update the remote tracking branch. The latter has colon and right-hand-side of the colon tells Git what to update with what was fetched. It would hlep to read up on refspec by running git fetch --help and looking for a string colon. -- 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: git fetch documentation problem or bug
Junio C Hamano gits...@pobox.com writes: Angelo Borsotti angelo.borso...@gmail.com writes: git fetch repository refspec 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 command line which is a short-hand for refs/heads/master. When you run $ git fetch origin configured refspec is looked up from your config (because you didn't give any from the command line). The default refspec in your config is likely to be refs/heads/*:refs/remotes/origin/*. The former, refs/heads/master refspec, tells Git not to update the remote tracking branch. The latter has colon and right-hand-side of the colon tells Git what to update with what was fetched. It would hlep to read up on refspec by running git fetch --help and looking for a string colon. Addendum. Your claim git fetch repository refspec does not create the remote refs in the current (local) repository... is incorrect. The behaviour depends on what refspec you give. 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 -- 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
[RFC] rebase: Handle cases where format-patch fails
'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 'am' by using an intermediate file. This gurantees that we can invoke 'am' with the complete input, or not invoking 'am' at all if 'format-patch' failed. Also print messages to help user with how to recover from such failures. Signed-off-by: Andrew Wong andrew.k...@gmail.com --- git-rebase--am.sh | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index 392ebc9..a955b38 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -26,10 +26,32 @@ then # makes this easy git cherry-pick --allow-empty $revisions else - git format-patch -k --stdout --full-index --ignore-if-in-upstream \ + rm -f $GIT_DIR/format-patch + if ! git format-patch -k --stdout --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ - --no-renames $root_flag $revisions | - git am $git_am_opt --rebasing --resolvemsg=$resolvemsg + --no-renames $root_flag $revisions $GIT_DIR/format-patch ret=$? + then + rm $GIT_DIR/format-patch + echo + echo 'git format-patch' seems to have failed. + echo It is impossible to continue or abort rebasing. + echo You have to use the following to return to your original head: + echo + case $head_name in + refs/*) + echo git checkout $head_name + ;; + *) + echo git checkout $orig_head + ;; + esac + echo + exit $ret + fi + + git am $git_am_opt --rebasing --resolvemsg=$resolvemsg $GIT_DIR/format-patch || ret=$? + rm -f $GIT_DIR/format-patch + test 0 != ret ( exit $ret ) fi move_to_original_branch ret=$? -- 1.8.0.rc0.19.ga19ab82.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Hi Junio
thanks for your feedback!
On 08/10/12 20:12, Junio C Hamano wrote:
Simon Oosthoek s.oosth...@xs4all.nl 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 not think it matters what _you_
think when judging it is worth including in the future releases ;-)
Hmm, right :-P
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...
Isn't it confusing that the color codes don't figure in this patch at all?
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
+# when called from PS1 using command substitution
+# in this mode it returns text to add to bash PS1 prompt (includes branch
name) or
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second
appended
+# to the state string when assigned to PS1, otherwise default start/end
strings
+# are used.
Sorry, but I cannot parse this. Is this meant to be a two-item list,
one describing the command substitution mode (zero or 1 arguments) and
the other describing the prompt command mode? If so, perhaps replacing
the or at the end of the first item with .\n#\n would make it readable.
I agree, that would make it more readable.
__git_ps1 ()
{
+local pcmode=yes
+local ps1pc_start='\u@\h:\w '
+local ps1pc_end='\$ '
+
+case $PROMPT_COMMAND in
+__git_ps1*)
+if [ $# = 2 ]; then
+ps1pc_start=$1
+ps1pc_end=$2
+fi
+case $PS1 in
+*__git_ps1*)
+echo '__git_ps1: overwriting PS1 due to
PROMPT_COMMAND'
Is this supposed to be an error and/or warning message? Why is it
worth warning only when you are overwriting __git_ps1 style of PS1
and not other user customization?
That's what this is doing, I wasn't able to make it the other way
around. I thought that I could detect when PS1 contained __git_ps1 that
it shouldn't overwrite the PS1, which worked, but when PROMPT_COMMAND
was set with __git_ps1 and PS1=$(__git_ps1) as well, it gave double output.
As PROMPT_COMMAND is relatively obscure I thought a warning when
overwriting the PS1 was good, but not unless there was a real conflict
(double call to __git_ps1).
The warning is only shown once.
I don't think it would be possible to detect any other kind of
customization without including specific code for it. Do you think it's
unnecessary to include a warning? (I think it would take people a long
time to figure out why their prompt goes whoopsy without getting a hint
that PROMPT_COMMAND messes up the PS1)
(OTOH, if you configure PROMPT_COMMAND, you're bound to know a little
bit about what you're doing...)
Perhaps it's better to just do it.
+;;
+esac
+;;
+*) pcmode=no ;; #no output
+esac
Please align outer case its arms) and esac at the same column,
like you did for the inner case/esac.
ok
Auto-detetction based on PROMPT_COMMAND is a flaky approach. In
practice, nobody will call PROMPT_COMMAND with the __git_ps1 without
any parameter (100% people want their prompt to end with some sort
of whitespace so they want the what comes after what is computed,
aka $2), and even more importantly, nobody has been relying on use
of 0 argument form of __git_ps1 in PROMPT_COMMAND. So why not
always require 2 args and take that as a cue to go into the pc mode?
That's a good idea, I'll change that.
+if [ $pcmode = yes ]; then
+PS1=$ps1pc_start($c${b##refs/heads/}${f:+
$f}$r$p)$ps1pc_end
+elif [ $pcmode = no ]; then
+printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+
$f}$r$p
+fi
Are there $pcmode other than yes or no? Why not just else,
instead of performing the test twice?
I forgot to remove that one, I had a default at some point ;-)
Cheers
Simon.
--
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] t/t5400-send-pack: Use POSIX options to cp for portability
On Mon, Oct 8, 2012 at 6:45 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com 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? This works. I was responding to a failing test so I didn't look for other instances. Clearly I should have...I must not be exercising those other tests. Acked-By: Ben Walton bdwal...@gmail.com Thanks -Ben -- --- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --- -- 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
[ANNOUNCE] Git v1.8.0-rc1
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 47be50c68d9fcd1c83bfea01c18a6e3f2abd37b8 git-htmldocs-1.8.0.rc1.tar.gz 7854c309bd9befcb0cd737eb6c17085084a458fd git-manpages-1.8.0.rc1.tar.gz Also the following public repositories all have a copy of the v1.8.0-rc1 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.0 Release Notes (draft) Backward compatibility notes In the next major release (*not* in 1.8.0 but the one that comes after that), we will change the behavior of the git push command. When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will now use the simple semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this, and git push will warn about the upcoming change until you set this variable. git branch --set-upstream is deprecated and may be removed in a relatively distant future. git branch [-u|--set-upstream-to] has been introduced with a saner order of arguments. Updates since v1.7.12 - UI, Workflows Features * A credential helper for Win32 to allow access to the keychain of the logged-in user has been added. * An initial port to HP NonStop. * A credential helper to allow access to the Gnome keyring has been added. * When git am sanitizes the Subject: line, we strip the prefix from Re: subject and also from a less common re: subject, but left the even less common RE: subject intact. We strip that now, too. * It was tempting to say git branch --set-upstream origin/master, but that tells Git to arrange the local branch origin/master to integrate with the currently checked out branch, which is highly unlikely what the user meant. The option is deprecated; use the new --set-upstream-to (with a short-and-sweet -u) option instead. * git cherry-pick learned the --allow-empty-message option to allow it to replay a commit without any log message. * After git cherry-pick -s gave control back to the user asking help to resolve conflicts, concluding git commit used to need to be run with -s if the user wants to sign it off; now the command leaves the sign-off line in the log template. * git daemon learned the --access-hook option to allow an external command to decline service based on the client address, repository path, etc. * git difftool --dir-diff learned to use symbolic links to prepare a temporary copy of the working tree when available. * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. * git log -g learned the --grep-reflog=pattern option to limit its output to commits with a reflog message that matches the given pattern. * git merge-base learned the --is-ancestor A B option to tell if A is an ancestor of B. The result is indicated by its exit status code. * git mergetool now allows users to override the actual command used with the mergetool.$name.cmd configuration variable even for built-in mergetool backends. * The -Xours backend option to git merge -s recursive now takes effect even on binary files. * git rebase -i learned the --edit-todo option to open an editor to edit the instruction sheet. Foreign Interface * git svn has been updated to work with SVN 1.7. * git p4 learned the --conflicts option to specify what to do when encountering a conflict during p4 submit. Performance, Internal Implementation, etc. (please report possible regressions) * Git ships with a fall-back regexp implementation for platforms with buggy regexp library, but it was easy for people to keep using their platform regexp by mistake. A new test has been added to check this. * The check-docs build target has been updated and greatly simplified. * The test suite is run under MALLOC_CHECK_ when running with a glibc that supports the feature. * The documentation in the TeXinfo format was using indented output for materials meant to be examples that are better typeset in monospace. * Compatibility wrapper around some mkdir(2) implementations that reject parameters with trailing slash has been introduced. * Compatibility wrapper for
A note from the maintainer
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 and patches should be sent to
the list address git@vger.kernel.org. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say Please Cc: me,
I am not subscribed.
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to jump to the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just git does not work. I used git in this
way, but it did not work is not much better, neither is I used git
in this way, and X happend, which is broken. It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: master, maint, next, and pu.
The master branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a feature
release is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the master branch is always
more stable than any of the released versions.
Whenever a feature release is made, maint branch is forked off from
master at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.3. New features never go to this branch. This branch is also
merged into master to propagate the fixes forward.
A new development does not usually happen on master. When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of master and your
Re: Fw: [git-users] How do I git-push to an FTP server?
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. For what it's worth, Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] Re: gitk: can't reload commits with new key binding
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 bindshiftfunctionkey to bind Shift-F5 Thanks, this series solves the problem for me. Best, Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Simon Oosthoek s.oosth...@xs4all.nl 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... Isn't it confusing that the color codes don't figure in this patch at all? Since the Subject: is allow ... to be used in PROMPT_COMMAND, it very much is relevant to mention that we need to use PROMPT_COMMAND in order to correctly use \[ and \] to generated zero-width escape sequences, which cannot be done by simply setting PS1 to command substitution. color is just an example; if it makes you uneasy to say color, you can say zero-width escape sequences. It could be \007 (BEL) ;-) I don't think it would be possible to detect any other kind of customization without including specific code for it. Do you think it's unnecessary to include a warning? (I think it would take people a long time to figure out why their prompt goes whoopsy without getting a hint that PROMPT_COMMAND messes up the PS1) I think you need your warning _only_ because you attempt to auto-detect it, when you do not have to. (OTOH, if you configure PROMPT_COMMAND, you're bound to know a little bit about what you're doing...) Yup. -- 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] t/t5400-send-pack: Use POSIX options to cp for portability
Ben Walton bdwal...@gmail.com writes: On Mon, Oct 8, 2012 at 6:45 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com 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? This works. I was responding to a failing test so I didn't look for other instances. Clearly I should have...I must not be exercising those other tests. Acked-By: Ben Walton bdwal...@gmail.com I actually was planning to pass the blame to you so I'll re-queue it under your Author: name, with S-o-b. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: build deps
On Mon, Oct 8, 2012 at 6:36 PM, Thiago Farina tfrans...@gmail.com wrote: On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong andrew.k...@gmail.com 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-store] Error 1 Did you run the configure script? Hum, I haven't. Now I did. In the source folder, do you have either file config.mak or config.mak.autogen ? After running ./configure, now I have. If you do, try removing them, and compile again. Which version are you compiling? $ cat GIT-VERSION-FILE GIT_VERSION = 1.7.12.84.gefa6462 Did you get the source files from tar? Or from git? From git (git://git.kernel.org/pub/scm/git/git.git). 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 $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix Also: $ echo $CC clang -B/usr/local/gold/bin -- 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: Fw: [git-users] How do I git-push to an FTP server?
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
Bug/Enhancement: contrib/subtree should ship with manpage
(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 contrib/subtree. What is the expected output? What do you see instead? Expected: git-subtree goes into $PREFIX/libexec/, and git-subtree.1 goes into $PREFIX/share/man/man1/. Actual: git-subtree.1 fails to be generated because my system doesn't ship asciidoc and xmlto. What version of the product are you using? On what operating system? v1.7.12.2 and v1.8.0.rc0.18.gf84667d, on OS X 10.8.2. Please provide any additional information below. Prototype patch attached. subtree_manpage.patch Description: Binary data
Re: [RFC] rebase: Handle cases where format-patch fails
Andrew Wong andrew.k...@gmail.com 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 pipe, we separate 'format-patch' and 'am' by using an
intermediate file. This gurantees that we can invoke 'am' with the
complete input, or not invoking 'am' at all if 'format-patch' failed.
Also print messages to help user with how to recover from such failures.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--am.sh | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 392ebc9..a955b38 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -26,10 +26,32 @@ then
# makes this easy
git cherry-pick --allow-empty $revisions
else
- git format-patch -k --stdout --full-index --ignore-if-in-upstream \
+ rm -f $GIT_DIR/format-patch
+ if ! git format-patch -k --stdout --full-index --ignore-if-in-upstream \
--src-prefix=a/ --dst-prefix=b/ \
- --no-renames $root_flag $revisions |
- git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
+ --no-renames $root_flag $revisions $GIT_DIR/format-patch
ret=$?
+ then
Is it just me? I find this construct
if ! cmd ret=$?
then
very hard to wrap my mind around. Why not
git format-patch ... just as before ... \
... $GIT_DIR/formatted-patches || {
# error handling or advices come here...
rm -f $GIT_DIR/formatted-patches
exit 1
}
git am ... just as before ... $GIT_DIR/formatted-patches || {
# possibly another error handling or advices come here...
rm -f $GIT_DIR/formatted-patches
exit 1
}
without changing anything else?
+ rm $GIT_DIR/format-patch
+ echo
+ echo 'git format-patch' seems to have failed.
+ echo It is impossible to continue or abort rebasing.
+ echo You have to use the following to return to your original
head:
+ echo
+ case $head_name in
+ refs/*)
+ echo git checkout $head_name
+ ;;
+ *)
+ echo git checkout $orig_head
+ ;;
+ esac
You _know_ format-patch failed, not just seems to have, at this
point, no? Why is it impossible to abort?
What have we done before reaching to this point? We know we are
doing the basic git rebase, without any funny -m/-i/-p business,
so the only thing we have done are (1) detached HEAD at the new
onto, (2) set ORIG_HEAD to point at the original tip of the branch
being rebased (or the commit we were sitting at, if we are rebasing
a detached history), and (3) head_name has the refname of the
original branch (or detached HEAD) and branch_name has the name of
the branch (or HEAD).
Shouldn't we be just rewinding what we have done so far and error
the whole thing out instead? Perhaps the first # error handling or
advises come here... part may simply be
case $head_name in
refs/heads/*)
git checkout $head_name
;;
*)
git checkout $orig_head
;;
esac
cat 2 -\EOF
Error was found while preparing the patches ($revisions) to
replay on the rewound head. You cannot rebase this history.
EOF
or something like that. The format-patch output (and its error) may
be of interest in getting help going forward.
--
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: build deps
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 $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix Looks like something went wrong with make setting PATH. I wonder if the + sign in your path is somehow messing things up. Are you trying to compile specifically with clang? If not, maybe try unsetting the CC env var, and run configure again? -- 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: Re: [Patch 0/5] Create single PDF for all HTML files
From: Thomas Ackermann th.acke...@arcor.de 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 slow. It takes more than 3 hrs to create git-doc.pdf. If you want to have a quick look on the resulting pdf just clone https://github.com/tacker66/git-docpdf.git. This repo contains a current version of user.manual.pdf and git-doc.pdf Even as a 'draft' I found it to be useful to see all the documentation collated together in one place/pdf. All 763 pages! Even just reading through the contents list (34 pages) showed the scale of the git documentation, and areas of documentation I wasn't aware of. Putting the Tutorials, Everyday GIT and workflows at the beginning looked good. For a polished version it would be good if the major breaks (e.g. between ToC, gittutorial, git-add [should start with git(1)], gitattributes, GIT Howto, API, Git Index Format, ReleaseNotes) could start on a new page. A few minor nits: I wasn't sure if the 'fighting regressions with git bisect', and 'a short git tools survey' were in the right place. There appear to be two 'git-send-pack' titles, though they are different. And the HowTo section would need some beefed up headings to give them enough prominence in the ToC once it all hangs together. - Original Nachricht Von: Jeff King p...@peff.net An: Thomas Ackermann th.acke...@arcor.de Datum: 06.10.2012 21:32 Betreff: Re: [Patch 0/5] Create single PDF for all HTML files On Sat, Oct 06, 2012 at 05:51:15PM +0200, Thomas Ackermann wrote: I wanted to have a single PDF file which contains the complete Git documentation (except user-manual) for easier reading on my tablet. The simplest way to do this was by using wkhtmltopdf which can combine a set of HTML files into a sinlge PDF file and also apply some reformatting. To this end HTML files for all the missing files in Documentation/technical and Documentation/howto and also for all the release notes in Documentation/RelNotes were created. It seems like a reasonable goal. I do not have a strong opinion on the approach or how the final output looks, but I wasn't able to actually get output at all after applying your patches. Running make fullpdf (after installing dblatex) got me: The switch --book, is not support using unpatched qt, and will be ignored.The switch --footer-html, is not support using unpatched qt, and will be ignored.The switch --disable-external-links, is not support using unpatched qt, and will be ignored. after which wkhtmltopdf began pegging my CPU. I let it run for 10 minutes before giving up. Another way of doing this would be to format the individual troff manpages into dvi or postscript, convert that into pdf, and then concatenate that. Something like: for i in *.[157]; do man -Tdvi -l $i $i.dvi dvipdfm $i done pdftk *.[157].pdf cat output full.pdf works for me, though obviously that does not handle some of the non-man items you included. No idea on how the output compares to yours, but it's something you may want to look at. -Peff --- Thomas -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2677 / Virus Database: 2591/5813 - Release Date: 10/06/12 -- 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: git fetch documentation problem or bug
Junio C Hamano gits...@pobox.com 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, start
coding after 1.8.0 final.
A good place to start may be $gmane/167149, where I listed (among
other things that turned out to be undesirable, which are omitted in
this copy):
* git branch --set-upstream name should not be about setting the
upstream of name to the current branch.
This has happened during 1.8.0 cycle [CMN].
* git push default semantics will be upstream (renamed from
tracking), not matching.
1.8.0 has the first step toward this [MM].
* git merge without what to merge default to @{upstream}
This is not acceptable for the default, but the users can ask for
it with merge.defaultToUpstream since 1.7.5 era [JC]
* Unify pathspec semantics
This has happened and commands that used to take only path prefix
style pathspecs now take globs as well [ND]
* git fetch $from $branch... to update tracking branches
This is the topic in this thread.
I personally do not think the downside of breaking backward
compatibility is too bad. If we do this only when we already are
configured to keep remote tracking branch for branch $branch from
remote $from (it has to be given as a nickname, not URL that happens
to have an entry in the configuration), then a promiscuous fetch
that grabs from a URL (or a nickname that is configured not to keep
tracking branches) will not change any behaviour, and when you want
to keep your remote tracking branch intact while doing one-shot
fetch for whatever reason, you can say git fetch $from $branch: to
explicitly decline copying.
--
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] submodule: teach foreach command a --revision tree-ish option
Teach git submodule foreach a --revision tree-ish 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.0
$ git submodule update
$ git submodule foreach 'git tag v1.0'
Signed-off-by: Jay Soffian jaysoff...@gmail.com
---
Documentation/git-submodule.txt | 7 ++-
git-submodule.sh| 27 ---
t/t7407-submodule-foreach.sh| 15 +++
3 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bba1b..6c889f5fd6 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -17,7 +17,8 @@ SYNOPSIS
[--reference repository] [--merge] [--recursive] [--]
[path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
-'git submodule' [--quiet] foreach [--recursive] command
+'git submodule' [--quiet] foreach [--recursive] [--revision tree-ish]
+ command
'git submodule' [--quiet] sync [--] [path...]
@@ -180,6 +181,10 @@ foreach::
of each submodule before evaluating the command.
If `--recursive` is given, submodules are traversed recursively (i.e.
the given shell command is evaluated in nested submodules as well).
+ If `--revision tree-ish` is given, submodules are traversed starting
+ at the given tree-ish. Though this does not alter the submodule check
+ outs, it may be combined with $sha1 to perform git commands that can
+ operate on a particular commit, such as linkgit:git-tag[1].
A non-zero return from the command in any submodule causes
the processing to terminate. This can be overridden by adding '|| :'
to the end of the command.
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b1107b6..5e7458e155 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -10,7 +10,7 @@ USAGE=[--quiet] add [-b branch] [-f|--force] [--reference
repository] [--] r
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference repository] [--merge] [--recursive] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n]
[commit] [--] [path...]
- or: $dashless [--quiet] foreach [--recursive] command
+ or: $dashless [--quiet] foreach [--recursive] [--revision tree-ish]
command
or: $dashless [--quiet] sync [--] [path...]
OPTIONS_SPEC=
. git-sh-setup
@@ -379,6 +379,7 @@ Use -f if you really want to add it. 2
cmd_foreach()
{
# parse $args after submodule ... foreach.
+ revision=
while test $# -ne 0
do
case $1 in
@@ -388,6 +389,11 @@ cmd_foreach()
--recursive)
recursive=1
;;
+ --revision)
+ git rev-parse --quiet --verify $2 /dev/null || usage
+ revision=$2
+ shift
+ ;;
-*)
usage
;;
@@ -404,7 +410,17 @@ cmd_foreach()
# command in the subshell (and a recursive call to this function)
exec 30
- module_list |
+ if test -n $revision
+ then
+ # make ls-tree output look like ls-files output
+ git ls-tree -r $revision | grep '^16 ' |
+ while read mode unused sha1 sm_path
+ do
+ echo $mode $sha1 0 $sm_path
+ done
+ else
+ module_list
+ fi |
while read mode sha1 stage sm_path
do
die_if_unmatched $mode
@@ -421,7 +437,12 @@ cmd_foreach()
eval $@
if test -n $recursive
then
- cmd_foreach --recursive $@
+ if test -n $revision
+ then
+ cmd_foreach --recursive
--revision $sha1 $@
+ else
+ cmd_foreach --recursive $@
+ fi
fi
) 3 3- ||
die $(eval_gettext Stopping at '\$sm_path'; script
returned non-zero status.)
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 9b69fe2e14..5c798b901b 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -179,6 +179,21 @@ test_expect_success 'test foreach --quiet --recursive' '
test_cmp expect
Re: Git ~unusable on slow lines :,'C
Marcel Partap mpar...@gmx.net 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. Unfortunately, git does not scale down very well, so for ten more days I will be unable to get the newest commits onto my machine. Which is very, very sad :/ git fetch --verbose --all Fetching origin POST git-upload-pack (1023 bytes) POST git-upload-pack (gzip 1123 to 614 bytes) POST git-upload-pack (gzip 1973 to 1030 bytes) POST git-upload-pack (gzip 5173 to 2639 bytes) POST git-upload-pack (gzip 7978 to 4042 bytes) remote: Counting objects: 24504, done. remote: Compressing objects: 100% (10705/10705), done. error: RPC failed; result=56, HTTP code = 200iB | 10 KiB/s fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed error: Could not fetch origin Bam, the server kicked me off after taking to long to sync my copy. This is unrelated to git. The HTTP server's configuration is too impatient. Multiple potential points of action: - git fetch should show the total amount of data it is about to transfer! It can't, because it doesn't know. - when ab^H^Horting, the cursor should be moved down (tput cud1) to not overwrite previous output The error message doesn't really know whether it is going to overwrite it (the CR comes from the server), though I suppose an extra LF wouldn't hurt there. - would be nice to be able to tell git fetch to get the next chunk of say 500 commits instead of trying to receive ALL commits, then b0rking after umpteen percent on server timeout. Not? You asked for the current state of the repository, and that's what its giving you. The timeout has nothing to do with git, if you can't convince the admins to increase it, you can try using another transport which doesn't suffer from HTTP, as it's most likely an anti-DoS measure. If you want to download it bit by bit, you can tell fetch to download particular tags. Doing this automatically for this would be working around a configuration issue for a particular server, which is generally better fixed in other ways. cmn -- 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: git fetch documentation problem or bug
On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano gits...@pobox.com 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. Still need to think about git-rm and git-mv as they also accept directories (i.e. not exactly pathspec by definition). -- Duy -- 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 nd/attr-match-optim-more 2/2] attr: more matching optimizations from .gitignore
.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 possible in favor of strncmp.
A few notes from this work is put in the documentation:
* !pattern syntax is not supported in .gitattributes. Negative
patterns may work well for a single attribute like .gitignore. It's
confusing in .gitattributes are many attributes can be
set/unset/undefined at using the same pattern.
* we support attaching attributes to directories at the syntax
level, but we do not really attach attributes on directory or use
them.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
No more die() for path/ syntax. Rephrase !syntax messages from not
supported to forbidden. A small test to verify that we actually
forbid it.
Documentation/gitattributes.txt | 3 +-
attr.c | 67 ++---
dir.c | 8 ++---
dir.h | 1 +
t/t0003-attributes.sh | 14 +
5 files changed, 77 insertions(+), 16 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 80120ea..cc2ff1d 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -23,7 +23,7 @@ Each line in `gitattributes` file is of form:
That is, a pattern followed by an attributes list,
separated by whitespaces. When the pattern matches the
path in question, the attributes listed on the line are given to
-the path.
+the path. Only files can be attached attributes to.
Each attribute can be in one of these states for a given path:
@@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Unlike `.gitignore`, negative patterns are forbidden.
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
diff --git a/attr.c b/attr.c
index e7caee4..7e85f82 100644
--- a/attr.c
+++ b/attr.c
@@ -115,6 +115,13 @@ struct attr_state {
const char *setto;
};
+struct pattern {
+ const char *pattern;
+ int patternlen;
+ int nowildcardlen;
+ int flags; /* EXC_FLAG_* */
+};
+
/*
* One rule, as from a .gitattributes file.
*
@@ -131,7 +138,7 @@ struct attr_state {
*/
struct match_attr {
union {
- char *pattern;
+ struct pattern pat;
struct git_attr *attr;
} u;
char is_macro;
@@ -241,9 +248,17 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
if (is_macro)
res-u.attr = git_attr_internal(name, namelen);
else {
- res-u.pattern = (char *)(res-state[num_attr]);
- memcpy(res-u.pattern, name, namelen);
- res-u.pattern[namelen] = 0;
+ char *p = (char *)(res-state[num_attr]);
+ memcpy(p, name, namelen);
+ p[namelen] = 0;
+ res-u.pat.pattern = p;
+ parse_exclude_pattern(res-u.pat.pattern,
+ res-u.pat.patternlen,
+ res-u.pat.flags,
+ res-u.pat.nowildcardlen);
+ if (res-u.pat.flags EXC_FLAG_NEGATIVE)
+ die(_(Negative patterns are forbidden in git
attributes\n
+ Use '\\!' for literal leading exclamation.));
}
res-is_macro = is_macro;
res-num_attr = num_attr;
@@ -640,25 +655,55 @@ static void prepare_attr_stack(const char *path)
static int path_matches(const char *pathname, int pathlen,
const char *basename,
- const char *pattern,
+ const struct pattern *pat,
const char *base, int baselen)
{
- if (!strchr(pattern, '/')) {
+ const char *pattern = pat-pattern;
+ int prefix = pat-nowildcardlen;
+ const char *name;
+ int namelen;
+
+ if (pat-flags EXC_FLAG_NODIR) {
+ if (prefix == pat-patternlen
+ !strcmp_icase(pattern, basename))
+ return 1;
+
+ if (pat-flags EXC_FLAG_ENDSWITH
+ pat-patternlen - 1 = pathlen
+ !strcmp_icase(pattern + 1, pathname +
+ pathlen - pat-patternlen + 1))
+ return 1;
+
return (fnmatch_icase(pattern, basename, 0) == 0);
}
/*
* match with FNM_PATHNAME; the pattern has base
[PATCH 0/8] wildmatch take 3
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 slash means match in all directories. For example, `**/foo` matches file or directory `foo` anywhere, the same as pattern `foo`. **/foo/bar matches file or directory `bar` anywhere that is directly under directory `foo`. - A trailing /** matches everything inside. For example, abc/** is equivalent to `/abc/`. - A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, `a/**/b` matches `a/b`, `a/x/b`, `a/x/y/b` and so on. - Consecutive asterisks otherwise are treated like normal asterisk wildcards. abc/** and abc/* are different in attr (the former matches all files, the latter only files directly under abc) while they are the same for ignore. I don't like these subtleties but I don't think we have a choice unless we rework attr matching machinery. Tests t3070.100 and .101 fail on some machine and not on other due to (I guess) fnmatch behavior changes. Maybe we should fallback on compat/fnmatch in such cases for consistent behavior. There are problems with asciidoc and `**/` but that's not something we need to care now. On top of master (and a small conflict with nd/attr-match-optim-more) Nguyễn Thái Ngọc Duy (8): Import wildmatch from rsync wildmatch: remove unnecessary functions Integrate wildmatch to git wildmatch: remove static variable force_lower_case wildmatch: fix case-insensitive matching wildmatch: adjust ** behavior wildmatch: make /**/ match zero or more directories Support ** wildcard in .gitignore and .gitattributes .gitignore | 1 + Documentation/gitignore.txt| 19 +++ Makefile | 3 + attr.c | 4 +- dir.c | 4 +- t/t0003-attributes.sh | 38 ++ t/t3001-ls-files-others-exclude.sh | 19 +++ t/t3070-wildmatch.sh | 184 test-wildmatch.c | 14 +++ wildmatch.c| 245 + wildmatch.h| 3 + 11 files changed, 532 insertions(+), 2 deletions(-) create mode 100755 t/t3070-wildmatch.sh create mode 100644 test-wildmatch.c create mode 100644 wildmatch.c create mode 100644 wildmatch.h -- 1.8.0.rc0.29.g1fdd78f -- 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/8] Import wildmatch from rsync
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.txtt/t3070/wildtest.txt Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- t/t3070/wildtest.txt | 165 +++ wildmatch.c | 368 +++ wildmatch.h | 6 + 3 files changed, 539 insertions(+) create mode 100644 t/t3070/wildtest.txt create mode 100644 wildmatch.c create mode 100644 wildmatch.h diff --git a/t/t3070/wildtest.txt b/t/t3070/wildtest.txt new file mode 100644 index 000..42c1678 --- /dev/null +++ b/t/t3070/wildtest.txt @@ -0,0 +1,165 @@ +# Input is in the following format (all items white-space separated): +# +# The first two items are 1 or 0 indicating if the wildmat call is expected to +# succeed and if fnmatch works the same way as wildmat, respectively. After +# that is a text string for the match, and a pattern string. Strings can be +# quoted (if desired) in either double or single quotes, as well as backticks. +# +# MATCH FNMATCH_SAME text to match 'pattern to use' + +# Basic wildmat features +1 1 foofoo +0 1 foobar +1 1 '' +1 1 foo??? +0 1 foo?? +1 1 foo* +1 1 foof* +0 1 foo*f +1 1 foo*foo* +1 1 foobar *ob*a*r* +1 1 aaabababab *ab +1 1 foo* foo\* +0 1 foobar foo\*bar +1 1 f\oo f\\oo +1 1 ball *[al]? +0 1 ten[ten] +1 1 ten**[!te] +0 1 ten**[!ten] +1 1 tent[a-g]n +0 1 tent[!a-g]n +1 1 tont[!a-g]n +1 1 tont[^a-g]n +1 1 a]ba[]]b +1 1 a-ba[]-]b +1 1 a]ba[]-]b +0 1 aaba[]-]b +1 1 aaba[]a-]b +1 1 ] ] + +# Extended slash-matching features +0 1 foo/baz/barfoo*bar +1 1 foo/baz/barfoo**bar +0 1 foo/barfoo?bar +0 1 foo/barfoo[/]bar +0 1 foo/barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +1 1 foo-barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +0 1 foo**/foo +1 1 /foo **/foo +1 1 bar/baz/foo**/foo +0 1 bar/baz/foo*/foo +0 0 foo/bar/baz**/bar* +1 1 deep/foo/bar/baz **/bar/* +0 1 deep/foo/bar/baz/ **/bar/* +1 1 deep/foo/bar/baz/ **/bar/** +0 1 deep/foo/bar **/bar/* +1 1 deep/foo/bar/ **/bar/** +1 1 foo/bar/baz**/bar** +1 1 foo/bar/baz/x */bar/** +0 0 deep/foo/bar/baz/x */bar/** +1 1 deep/foo/bar/baz/x **/bar/*/* + +# Various additional tests +0 1 acrt a[c-c]st +1 1 acrt a[c-c]rt +0 1 ] [!]-] +1 1 a [!]-] +0 1 '' \ +0 1 \ \ +0 1 /\ */\ +1 1 /\ */\\ +1 1 foofoo +1 1 @foo @foo +0 1 foo@foo +1 1 [ab] \[ab] +1 1 [ab] [[]ab] +1 1 [ab] [[:]ab] +0 1 [ab] [[::]ab] +1 1 [ab] [[:digit]ab] +1 1 [ab] [\[:]ab] +1 1 ?a?b \??\?b +1 1 abc\a\b\c +0 1 foo'' +1 1 foo/bar/baz/to **/t[o] + +# Character class tests +1 1 a1B[[:alpha:]][[:digit:]][[:upper:]] +0 1 a [[:digit:][:upper:][:space:]] +1 1 A [[:digit:][:upper:][:space:]] +1 1 1 [[:digit:][:upper:][:space:]] +0 1 1 [[:digit:][:upper:][:spaci:]] +1 1 ' '[[:digit:][:upper:][:space:]] +0 1 . [[:digit:][:upper:][:space:]] +1 1 . [[:digit:][:punct:][:space:]] +1 1 5 [[:xdigit:]] +1 1 f [[:xdigit:]] +1 1 D [[:xdigit:]] +1 1 _ [[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +#1 1 � [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 [^[:alnum:][:alpha:][:blank:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 . [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]] +1 1 5 [a-c[:digit:]x-z] +1 1 b [a-c[:digit:]x-z] +1 1 y [a-c[:digit:]x-z] +0 1 q [a-c[:digit:]x-z] + +# Additional tests, including some malformed wildmats
[PATCH 2/8] wildmatch: remove unnecessary functions
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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.c
@@ -53,33 +53,19 @@
#define ISUPPER(c) (ISASCII(c) isupper(c))
#define ISXDIGIT(c) (ISASCII(c) isxdigit(c))
-#ifdef WILD_TEST_ITERATIONS
-int wildmatch_iteration_count;
-#endif
-
static int force_lower_case = 0;
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
-static int dowild(const uchar *p, const uchar *text, const uchar*const *a)
+static int dowild(const uchar *p, const uchar *text)
{
uchar p_ch;
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count++;
-#endif
-
for ( ; (p_ch = *p) != '\0'; text++, p++) {
int matched, special;
uchar t_ch, prev_ch;
- while ((t_ch = *text) == '\0') {
- if (*a == NULL) {
- if (p_ch != '*')
- return ABORT_ALL;
- break;
- }
- text = *a++;
- }
+ if ((t_ch = *text) == '\0' p_ch != '*')
+ return ABORT_ALL;
if (force_lower_case ISUPPER(t_ch))
t_ch = tolower(t_ch);
switch (p_ch) {
@@ -107,21 +93,15 @@ static int dowild(const uchar *p, const uchar *text, const
uchar*const *a)
/* Trailing ** matches everything. Trailing * matches
* only if there are no more slash characters. */
if (!special) {
- do {
if (strchr((char*)text, '/') != NULL)
return FALSE;
- } while ((text = *a++) != NULL);
}
return TRUE;
}
while (1) {
- if (t_ch == '\0') {
- if ((text = *a++) == NULL)
- break;
- t_ch = *text;
- continue;
- }
- if ((matched = dowild(p, text, a)) != FALSE) {
+ if (t_ch == '\0')
+ break;
+ if ((matched = dowild(p, text)) != FALSE) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -225,144 +205,21 @@ static int dowild(const uchar *p, const uchar *text,
const uchar*const *a)
}
}
-do {
- if (*text)
- return FALSE;
-} while ((text = *a++) != NULL);
-
-return TRUE;
-}
-
-/* Match literal string s against the a virtually-joined string consisting
- * of text and any strings in array a. */
-static int doliteral(const uchar *s, const uchar *text, const uchar*const *a)
-{
-for ( ; *s != '\0'; text++, s++) {
- while (*text == '\0') {
- if ((text = *a++) == NULL)
- return FALSE;
- }
- if (*text != *s)
- return FALSE;
-}
-
-do {
- if (*text)
- return FALSE;
-} while ((text = *a++) != NULL);
-
-return TRUE;
-}
-
-/* Return the last count path elements from the concatenated string.
- * We return a string pointer to the start of the string, and update the
- * array pointer-pointer to point to any remaining string elements. */
-static const uchar *trailing_N_elements(const uchar*const **a_ptr, int count)
-{
-const uchar*const *a = *a_ptr;
-const uchar*const *first_a = a;
-
-while (*a)
- a++;
-
-while (a != first_a) {
- const uchar *s = *--a;
- s += strlen((char*)s);
- while (--s = *a) {
- if (*s == '/' !--count) {
- *a_ptr = a+1;
- return s+1;
- }
- }
-}
-
-if (count == 1) {
- *a_ptr = a+1;
- return *a;
-}
-
-return NULL;
+return *text ? FALSE : TRUE;
}
/* Match the pattern against the text string. */
int wildmatch(const char *pattern, const char *text)
{
-static const uchar *nomore[1]; /* A NULL pointer. */
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count = 0;
-#endif
-return dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
+return dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
}
/* Match the pattern against the forced-to-lower-case text string. */
int iwildmatch(const char *pattern, const char *text)
{
-static const uchar *nomore[1]; /* A NULL pointer. */
int ret;
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count = 0;
-#endif
force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
+ret = dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
force_lower_case = 0;
return ret;
}
-
-/* Match pattern p against the a virtually-joined string consisting
- * of all the pointers in array
[PATCH 3/8] Integrate wildmatch to 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 pclo...@gmail.com
---
.gitignore | 1 +
Makefile | 3 +
t/t3070-wildmatch.sh | 178 +++
t/t3070/wildtest.txt | 165 ---
test-wildmatch.c | 14
wildmatch.c | 8 ++-
6 files changed, 203 insertions(+), 166 deletions(-)
create mode 100755 t/t3070-wildmatch.sh
delete mode 100644 t/t3070/wildtest.txt
create mode 100644 test-wildmatch.c
diff --git a/.gitignore b/.gitignore
index a188a82..37c3507 100644
--- a/.gitignore
+++ b/.gitignore
@@ -197,6 +197,7 @@
/test-string-list
/test-subprocess
/test-svn-fe
+/test-wildmatch
/common-cmds.h
*.tar.gz
*.dsc
diff --git a/Makefile b/Makefile
index 8413606..9a97379 100644
--- a/Makefile
+++ b/Makefile
@@ -523,6 +523,7 @@ TEST_PROGRAMS_NEED_X += test-sigchain
TEST_PROGRAMS_NEED_X += test-string-list
TEST_PROGRAMS_NEED_X += test-subprocess
TEST_PROGRAMS_NEED_X += test-svn-fe
+TEST_PROGRAMS_NEED_X += test-wildmatch
TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
@@ -695,6 +696,7 @@ LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += varint.h
LIB_H += walker.h
+LIB_H += wildmatch.h
LIB_H += wt-status.h
LIB_H += xdiff-interface.h
LIB_H += xdiff/xdiff.h
@@ -826,6 +828,7 @@ LIB_OBJS += utf8.o
LIB_OBJS += varint.o
LIB_OBJS += version.o
LIB_OBJS += walker.o
+LIB_OBJS += wildmatch.o
LIB_OBJS += wrapper.o
LIB_OBJS += write_or_die.o
LIB_OBJS += ws.o
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
new file mode 100755
index 000..bb92f8d
--- /dev/null
+++ b/t/t3070-wildmatch.sh
@@ -0,0 +1,178 @@
+#!/bin/sh
+
+test_description='wildmatch tests'
+
+. ./test-lib.sh
+
+match() {
+test_expect_success wildmatch $*
+ if [ $1 = 1 ]; then
+ test-wildmatch wildmatch '$3' '$4'
+ else
+ ! test-wildmatch wildmatch '$3' '$4'
+ fi
+ if [ $2 = 1 ]; then
+ test-wildmatch fnmatch '$3' '$4'
+ else
+ ! test-wildmatch fnmatch '$3' '$4'
+ fi
+
+}
+
+# Basic wildmat features
+match 1 1 foo foo
+match 0 0 foo bar
+match 1 1 ''
+match 1 1 foo '???'
+match 0 0 foo '??'
+match 1 1 foo '*'
+match 1 1 foo 'f*'
+match 0 0 foo '*f'
+match 1 1 foo '*foo*'
+match 1 1 foobar '*ob*a*r*'
+match 1 1 aaabababab '*ab'
+match 1 1 'foo*' 'foo\*'
+match 0 0 foobar 'foo\*bar'
+match 1 1 'f\oo' 'f\\oo'
+match 1 1 ball '*[al]?'
+match 0 0 ten '[ten]'
+match 1 1 ten '**[!te]'
+match 0 0 ten '**[!ten]'
+match 1 1 ten 't[a-g]n'
+match 0 0 ten 't[!a-g]n'
+match 1 1 ton 't[!a-g]n'
+match 1 1 ton 't[^a-g]n'
+match 1 1 'a]b' 'a[]]b'
+match 1 1 a-b 'a[]-]b'
+match 1 1 'a]b' 'a[]-]b'
+match 0 0 aab 'a[]-]b'
+match 1 1 aab 'a[]a-]b'
+match 1 1 ']' ']'
+
+# Extended slash-matching features
+match 0 0 'foo/baz/bar' 'foo*bar'
+match 1 0 'foo/baz/bar' 'foo**bar'
+match 0 0 'foo/bar' 'foo?bar'
+match 0 0 'foo/bar' 'foo[/]bar'
+match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 0 0 'foo' '**/foo'
+match 1 1 '/foo' '**/foo'
+match 1 0 'bar/baz/foo' '**/foo'
+match 0 0 'bar/baz/foo' '*/foo'
+match 0 0 'foo/bar/baz' '**/bar*'
+match 1 0 'deep/foo/bar/baz' '**/bar/*'
+match 0 0 'deep/foo/bar/baz/' '**/bar/*'
+match 1 0 'deep/foo/bar/baz/' '**/bar/**'
+match 0 0 'deep/foo/bar' '**/bar/*'
+match 1 0 'deep/foo/bar/' '**/bar/**'
+match 1 0 'foo/bar/baz' '**/bar**'
+match 1 0 'foo/bar/baz/x' '*/bar/**'
+match 0 0 'deep/foo/bar/baz/x' '*/bar/**'
+match 1 0 'deep/foo/bar/baz/x' '**/bar/*/*'
+
+# Various additional tests
+match 0 0 'acrt' 'a[c-c]st'
+match 1 1 'acrt' 'a[c-c]rt'
+match 0 0 ']' '[!]-]'
+match 1 1 'a' '[!]-]'
+match 0 0 '' '\'
+match 0 0 '\' '\'
+match 0 0 '/\' '*/\'
+match 1 1 '/\' '*/\\'
+match 1 1 'foo' 'foo'
+match 1 1 '@foo' '@foo'
+match 0 0 'foo' '@foo'
+match 1 1 '[ab]' '\[ab]'
+match 1 1 '[ab]' '[[]ab]'
+match 1 1 '[ab]' '[[:]ab]'
+match 0 0 '[ab]' '[[::]ab]'
+match 1 1 '[ab]' '[[:digit]ab]'
+match 1 1 '[ab]' '[\[:]ab]'
+match 1 1 '?a?b' '\??\?b'
+match 1 1 'abc' '\a\b\c'
+match 0 0 'foo' ''
+match 1 0 'foo/bar/baz/to' '**/t[o]'
+
+# Character class tests
+match 1 1 'a1B' '[[:alpha:]][[:digit:]][[:upper:]]'
+match 0 0 'a' '[[:digit:][:upper:][:space:]]'
+match 1 1 'A' '[[:digit:][:upper:][:space:]]'
+match 1 0 '1' '[[:digit:][:upper:][:space:]]'
+match 0 0 '1' '[[:digit:][:upper:][:spaci:]]'
+match 1 1 ' ' '[[:digit:][:upper:][:space:]]'
+match 0 0 '.' '[[:digit:][:upper:][:space:]]'
+match 1 1 '.' '[[:digit:][:punct:][:space:]]'
+match 1 1 '5' '[[:xdigit:]]'
+match 1 1 'f' '[[:xdigit:]]'
+match 1 1 'D' '[[:xdigit:]]'
+match 1 0 '_'
[PATCH 4/8] wildmatch: remove static variable force_lower_case
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 pclo...@gmail.com
---
test-wildmatch.c | 4 ++--
wildmatch.c | 23 ++-
wildmatch.h | 3 +--
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 08962d5..5c18cf8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -4,9 +4,9 @@
int main(int argc, char **argv)
{
if (!strcmp(argv[1], wildmatch))
- return wildmatch(argv[3], argv[2]) ? 0 : 1;
+ return wildmatch(argv[3], argv[2], 0) ? 0 : 1;
else if (!strcmp(argv[1], iwildmatch))
- return iwildmatch(argv[3], argv[2]) ? 0 : 1;
+ return wildmatch(argv[3], argv[2], FNM_CASEFOLD) ? 0 : 1;
else if (!strcmp(argv[1], fnmatch))
return fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 7b64a6b..2382873 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -11,8 +11,8 @@
#include stddef.h
#include ctype.h
-#include string.h
+#include cache.h
#include wildmatch.h
typedef unsigned char uchar;
@@ -59,11 +59,9 @@ typedef unsigned char uchar;
#define ISUPPER(c) (ISASCII(c) isupper(c))
#define ISXDIGIT(c) (ISASCII(c) isxdigit(c))
-static int force_lower_case = 0;
-
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
-static int dowild(const uchar *p, const uchar *text)
+static int dowild(const uchar *p, const uchar *text, int force_lower_case)
{
uchar p_ch;
@@ -107,7 +105,7 @@ static int dowild(const uchar *p, const uchar *text)
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text)) != FALSE) {
+ if ((matched = dowild(p, text, force_lower_case)) != FALSE) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -215,17 +213,8 @@ static int dowild(const uchar *p, const uchar *text)
}
/* Match the pattern against the text string. */
-int wildmatch(const char *pattern, const char *text)
-{
-return dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
-}
-
-/* Match the pattern against the forced-to-lower-case text string. */
-int iwildmatch(const char *pattern, const char *text)
+int wildmatch(const char *pattern, const char *text, int flags)
{
-int ret;
-force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
-force_lower_case = 0;
-return ret;
+return dowild((const uchar*)pattern, (const uchar*)text,
+ flags FNM_CASEFOLD ? 1 : 0) == TRUE;
}
diff --git a/wildmatch.h b/wildmatch.h
index 562faa3..e974f9a 100644
--- a/wildmatch.h
+++ b/wildmatch.h
@@ -1,4 +1,3 @@
/* wildmatch.h */
-int wildmatch(const char *pattern, const char *text);
-int iwildmatch(const char *pattern, const char *text);
+int wildmatch(const char *pattern, const char *text, int flags);
--
1.8.0.rc0.29.g1fdd78f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] wildmatch: fix case-insensitive matching
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: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wildmatch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wildmatch.c b/wildmatch.c
index 2382873..fdb8cb1 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -72,6 +72,8 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
return ABORT_ALL;
if (force_lower_case ISUPPER(t_ch))
t_ch = tolower(t_ch);
+ if (force_lower_case ISUPPER(p_ch))
+ p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
/* Literal match with following character. Note that the test
--
1.8.0.rc0.29.g1fdd78f
--
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 6/8] wildmatch: adjust ** behavior
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 with file/directory 'def'
- abc/** - equivalent to /abc/
- abc/**/def - abc/x/def, abc/x/y/def...
- other ** cases are downgraded to normal *
Basically the magic of ** only remains if it's wrapped around by
slashes.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t3070-wildmatch.sh | 2 +-
wildmatch.c | 8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index bb92f8d..d320f84 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -51,7 +51,7 @@ match 1 1 ']' ']'
# Extended slash-matching features
match 0 0 'foo/baz/bar' 'foo*bar'
-match 1 0 'foo/baz/bar' 'foo**bar'
+match 0 0 'foo/baz/bar' 'foo**bar'
match 0 0 'foo/bar' 'foo?bar'
match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
diff --git a/wildmatch.c b/wildmatch.c
index fdb8cb1..1b39346 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -91,8 +91,14 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
continue;
case '*':
if (*++p == '*') {
+ const uchar *prev_p = p - 2;
while (*++p == '*') {}
- special = TRUE;
+ if ((prev_p == text || *prev_p == '/') ||
+ (*p == '\0' || *p == '/' ||
+(p[0] == '\\' p[1] == '/'))) {
+ special = TRUE;
+ } else
+ special = FALSE;
} else
special = FALSE;
if (*p == '\0') {
--
1.8.0.rc0.29.g1fdd78f
--
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 7/8] wildmatch: make /**/ match zero or more directories
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 also makes **/foo match foo in addition to x/foo,
x/y/foo..
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t3070-wildmatch.sh | 8 +++-
wildmatch.c | 17 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index d320f84..a247a36 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -52,11 +52,17 @@ match 1 1 ']' ']'
# Extended slash-matching features
match 0 0 'foo/baz/bar' 'foo*bar'
match 0 0 'foo/baz/bar' 'foo**bar'
+match 1 1 'foo/baz/bar' 'foo/**/bar'
+match 1 0 'foo/baz/bar' 'foo/**/**/bar'
+match 1 0 'foo/b/a/z/bar' 'foo/**/bar'
+match 1 0 'foo/b/a/z/bar' 'foo/**/**/bar'
+match 1 0 'foo/bar' 'foo/**/bar'
+match 1 0 'foo/bar' 'foo/**/**/bar'
match 0 0 'foo/bar' 'foo?bar'
match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 0 0 'foo' '**/foo'
+match 1 0 'foo' '**/foo'
match 1 1 '/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
diff --git a/wildmatch.c b/wildmatch.c
index 1b39346..4069b2d 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -96,6 +96,23 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
if ((prev_p == text || *prev_p == '/') ||
(*p == '\0' || *p == '/' ||
(p[0] == '\\' p[1] == '/'))) {
+ /*
+* Assuming we already match 'foo/' and are at
+* star star slash, just assume it matches
+* nothing and go ahead match the rest of the
+* pattern with the remaining string. This
+* helps make foo/**/bar ( because
+* otherwise it breaks C comment syntax) match
+* both foo/bar and foo/a/bar.
+*
+* Crazy patterns like /**/**/ are
+* treated like /**/. But undefined
+* behavior is even appropriate for people
+* writing such a pattern.
+*/
+ if (p[0] == '/'
+ dowild(p + 1, text, force_lower_case) == TRUE)
+ return TRUE;
special = TRUE;
} else
special = FALSE;
--
1.8.0.rc0.29.g1fdd78f
--
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 8/8] Support ** wildcard in .gitignore and .gitattributes
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 38 ++
t/t3001-ls-files-others-exclude.sh | 19 +++
5 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 96639e0..5a9c9f7 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -104,6 +104,25 @@ PATTERN FORMAT
For example, /{asterisk}.c matches cat-file.c but not
mozilla-sha1/sha1.c.
+Two consecutive asterisks (`**`) in patterns matched against
+full pathname may have special meaning:
+
+ - A leading `**` followed by a slash means match in all
+ directories. For example, `**/foo` matches file or directory
+ `foo` anywhere, the same as pattern `foo`. **/foo/bar
+ matches file or directory `bar` anywhere that is directly
+ under directory `foo`.
+
+ - A trailing /** matches everything inside. For example,
+ abc/** is equivalent to `/abc/`.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, `a/**/b`
+ matches `a/b`, `a/x/b`, `a/x/y/b` and so on.
+
+ - Consecutive asterisks otherwise are treated like normal
+ asterisk wildcards.
+
NOTES
-
diff --git a/attr.c b/attr.c
index 887a9ae..e85e5ed 100644
--- a/attr.c
+++ b/attr.c
@@ -12,6 +12,7 @@
#include exec_cmd.h
#include attr.h
#include dir.h
+#include wildmatch.h
const char git_attr__true[] = (builtin)true;
const char git_attr__false[] = \0(builtin)false;
@@ -666,7 +667,8 @@ static int path_matches(const char *pathname, int pathlen,
return 0;
if (baselen != 0)
baselen++;
- return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+ return wildmatch(pattern, pathname + baselen,
+ignore_case ? FNM_CASEFOLD : 0);
}
static int macroexpand_one(int attr_nr, int rem);
diff --git a/dir.c b/dir.c
index 4868339..dc721c0 100644
--- a/dir.c
+++ b/dir.c
@@ -8,6 +8,7 @@
#include cache.h
#include dir.h
#include refs.h
+#include wildmatch.h
struct path_simplify {
int len;
@@ -575,7 +576,8 @@ int excluded_from_list(const char *pathname,
namelen -= prefix;
}
- if (!namelen || !fnmatch_icase(exclude, name, FNM_PATHNAME))
+ if (!namelen ||
+ wildmatch(exclude, name, ignore_case ? FNM_CASEFOLD : 0))
return to_exclude;
}
return -1; /* undecided */
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index febc45c..67a5694 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -232,4 +232,42 @@ test_expect_success 'bare repository: test
info/attributes' '
attr_check subdir/a/i unspecified
'
+test_expect_success '** test' '
+ cd ..
+ echo **/f foo=bar .gitattributes
+ cat \EOF expect
+f: foo: bar
+a/f: foo: bar
+a/b/f: foo: bar
+a/b/c/f: foo: bar
+EOF
+ git check-attr foo -- f actual 2err
+ git check-attr foo -- a/f actual 2err
+ git check-attr foo -- a/b/f actual 2err
+ git check-attr foo -- a/b/c/f actual 2err
+ test_cmp expect actual
+ test_line_count = 0 err
+'
+
+test_expect_success '** with no slashes test' '
+ echo a**f foo=bar .gitattributes
+ git check-attr foo -- f actual
+ cat \EOF expect
+f: foo: unspecified
+af: foo: bar
+axf: foo: bar
+a/f: foo: unspecified
+a/b/f: foo: unspecified
+a/b/c/f: foo: unspecified
+EOF
+ git check-attr foo -- f actual 2err
+ git check-attr foo -- af actual 2err
+ git check-attr foo -- axf actual 2err
+ git check-attr foo -- a/f actual 2err
+ git check-attr foo -- a/b/f actual 2err
+ git check-attr foo -- a/b/c/f actual 2err
+ test_cmp expect actual
+ test_line_count = 0 err
+'
+
test_done
diff --git a/t/t3001-ls-files-others-exclude.sh
b/t/t3001-ls-files-others-exclude.sh
index c8fe978..278315d 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -214,4 +214,23 @@ test_expect_success 'subdirectory ignore (l1)' '
test_cmp expect actual
'
+
+test_expect_success 'ls-files with ** patterns' '
+ cat \EOF expect
+a.1
+one/a.1
+one/two/a.1
+three/a.1
+EOF
+ git ls-files -o -i --exclude **/a.1 actual
+ test_cmp expect actual
+'
+
+
+test_expect_success 'ls-files with ** patterns and no slashes' '
+ : expect
+ git ls-files -o -i --exclude one**a.1 actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.0.rc0.29.g1fdd78f
--
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
Re: In search of a version control system
On Mon, Oct 8, 2012 at 11:30 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Ramkumar Ramachandra artag...@gmail.com 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), then file locking is indeed not such a bad idea. gitolite to the rescue: http://sitaramc.github.com/gitolite/locking.html If you want to setup a git server, look at gitolite. It's really easy and slick. I would advise against the file locking, though. You ain't gonna need it ;-) -- David -- 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 nd/attr-match-optim-more 2/2] attr: more matching optimizations from .gitignore
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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. Basically it tries to
avoid fnmatch as much as possible in favor of strncmp.
A few notes from this work is put in the documentation:
* !pattern syntax is not supported in .gitattributes. Negative
patterns may work well for a single attribute like .gitignore. It's
confusing in .gitattributes are many attributes can be
set/unset/undefined at using the same pattern.
I think the above misses the point.
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 path !attr.
Both are used in conjunction with some other (typically more
generic) pattern that sets, sets to a value, and/or unsets the
attribute, to countermand its effect.
If you were to allow !path attr, what does it mean? It obviously
is not about setting the attr to true or to a string value, but is
it countermanding an earlier set and telling us to unset the attr,
or make the attr unspecified?
That is the ambiguity issue !pattern syntax would introduce if it
were to be allowed in the attributes. I think multiple attributes
on the same line is a red herring.
* we support attaching attributes to directories at the syntax
level, but we do not really attach attributes on directory or use
them.
I would say ... but we do not currently use attributes on
directories.
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 80120ea..cc2ff1d 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -23,7 +23,7 @@ Each line in `gitattributes` file is of form:
That is, a pattern followed by an attributes list,
separated by whitespaces. When the pattern matches the
path in question, the attributes listed on the line are given to
-the path.
+the path. Only files can be attached attributes to.
Symbolic links?
I would strongly suggest dropping Only ... can be You can
specify attributes to anything and check with check-attr. It is
just that core part does not have anything that pays attention to
attributes given to directories in the current codebase.
@@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Unlike `.gitignore`, negative patterns are forbidden.
OK (I am debating myself if it helps the readers if we said why it
is forbidden to write such).
diff --git a/attr.c b/attr.c
index e7caee4..7e85f82 100644
--- a/attr.c
+++ b/attr.c
@@ -115,6 +115,13 @@ struct attr_state {
const char *setto;
};
+struct pattern {
+ const char *pattern;
+ int patternlen;
+ int nowildcardlen;
+ int flags; /* EXC_FLAG_* */
+};
+
/*
* One rule, as from a .gitattributes file.
*
@@ -131,7 +138,7 @@ struct attr_state {
*/
struct match_attr {
union {
- char *pattern;
+ struct pattern pat;
struct git_attr *attr;
} u;
char is_macro;
@@ -241,9 +248,17 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
if (is_macro)
res-u.attr = git_attr_internal(name, namelen);
else {
- res-u.pattern = (char *)(res-state[num_attr]);
- memcpy(res-u.pattern, name, namelen);
- res-u.pattern[namelen] = 0;
+ char *p = (char *)(res-state[num_attr]);
+ memcpy(p, name, namelen);
+ p[namelen] = 0;
This is inherited from the original code, but *res is calloc(3)ed
so the above memcpy() automatically NUL terminates this string.
+ res-u.pat.pattern = p;
+ parse_exclude_pattern(res-u.pat.pattern,
+ res-u.pat.patternlen,
+ res-u.pat.flags,
+ res-u.pat.nowildcardlen);
+ if (res-u.pat.flags EXC_FLAG_NEGATIVE)
+ die(_(Negative patterns are forbidden in git
attributes\n
+ Use '\\!' for literal leading exclamation.));
}
res-is_macro = is_macro;
res-num_attr = num_attr;
@@ -640,25 +655,55 @@ static void prepare_attr_stack(const char *path)
static int path_matches(const char *pathname, int pathlen,
const char *basename,
- const char *pattern,
+ const struct pattern *pat,
Re: [PATCH] submodule: teach foreach command a --revision tree-ish option
Jay Soffian jaysoff...@gmail.com writes:
Teach git submodule foreach a --revision tree-ish 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 why it is useful.
- This is useful.
Huh? How can anybody supposed to agree or disagree with that
claim, when nothing is said about what it does in the first
place?
For example:
$ git submodule foreach --revision v1.0 'git tag v1.0 $sha1'
Whose v1.0 does this example refer to?
The first line of the proposed log message says it is tree-ish,
which means that you can safely substitute --revision T with
--revision $(git rev-parse T^{tree}), so it must name a concrete
single object that is a tree (not a tree-ish). In which repository
is that object found? The top-level superproject? All submodule
repositories share the same object store with the superproject?
The description doesn't make _any_ sense to me. The feature might be
something worth considering about with a better description, but
with the above, I can't tell if it is.
+ If `--revision tree-ish` is given, submodules are traversed starting
+ at the given tree-ish.
What does are traversed starting at the given tree-ish? The
desired or expected state of each submodule is recorded as a commit
object name (not even commit-ish) in its superproject. Did you mean
commit-ish?
+ Though this does not alter the submodule check
+ outs, it may be combined with $sha1 to perform git commands that can
+ operate on a particular commit, such as linkgit:git-tag[1].
Here is what I am guessing, partially with help from the horrible example:
$ git submodule foreach --revision v1.0 'git tag v1.0 $sha1'
Previously, this would have required multiple steps:
$ git checkout v1.0
$ git submodule update
$ git submodule foreach 'git tag v1.0'
where there appears two v1.0 that are used for totally different
purposes which does not help guessing. Perhaps --revision names a
tree-ish taken from the top-level superproject, and for each
submodule that appear in the tree in the superproject, the command
specified by foreach is run with the usual $sha1, $name, $path set
to the state in the submodules that top-level tree wants to have,
and this is done without actually checking anything out. So the
first v1.0 in that confusing example is about specifying a tree in
the superproject repository, and the second v1.0 does not have any
relationship with that first v1.0 (the first one could have been HEAD~2
when you have committed twice in the superproject since you tagged v1.0
and remembered that you forgot to tag its submodules).
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 foreach --revision v1.0 'git grep -e frotz $sha1'
@@ -379,6 +379,7 @@ Use -f if you really want to add it. 2
cmd_foreach()
{
# parse $args after submodule ... foreach.
+ revision=
while test $# -ne 0
do
case $1 in
@@ -388,6 +389,11 @@ cmd_foreach()
--recursive)
recursive=1
;;
+ --revision)
+ git rev-parse --quiet --verify $2 /dev/null || usage
+ revision=$2
Shouldn't this part of the code verify $2^{tree} instead to ensure
that $2 is a tree-ish?
+ shift
+ ;;
-*)
usage
;;
@@ -404,7 +410,17 @@ cmd_foreach()
# command in the subshell (and a recursive call to this function)
exec 30
- module_list |
+ if test -n $revision
+ then
+ # make ls-tree output look like ls-files output
+ git ls-tree -r $revision | grep '^16 ' |
+ while read mode unused sha1 sm_path
+ do
+ echo $mode $sha1 0 $sm_path
+ done
+ else
+ module_list
+ fi |
Hrm, it is somewhat unfortunate that you cannot limit the set of
submodules to apply foreach to, like other commands like init,
update, status, etc. (not a new problem).
--
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: In search of a version control system
David Aguilar dav...@gmail.com 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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
