Feature Request: gitignore recursion
I'm hoping to get the following feature implemented into git. Add the ability to recursively include using: !/my_dir/**/* Currently, in order to include a directory with multiple sub-directories within a excluded directory, you must do the following: !/my_dir/ !/my_dir/* !/my_dir/*/* !/my_dir/*/*/* !/my_dir/*/*/*/* !/my_dir/*/*/*/*/* Here is a use case: When developing a WordPress site you typically only place the wp-content/themes directory under version control. Once you start adding custom plugins, README files, and a task manager like Grunt JS, you then have to starting getting creative with your .gitignore if your .git directory is in the web root directory. Here is an example: https://gist.github.com/AJ-Acevedo/6859779 Thanks for taking the time to consider this feature AJ -- 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] mergetools/diffmerge: support DiffMerge as a git mergetool
On Sat, Oct 5, 2013 at 1:29 AM, Stefan Saasen wrote:
> DiffMerge is a non-free (but gratis) tool that supports OS X, Windows and
> Linux.
>
> See http://www.sourcegear.com/diffmerge/
>
> DiffMerge includes a script `/usr/bin/diffmerge` that can be used to launch
> the
> graphical compare tool.
>
> This change adds mergetool support for DiffMerge and adds 'diffmerge' as an
> option to the mergetool help.
>
> Signed-off-by: Stefan Saasen
> ---
> contrib/completion/git-completion.bash | 2 +-
> git-mergetool--lib.sh | 2 +-
> mergetools/diffmerge | 15 +++
> 3 files changed, 17 insertions(+), 2 deletions(-)
> create mode 100644 mergetools/diffmerge
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index e1b7313..07b0ba5 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1188,7 +1188,7 @@ _git_diff ()
> __git_complete_revlist_file
> }
>
> -__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
> +__git_mergetools_common="diffuse diffmerge ecmerge emerge kdiff3 meld
> opendiff
> tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3
> codecompare
> "
It's a little unfortunate that we have to keep repeating ourselves
here. mergetool--lib has a list_merge_tool_candidate() that populates
$tools and help us avoid having to maintain these lists in separate
files.
It might be worth leaving the git-completion.bash bits alone in this
first patch and follow it up with a change that generalizes the "list
of tools" thing so that it can be reused here, possibly. The
show_tool_help() function, as used by "git difftool --tool-help" and
"git mergetool --tool-help", might be a good place to look for
inspiration.
We were able to eliminate duplication in the docs (see the handling
for $(mergetools_txt) in Documentation/Makefile) so it'd be nice if we
could do the same for git-completion.bash, somehow.
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index feee6a4..6d0fa3b 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -250,7 +250,7 @@ list_merge_tool_candidates () {
> else
> tools="opendiff kdiff3 tkdiff xxdiff meld $tools"
> fi
> - tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3
> codecompare"
> + tools="$tools gvimdiff diffuse diffmerge ecmerge p4merge
> araxis bc3 codecompare"
I think this line was already too long in its current form. Would you
mind splitting up this long line?
> fi
> case "${VISUAL:-$EDITOR}" in
> *vim*)
> diff --git a/mergetools/diffmerge b/mergetools/diffmerge
> new file mode 100644
> index 000..85ac720
> --- /dev/null
> +++ b/mergetools/diffmerge
> @@ -0,0 +1,15 @@
> +diff_cmd () {
> + "$merge_tool_path" "$LOCAL" "$REMOTE" >/dev/null 2>&1
> +}
> +
> +merge_cmd () {
> + if $base_present
> + then
> + "$merge_tool_path" --merge --result="$MERGED" \
> + "$LOCAL" "$BASE" "$REMOTE"
> + else
> + "$merge_tool_path" --merge \
> + --result="$MERGED" "$LOCAL" "$REMOTE"
> + fi
> + status=$?
> +}
Other than those two minor notes, this looks good to me.
Thanks,
--
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
[PATCH 6/6] sparse: Fix some "using sizeof on a function" warnings
Sparse issues an "using sizeof on a function" warning for each call to curl_easy_setopt() which sets an option that takes a function pointer parameter. (currently 12 such warnings over 4 files.) The warnings relate to the use of the "typecheck-gcc.h" header file which adds a layer of type-checking macros to the curl function invocations (for gcc >= 4.3 and !__cplusplus). As part of the type-checking layer, 'sizeof' is applied to the function parameter of curl_easy_setopt(). Note that, in the context of sizeof, the function to function pointer conversion is not performed and that sizeof(f) != sizeof(&f). A simple solution, therefore, would be to replace the function name in each such call to curl_easy_setopt() with an explicit function pointer expression (i.e. replace f with &f). However, the "typecheck-gcc.h" header file is only conditionally included, in addition to the gcc and C++ checks mentioned above, depending on the CURL_DISABLE_TYPECHECK preprocessor variable. In order to suppress the warnings, we use target-specific variable assignments to add -DCURL_DISABLE_TYPECHECK to SPARSE_FLAGS for each file affected (http-push.c, http.c, http-walker.c and remote-curl.c). Signed-off-by: Ramsay Jones --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index de3d72c..4fde227 100644 --- a/Makefile +++ b/Makefile @@ -2018,6 +2018,9 @@ gettext.sp gettext.s gettext.o: GIT-PREFIX gettext.sp gettext.s gettext.o: EXTRA_CPPFLAGS = \ -DGIT_LOCALE_PATH='"$(localedir_SQ)"' +http-push.sp http.sp http-walker.sp remote-curl.sp: SPARSE_FLAGS += \ + -DCURL_DISABLE_TYPECHECK + ifdef NO_EXPAT http-walker.sp http-walker.s http-walker.o: EXTRA_CPPFLAGS = -DNO_EXPAT endif -- 1.8.4 -- 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/6] t9500-*.sh: Fix highlight test hang on Linux Mint
Linux Mint has an implementation of the highlight command (unrelated to the one from http://www.andre-simon.de) that works as a simple filter. The script uses 'sed' to add terminal colour escape codes around text matching a regular expression. When t9500-*.sh attempts to run "highlight --version", the script simply hangs waiting for input. (See https://bugs.launchpad.net/linuxmint/+bug/815005). The tool required by gitweb can be installed from the 'highlight' package. Unfortunately, given the default $PATH, this leads to the tool having lower precedence than the script. In order to avoid hanging the test, add ' --- t/t9500-gitweb-standalone-no-errors.sh | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh index 6fca193..718014d 100755 --- a/t/t9500-gitweb-standalone-no-errors.sh +++ b/t/t9500-gitweb-standalone-no-errors.sh @@ -683,9 +683,11 @@ test_expect_success \ # syntax highlighting -highlight --version >/dev/null 2>&1 +highlight_version=$(highlight --version /dev/null) if [ $? -eq 127 ]; then - say "Skipping syntax highlighting test, because 'highlight' was not found" + say "Skipping syntax highlighting tests: 'highlight' not found" +elif test -z "$highlight_version"; then + say "Skipping syntax highlighting tests: incorrect 'highlight' found" else test_set_prereq HIGHLIGHT cat >>gitweb_config.perl <<-\EOF -- 1.8.4 -- 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/6] git-format-patch.txt: Add to Thunderbird configuration
The Thunderbird section of the 'MUA-specific hints' contains three different approaches to setting up the mail client to leave patch emails unmolested. The second approach (configuration) has a step missing when configuring the composition window not to wrap. In particular, the "mailnews.wraplength" configuration variable needs to be set to zero. Update the documentation to add the missing setting. Signed-off-by: Ramsay Jones --- Documentation/git-format-patch.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 9e0ef0e..5c0a4ab 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -438,7 +438,8 @@ Edit..Preferences..Composition, wrap plain text messages at 0 In Thunderbird 3: Edit..Preferences..Advanced..Config Editor. Search for "mail.wrap_long_lines". -Toggle it to make sure it is set to `false`. +Toggle it to make sure it is set to `false`. Also, search for +"mailnews.wraplength" and set the value to 0. 3. Disable the use of format=flowed: Edit..Preferences..Advanced..Config Editor. Search for -- 1.8.4 -- 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/6] wrapper.c: Fix a sparse warning
When the NO_MKSTEMPS build variable is not set, sparse issues an
"'gitmkstemps' was not declared. Should it be static?" warning.
The 'gitmkstemps' function definition is only required when the
NO_MKSTEMPS variable is set. In order to suppress the warning,
use a preprocessor conditional to include the definition only
when needed.
Signed-off-by: Ramsay Jones
---
wrapper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wrapper.c b/wrapper.c
index f92b147..9a6aaaf 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -360,10 +360,12 @@ int git_mkstemp_mode(char *pattern, int mode)
return git_mkstemps_mode(pattern, 0, mode);
}
+#ifdef NO_MKSTEMPS
int gitmkstemps(char *pattern, int suffix_len)
{
return git_mkstemps_mode(pattern, suffix_len, 0600);
}
+#endif
int xmkstemp_mode(char *template, int mode)
{
--
1.8.4
--
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/6] refs.c: Fix a sparse warning
Sparse issues an "Using plain integer as NULL pointer" warning
against a call to update_ref_lock() which passes '0' to the
'int *type_p' parameter. In order to suppress the warning, we
simply change the argument to 'NULL'.
Signed-off-by: Ramsay Jones
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index ad5d66c..3710748 100644
--- a/refs.c
+++ b/refs.c
@@ -3235,7 +3235,7 @@ int update_ref(const char *action, const char *refname,
int flags, enum action_on_err onerr)
{
struct ref_lock *lock;
- lock = update_ref_lock(refname, oldval, flags, 0, onerr);
+ lock = update_ref_lock(refname, oldval, flags, NULL, onerr);
if (!lock)
return 1;
return update_ref_write(action, refname, sha1, lock, onerr);
--
1.8.4
--
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/6] config.c: Fix a sparse warning
Sparse issues an "'git_parse_unsigned' was not declared. Should it
be static?" warning. In order to suppress this warning, since this
symbol only requires file scope, we simply add the static modifier
to its declaration.
Signed-off-by: Ramsay Jones
---
config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 6588cf5..e1d66a1 100644
--- a/config.c
+++ b/config.c
@@ -498,7 +498,7 @@ static int git_parse_signed(const char *value, intmax_t
*ret, intmax_t max)
return 0;
}
-int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
+static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
{
if (value && *value) {
char *end;
--
1.8.4
--
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 0/6] miscellaneous patches
Hi Jonathan, These patches don't have too much in common, hence the subject line, except perhaps that 4 of them fix sparse warnings. Note that the fourth patch is actually a simplified version of an earlier RFC patch. Junio didn't like the idea of using a build variable (GIT_TEST_HIGHLIGHT_BIN) to set the path to the 'correct' highlight tool. see: http://article.gmane.org/gmane.comp.version-control.git/234138 Having recently had to re-configure Thunderbird, I noticed that the documentation needed updating. (actually, I was sure that I had sent a similar patch, years ago, when I last did this! :-P ) ATB, Ramsay Jones Ramsay Jones (6): config.c: Fix a sparse warning refs.c: Fix a sparse warning wrapper.c: Fix a sparse warning t9500-*.sh: Fix highlight test hang on Linux Mint git-format-patch.txt: Add to Thunderbird configuration sparse: Fix some "using sizeof on a function" warnings Documentation/git-format-patch.txt | 3 ++- Makefile | 3 +++ config.c | 2 +- refs.c | 2 +- t/t9500-gitweb-standalone-no-errors.sh | 6 -- wrapper.c | 2 ++ 6 files changed, 13 insertions(+), 5 deletions(-) -- 1.8.4 -- 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: GSS-Negotiate authentication requires that all data fit into postbuffer
On Sun, Oct 06, 2013 at 05:38:24PM +0200, Daniel Stenberg wrote: > On Sun, 6 Oct 2013, brian m. carlson wrote: > > >If there's a way to make Apache with mod_auth_kerb do that with > >curl, then it doesn't require a change to git, and I'm happy to > >make it on my end. But using the curl command line client, I don't > >see an Expect: 100-continue anywhere during the connection using > >Debian's curl 7.32.0-1. Do I need to send a certain amount of > >data to see that behavior? > > Correct, curl will enable "Expect: 100-continue" if the post size is > > 1024 bytes. I've been able to reproduce this behavior with the curl command line client, but it looks like we disable Expect: 100-continue in git since some proxy servers are too stupid to understand it, according to commit 959dfcf. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: GSS-Negotiate authentication requires that all data fit into postbuffer
On Sun, 6 Oct 2013, brian m. carlson wrote: If there's a way to make Apache with mod_auth_kerb do that with curl, then it doesn't require a change to git, and I'm happy to make it on my end. But using the curl command line client, I don't see an Expect: 100-continue anywhere during the connection using Debian's curl 7.32.0-1. Do I need to send a certain amount of data to see that behavior? Correct, curl will enable "Expect: 100-continue" if the post size is > 1024 bytes. -- / daniel.haxx.se -- 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: GSS-Negotiate authentication requires that all data fit into postbuffer
On Sun, Oct 06, 2013 at 05:00:02PM +0200, Daniel Stenberg wrote: > On Sun, 6 Oct 2013, Ilari Liusvaara wrote: > > >>GSS-Negotiate authentication always requires a rewind with CURL. > > >Isn't 'Expect: 100-Continue' meant for stuff like this (not that > >it is always supported properly)? > > Yes it is and libcurl uses 100-Continue by default for that purpose. > But the harsh reality is that lots of (most?) servers just don't > care and aren't setup to respond properly and instead we end up > having to send data multiple times in vain. If there's a way to make Apache with mod_auth_kerb do that with curl, then it doesn't require a change to git, and I'm happy to make it on my end. But using the curl command line client, I don't see an Expect: 100-continue anywhere during the connection using Debian's curl 7.32.0-1. Do I need to send a certain amount of data to see that behavior? The command line I used was curl -v -d '' -H'Transfer-Encoding: chunked' -H'Content-Type: application/x-git-receive-pack-request' --negotiate -u bmc: https://git.crustytoothpaste.net/git/bmc/test.git/git-receive-pack -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: GSS-Negotiate authentication requires that all data fit into postbuffer
On Sun, 6 Oct 2013, Ilari Liusvaara wrote: GSS-Negotiate authentication always requires a rewind with CURL. Isn't 'Expect: 100-Continue' meant for stuff like this (not that it is always supported properly)? Yes it is and libcurl uses 100-Continue by default for that purpose. But the harsh reality is that lots of (most?) servers just don't care and aren't setup to respond properly and instead we end up having to send data multiple times in vain. -- / daniel.haxx.se -- 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: [RFC/PATCHv2 1/3] Documentation/git-svn: Promote the use of --prefix in docs + examples
On Sun, Oct 6, 2013 at 11:51 AM, Philip Oakley wrote: > From: "Johan Herland" >> Cc: Eric Wong > > Excuse my ignorance, but what is the "Carbon copy:" line meant to signify? > Should it be a double "Signed-of-by:" or one of the other "-by:" lines? No, it's not a Signed-off-by, it's merely a hint to someone that they might want to take a closer look at this patch. In this case, I'm Cc-ing Eric Wong, as he is the main git-svn author, and I consider his feedback on these patches very valuable. When I add a Cc: to the commit message, git send-email picks it up, and adds him to the Cc-list of the resulting email. I could have achieved the same by passing --cc "Eric ..." directly to git-send-email, but sometimes there might be quite a while between preparing the commit and running git send-email, and in those cases adding the Cc to the commit message saves me from forgetting to Cc him when I some time later get around to running git send-email. That said, my hope is obviously that Eric will have the time/energy/motivation to review these patches, so that I (or someone else) can later replace the "Cc:" line with a corresponding "Reviewed-by:" or "Acked-by:". Even if that does not happen, and the "Cc:" line ends up in the recorded history of Git, I don't consider that a big problem either; a 'git log origin/master | grep "^\s*Cc: " | wc -l' yields 148 existing cases... Hope that helps, ...Johan -- Johan Herland, www.herland.net -- 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: GSS-Negotiate authentication requires that all data fit into postbuffer
On Sun, Oct 06, 2013 at 12:42:36AM +, brian m. carlson wrote: > > GSS-Negotiate authentication always requires a rewind with CURL. > > The remote in question only supports Negotiate authentication, so > prompting for a password in this case isn't going to help. I'm probably > going to look into this over the next couple of days, but two things > need to be done here: 1) do not prompt for a password if only Negotiate > authentication is requested, since it just won't work, and 2) recreate > the data as needed if we have to rewind, since otherwise pushing a fresh > copy of the Linux kernel repo simply isn't going to work as the buffer > will have to be too large. An alternative is to send a small amount of > data, smaller than the postbuffer, in the first chunk and only fail to > rewind if the second or subsequent chunks need rewinding. Isn't 'Expect: 100-Continue' meant for stuff like this (not that it is always supported properly)? -Ilari -- 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: [RFC/PATCHv2 1/3] Documentation/git-svn: Promote the use of --prefix in docs + examples
From: "Johan Herland" Currently, the git-svn defaults to using an empty prefix, which ends up placing the SVN-tracking refs directly in refs/remotes/*. This placement runs counter to Git's convention of placing remote-tracking branches in refs/remotes/$remote/*. This is also in preparation for changing the default value of --prefix at some point in the future. Cc: Eric Wong Excuse my ignorance, but what is the "Carbon copy:" line meant to signify? Should it be a double "Signed-of-by:" or one of the other "-by:" lines? Signed-off-by: Johan Herland --- Documentation/git-svn.txt | 35 +-- 1 file changed, 25 insertions(+), 10 deletions(-) Philip Oakley -- 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] clone: do not segfault when specifying a nonexistent branch
On 10/05/2013 01:55 AM, Duy Nguyen wrote:
> On Fri, Oct 4, 2013 at 9:20 PM, Stefan Beller
> wrote:
>> I think we should emit a warning additionally?
>>
>> Signed-off-by: Stefan Beller
>
> I think it's nice to credit Robert for reporting the fault in the
> commit message (something like "reported-by:" or "noticed-by:"...)
I'll do so in a resend.
>
>> ---
>> builtin/clone.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/builtin/clone.c b/builtin/clone.c
>> index 0aff974..b764ad0 100644
>> --- a/builtin/clone.c
>> +++ b/builtin/clone.c
>> @@ -688,7 +688,7 @@ static void write_refspec_config(const char*
>> src_ref_prefix,
>>
>> if (option_mirror || !option_bare) {
>> if (option_single_branch && !option_mirror) {
>> - if (option_branch) {
>> + if (option_branch && our_head_points_at) {
>> if (strstr(our_head_points_at->name,
>> "refs/tags/"))
>> strbuf_addf(&value, "+%s:%s",
>> our_head_points_at->name,
>> our_head_points_at->name);
>
> This prevents the segfault, but what about remote.*.fetch? Should we
> setup standard refspec for fetch or..?
>
Looking at the code a few lines below, this comment comes up:
/*
* otherwise, the next "git fetch" will
* simply fetch from HEAD without updating
* any remote-tracking branch, which is what
* we want.
*/
This behavior was good for the case (!option_branch && !remote_head_points_at)
Now we extend that behavior doing nothing to
((!option_branch || !our_head_points_at) && !remote_head_points_at)
I am not sure how to handle that case best. The user has given a non existing
branch,
so it doesn't make sense to track that branch, but only have that
registered as a remote*.fetch?
Reading the documentation enhancements of 31b808a
(2012-09-20, clone --single: limit the fetch refspec to fetched branch),
doesn't
talk about this corner case. So maybe the remote.*.fetch shall be set, but no
branch
should be checked out, when running
git clone --depth 1 -b test https://github.com/mitfik/coredump.git
/tmp/coredump.git
Does that make sense?
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
