Re: [PATCH] contrib/hooks: avoid requiring root access in usage instructions

[Junio C Hamano]

Jonathan Nieder  writes:

> Comments in hooks/post-receive-email suggest:
>
>  For example, on debian the hook is stored in
>  /usr/share/git-core/contrib/hooks/post-receive-email:
>
>   chmod a+x post-receive-email
>   cd /path/to/your/repository.git
>   ln -sf /usr/share/git-core/contrib/hooks/post-receive-email 
> hooks/post-receive
>
> Doing that means changing permissions on a file provided by a package,
> which is problematic in a number of ways: the permissions would be
> likely to change back in later upgrades, and changing them requires
> root access.  Copying the script into each repo that uses it is not
> much better, since each copy would be maintained separately and not
> benefit from bugfixes in the master copy.
>
> Better to ship the hook with executable permission and remove the
> chmod line so enabling the hook becomes a one-step process: just
> symlink it into place.
>
> Likewise for the pre-auto-gc-battery hook.
>
> Reported-by: Olivier Berger 
> Signed-off-by: Jonathan Nieder 
> ---
> From .
>
> Thoughts?

We already encourage casting-in-stone a particular version of the
sample hook when a new repository is created by copying them from
the template directory.  This prevents from surprising users when an
updated version of Git changes the behaviour of these samples.  Even
if you think bugs in older ones may be corrected in newer ones,
silently updating the hook the user chose to use by inspecting one
particular version is not something we would want to do lightly. A
buggy devil you know is better than a devil that suddenly changes
its behaviour depending on when your sysadmin updates the version of
Git without your knowing.

I personally think the same applies to these contrib/ hooks, and I
would think it is simpler and more consistent to correct the
instruction in these files to tell users to copy them.

Adding +x bits to these files is a good idea but that is orthogonal
to copying vs symlinking, I think.

> Jonathan
>
>  contrib/hooks/post-receive-email  | 1 -
>  contrib/hooks/pre-auto-gc-battery | 1 -
>  2 files changed, 2 deletions(-)
>  mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery
>
> diff --git a/contrib/hooks/post-receive-email 
> b/contrib/hooks/post-receive-email
> index 8ca6607a..359f1ad2 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -13,7 +13,6 @@
>  # For example, on debian the hook is stored in
>  # /usr/share/git-core/contrib/hooks/post-receive-email:
>  #
> -#  chmod a+x post-receive-email
>  #  cd /path/to/your/repository.git
>  #  ln -sf /usr/share/git-core/contrib/hooks/post-receive-email 
> hooks/post-receive
>  #
> diff --git a/contrib/hooks/pre-auto-gc-battery 
> b/contrib/hooks/pre-auto-gc-battery
> old mode 100644
> new mode 100755
> index 1f914c94..9d0c2d19
> --- a/contrib/hooks/pre-auto-gc-battery
> +++ b/contrib/hooks/pre-auto-gc-battery
> @@ -13,7 +13,6 @@
>  # For example, if the hook is stored in
>  # /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
>  #
> -# chmod a+x pre-auto-gc-battery
>  # cd /path/to/your/repository.git
>  # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
>  #hooks/pre-auto-gc
--
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] contrib/hooks: avoid requiring root access in usage instructions

[Jonathan Nieder]

Comments in hooks/post-receive-email suggest:

 For example, on debian the hook is stored in
 /usr/share/git-core/contrib/hooks/post-receive-email:

  chmod a+x post-receive-email
  cd /path/to/your/repository.git
  ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive

Doing that means changing permissions on a file provided by a package,
which is problematic in a number of ways: the permissions would be
likely to change back in later upgrades, and changing them requires
root access.  Copying the script into each repo that uses it is not
much better, since each copy would be maintained separately and not
benefit from bugfixes in the master copy.

Better to ship the hook with executable permission and remove the
chmod line so enabling the hook becomes a one-step process: just
symlink it into place.

Likewise for the pre-auto-gc-battery hook.

Reported-by: Olivier Berger 
Signed-off-by: Jonathan Nieder 
---
>From .

Thoughts?
Jonathan

 contrib/hooks/post-receive-email  | 1 -
 contrib/hooks/pre-auto-gc-battery | 1 -
 2 files changed, 2 deletions(-)
 mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 8ca6607a..359f1ad2 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -13,7 +13,6 @@
 # For example, on debian the hook is stored in
 # /usr/share/git-core/contrib/hooks/post-receive-email:
 #
-#  chmod a+x post-receive-email
 #  cd /path/to/your/repository.git
 #  ln -sf /usr/share/git-core/contrib/hooks/post-receive-email 
hooks/post-receive
 #
diff --git a/contrib/hooks/pre-auto-gc-battery 
b/contrib/hooks/pre-auto-gc-battery
old mode 100644
new mode 100755
index 1f914c94..9d0c2d19
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -13,7 +13,6 @@
 # For example, if the hook is stored in
 # /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
 #
-# chmod a+x pre-auto-gc-battery
 # cd /path/to/your/repository.git
 # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
 #  hooks/pre-auto-gc
-- 
1.8.0.rc2

--
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: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)

[Peter Krefting]

Nguyen Thai Ngoc Duy:


It's the result of this discussion [1]. I don't remember exactly the
open issues. But I think it involves drawing a line between team
language vs local language, whether team language can be anything
other than English, the maintenance cost for supporting it


Like I said, I can see that defaulting format-patch to output English 
is a good idea (since its output is "protocol data" and not something 
for human consumption), it is the output from diff and show that I 
want to have localized.


I'll see if I can come up with a patch that cater for both use-cases. 
Maybe I can also fix so that log output is fully localized at the same 
time (translating "commit", "author", "date" and outputting locale 
dates (although my locale usess ISO dates, so I can get proper 
formatting there already)).


--
\\// Peter - http://www.softwolves.pp.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: libgit2 status

[Junio C Hamano]

Junio C Hamano  writes:

> Ramkumar Ramachandra  writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.

Having said that, I do not mind moving codeblocks around to make
some files purely library-ish while others purely commands.

Ideally, if you run

$ nm --defined-only -g builtin/frotz.o

you should see nothing but "T cmd_frotz" (there are exceptions, most
notably, what the commands in the "log" family do are so close with
each other that builtin/log.o can define cmd_* for all of them).

$ nm --defined-only -og builtin/*.o  | grep -v 'T cmd_'

a handful of offenders.  If these functions with external linkage
are truly useful across subcommands, we should move them to a more
library-ish location.

It may require splitting the bits that are too closely tied to the
external interface they are implementing from these functions,
generalizing only the core-ish logic from them, and moving them to a
more library-ish file as a preparatory step.  Such a library-ish file
may be created inside lib/ subdirectory from the get-go.

Until that kind of code restructure happens, I do not see much sense
in just moving files, e.g. renaming revision.c to src/revision.c or
lib/revision.c or somesuch.
--
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: Rebase doesn't restore branch pointer back on out of memory

[Junio C Hamano]

Alexander Kostikov  writes:

> Sorry to bother but I was wondering what would be the release version
> that would have this patch.

That depends on how well the people who are interested in this
change test it to smoke out potential issues (if any) in it.

It currently is on the 'pu' branch.
--
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: libgit2 status

[dag]

Junio C Hamano  writes:

> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.

+1

  -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: [msysGit] Re: Git for Windows and line endings

[John Szakmeister]

On Fri, Oct 19, 2012 at 10:39 AM, Chris B  wrote:
[snip]
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.

That's simply not a true, across the board statement.  I really wish
it was, because I find the issue troublesome as well.  Unfortunately,
there are still plenty of applications that don't cope with mixed line
endings very well.  We have a backend that targets several platforms,
and the Windows toolchain is quite keen on having CRLF endings, but we
like LF under Linux, and others.

I also wish that no developers were using Notepad either.  Any time
I've run across it, I've tried to point folks at much more capable
environments... but that only has moderate success.  Of course, it's
even worse these days because Notepad puts a BOM at the front of the
file, making Git think it's a binary file.

One thing I do wish is that I didn't have to do the song and dance to
convert all the files when I set gitattributes:

$ echo "* text=auto" >>.gitattributes
$ rm .git/index # Remove the index to force git to
$ git reset # re-scan the working directory
$ git status# Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

One thing that I like about Subversion was that when you set
svn:eol-style, it took.

-John
--
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: Rebase doesn't restore branch pointer back on out of memory

[Alexander Kostikov]

Sorry to bother but I was wondering what would be the release version
that would have this patch.

-- Alexander


On Wed, Oct 10, 2012 at 8:54 PM, Andrew Wong  wrote:
>
> For the 'format-patch' part, originally I was going to do something like:
>
> git format-patch ... || {
> ...
> }
>
> But later I thought it's better to use a consistent style as the following
> 'am' part.
>
> For the 'am' part, if we kept the following line at the end of the if-block:
>
> fi && move_to_original_branch
>
> then, before exiting the if-block, we would have to do something like:
>
> test 0 != $ret && false
>
> which seems a bit ugly to me. So I removed the use of '&&', and rearrange the
> 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
> better and easier to read.
>
> Andrew Wong (1):
>   rebase: Handle cases where format-patch fails
>
>  git-rebase--am.sh | 51 +--
>  1 file changed, 45 insertions(+), 6 deletions(-)
>
> --
> 1.8.0.rc0.19.gc58a63a.dirty
>



--
Alexander Kostikov
--
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] Fix potential hang in https handshake.

[Junio C Hamano]

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

[PATCH] Fix potential hang in https handshake.

[szager]

It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading.  The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped.  The observed behavior is that
the git command will hang at the terminal and never transfer any
data.

This patch is a workaround for a probable bug in libcurl.  The bug
only seems to manifest around a very specific set of circumstances:

- curl version (from curl/curlver.h):

 #define LIBCURL_VERSION_NUM 0x071307

- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.

Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine).  That would seem to suggest that this issue
is timing-sensitive.

This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:

http://curl.haxx.se/libcurl/c/curl_multi_fdset.html

Signed-off-by: Stefan Zager 
---
 http.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/http.c b/http.c
index df9bb71..b7e7ab4 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,18 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
&max_fd);
 
+   /*
+* It can happen that curl_multi_timeout returns a 
pathologically
+* long timeout when curl_multi_fdset returns no file 
descriptors
+* to read.  See commit message for more details.
+*/
+   if (max_fd < 0 &&
+   (select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 5)) {
+   select_timeout.tv_sec  = 0;
+select_timeout.tv_usec = 5;
+   }
+
select(max_fd+1, &readfds, &writefds, &excfds, 
&select_timeout);
}
}
-- 
1.7.7.3

--
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: Fix potential hang in https handshake (v3)

[Junio C Hamano]

Jeff King  writes:

>> +if (max_fd < 0 &&
>> +select_timeout.tv_sec > 0 ||
>> +select_timeout.tv_usec > 5) {
>> +select_timeout.tv_sec  = 0;
>> +select_timeout.tv_usec = 5;
>> +}
>
> Should there be parentheses separating the || bit from the &&?

Yeah, I think there should be.  Thanks for sharp eyes.

--
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: Fix potential hang in https handshake (v3)

[Jeff King]

On Fri, Oct 19, 2012 at 02:04:20PM -0700, sza...@google.com wrote:

> From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
> From: Stefan Zager 
> Date: Thu, 18 Oct 2012 16:23:53 -0700

Drop these lines.

> Subject: [PATCH] Fix potential hang in https handshake.

And make this one your actual email subject.

> It has been observed that curl_multi_timeout may return a very long
> timeout value (e.g., 294 seconds and some usec) just before
> curl_multi_fdset returns no file descriptors for reading.  The
> upshot is that select() will hang for a long time -- long enough for
> an https handshake to be dropped.  The observed behavior is that
> the git command will hang at the terminal and never transfer any
> data.
> 
> This patch is a workaround for a probable bug in libcurl.  The bug
> only seems to manifest around a very specific set of circumstances:
> 
> - curl version (from curl/curlver.h):
> 
>  #define LIBCURL_VERSION_NUM 0x071307
> 
> - git-remote-https running on an ubuntu-lucid VM.
> - Connecting through squid proxy running on another VM.
> 
> Interestingly, the problem doesn't manifest if a host connects
> through squid proxy running on localhost; only if the proxy is on
> a separate VM (not sure if the squid host needs to be on a separate
> physical machine).  That would seem to suggest that this issue
> is timing-sensitive.

Thanks, that explanation makes much more sense.

> diff --git a/http.c b/http.c
> index df9bb71..51eef02 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
>   FD_ZERO(&excfds);
>   curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
> &max_fd);
>  
> + /* It can happen that curl_multi_timeout returns a 
> pathologically
> +  * long timeout when curl_multi_fdset returns no file 
> descriptors
> +  * to read.  See commit message for more details.
> +  */

Minor nit, but our multi-line comment style is:

  /*
   * blah blah blah
   */

> + if (max_fd < 0 &&
> + select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 5) {
> + select_timeout.tv_sec  = 0;
> + select_timeout.tv_usec = 5;
> + }

Should there be parentheses separating the || bit from the &&?

-Peff
--
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

Fix potential hang in https handshake (v3)

[szager]

>From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
From: Stefan Zager 
Date: Thu, 18 Oct 2012 16:23:53 -0700
Subject: [PATCH] Fix potential hang in https handshake.

It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading.  The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped.  The observed behavior is that
the git command will hang at the terminal and never transfer any
data.

This patch is a workaround for a probable bug in libcurl.  The bug
only seems to manifest around a very specific set of circumstances:

- curl version (from curl/curlver.h):

 #define LIBCURL_VERSION_NUM 0x071307

- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.

Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine).  That would seem to suggest that this issue
is timing-sensitive.

This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:

http://curl.haxx.se/libcurl/c/curl_multi_fdset.html

Signed-off-by: Stefan Zager 
---
 http.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/http.c b/http.c
index df9bb71..51eef02 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
&max_fd);
 
+   /* It can happen that curl_multi_timeout returns a 
pathologically
+* long timeout when curl_multi_fdset returns no file 
descriptors
+* to read.  See commit message for more details.
+*/
+   if (max_fd < 0 &&
+   select_timeout.tv_sec > 0 ||
+   select_timeout.tv_usec > 5) {
+   select_timeout.tv_sec  = 0;
+   select_timeout.tv_usec = 5;
+   }
+
select(max_fd+1, &readfds, &writefds, &excfds, 
&select_timeout);
}
}
-- 
1.7.7.3

--
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

What's cooking in git.git (Oct 2012, #06; Fri, 19)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The 1.8.0 release is expected to be tagged this weekend, after which
I'd disappear for a few weeks, and Git will be in steady and good
hands of Jeff King (thanks) in the meantime.

You can find the changes described here in the integration branches of the
repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* js/mingw-fflush-errno (2012-10-17) 1 commit
  (merged to 'next' on 2012-10-18 at 43d6ebb)
 + maybe_flush_or_die: move a too-loose Windows specific error

 Will merge to 'master' in the first batch after 1.8.0 ships.


* mo/cvs-server-cleanup (2012-10-16) 10 commits
  (merged to 'next' on 2012-10-18 at 5a60da1)
 + cvsserver status: provide real sticky info
 + cvsserver: cvs add: do not expand directory arguments
 + cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
 + cvsserver: split up long lines in req_{status,diff,log}
 + cvsserver: clean up client request handler map comments
 + cvsserver: remove unused functions _headrev and gethistory
 + cvsserver update: comment about how we shouldn't remove a user-modified file
 + cvsserver: add comments about database schema/usage
 + cvsserver: removed unused sha1Or-k mode from kopts_from_path
 + cvsserver t9400: add basic 'cvs log' test
 (this branch is used by mo/cvs-server-updates.)


* mo/cvs-server-updates (2012-10-16) 10 commits
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic
 (this branch uses mo/cvs-server-cleanup.)


* ta/doc-cleanup (2012-10-18) 5 commits
 - Documentation/howto: convert plain text files to asciidoc
 - Documentation/technical: convert plain text files to asciidoc
 - Change headline of technical/send-pack-pipeline.txt to not confuse its 
content with content from git-send-pack.txt
 - Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some 
sha1
 - Split over-long synopsis in git-fetch-pack.txt into several lines

 Misapplication of a patch fixed; the ones near the tip needs to
 update the links to point at the html files, though.


* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
 - Fix "git diff --stat" for interesting - but empty - file changes

 We failed to mention a file without any content change but whose
 permission bit was modified, or (worse yet) a new file without any
 content in the "git diff --stat" output.


* jc/prettier-pretty-note (2012-10-19) 7 commits
 - Documentation: decribe format-patch --notes
 - format-patch --notes: show notes after three-dashes
 - format-patch: append --signature after notes
 - pretty_print_commit(): do not append notes message
 - pretty: prepare notes message at a centralized place
 - format_note(): simplify API
 - pretty: remove reencode_commit_message()

 Needs updates to the placeholder documentation.


* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
  (merged to 'next' on 2012-10-18 at 3864adc)
 + filter-branch: use git-sh-setup's ident parsing functions
 + git-sh-setup: refactor ident-parsing functions

 Will merge to 'master' in the second batch after 1.8.0 ships.


* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
  (merged to 'next' on 2012-10-18 at 54561c7)
 + strbuf: always return a non-NULL value from strbuf_detach

 Will merge to 'master' in the first batch after 1.8.0 ships.


* nd/status-long (2012-10-18) 1 commit
  (merged to 'next' on 2012-10-18 at 53940a1)
 + status: add --long output format option

 Allow an earlier "--short" option on the command line to be
 countermanded with the "--long" option for "git status" and "git
 commit".

 Will merge to 'master' in the second batch after 1.8.0 ships.


* rs/branch-del-symref (2012-10-18) 5 commits
  (merged to 'next' on 2012-10-18 at 68ee254)
 + branch: show targets of deleted symrefs, not sha1s
 + branch: skip commit checks when deleting symref branches
 + branch: delete symref branch, not its target
 + branch: factor out delete_branch_config()
 + branch: factor out check_branch_commit()

 A symbolic ref refs/heads/SYM was not correctly removed with
 "git branch -d SYM"; the command removed the ref pointed by
 SYM instead.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* sz/maint-curl-multi-timeout (2012-10-18) 1 commit
 - Fix potential hang in https handshake

 Sometimes curl_multi_tim

Re: [msysGit] Re: Git for Windows and line endings

[Jeff King]

On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:

> I would like to point out:
> - Git on Linux does not mess around with line endings. I can create
> and edit a file in either line ending on Linux and commit and still
> have it untouched.
> - Git on Windows via Cygwin also does not mess around.
> - If those flavors of Git don't mess around, why should msysgit do it?

Most platforms (i.e., the userspace of most unix-y distributions) do not
mess around with line endings, either, so it is easy to have a sane
default there. I think the Cygwin build just followed that existing
defaults.

But msysgit's behavior was directly responding to user complaints. And
there were a lot of them. I do not use Windows myself, so I have only
the perspective of reading the list discussions. And that only what
bleeds onto the git@vger list, not the msysgit list.

Searching for "crlf" on the list yields over 2300 messages, many of
which discuss specific problems people are having without CRLF support.
I do not think any decision in the open source world is final, and
correcting a wrong decision from the past should always be an option.
But I do not think it is constructive to say "your decision is wrong"
without responding to the arguments that led to that decision. All I see
in your email is "your default is not my preference" without responding
to the discussion and perspectives of others through the years.

> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.

Again, I do not use Windows, so my anecdotes are purely culled from the
list. But people have mentioned that Visual Studio is bad for writing
our CRLFs for files which already have LFs. This makes diffs unreadable,
and gives merges, rebases and cherry-picks lots of spurious conflicts.

> - If there was SO MUCH thought into this, then it was too much; it was
> the wrong thought. There should not have been much at all, and just
> allow Git to do what it does: store things *exactly* as you put it in.
> Allow the clients to worry about things like line endings should they
> have the need to worry about it. I'm not seeing how the revision
> system has any business making alterations to things one commits into
> it.

One of the problems is that people do not realize the issue until they
have built a lot of history with CRLFs or mixed line endings (which they
might not even realize until the project starts being used by somebody
with a different editor or platform), and then they have a very painful
flag day turning on these options and normalizing the repository.

-Peff
--
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] diff: diff.context configuration gives default to -U

[Jeff Muizelaar]

Introduce a configuration variable diff.context that tells
Porcelain commands to use a non-default number of context
lines instead of 3 (the default).  With this variable, users
do not have to keep repeating "git log -U8" from the command
line; instead, it becomes sufficient to say "git config
diff.context 8" just once.

Signed-off-by: Jeff Muizelaar 
---
On 2012-09-27, at 6:18 PM, Junio C Hamano wrote:

> Jeff Muizelaar  writes:
> 
>> +if (!strcmp(var, "diff.context")) {
>> +diff_context_default = git_config_int(var, value);
>> +if (diff_context_default < 0)
>> +return -1;
>> +return 0;
> 
> I am somewhat torn on this part. This fails the entire command when
> diff.context is set to non integer or negative integer, which means
> trouble for a user of a future version of git that accepts such a
> value to do something intelligent we do not anticipate today. The
> useful configuration value cannot be given unless the user is
> certain that .gitconfig file will never be read by older version of
> git.
> 
> Perhaps it is OK, at least for now.  We'd have the same worry for
> what is given to -U anyway.

I left this as is.

>> +test_expect_success 'diff.context affects log' '
>> +git log -1 -p >output &&
>> +! grep firstline output &&
>> +git config diff.context 8 &&
>> +git log -1 -p >output &&
>> +grep firstline output
>> +'
> 
> Is there a reason to favor "log -1 -p" over something a lot simpler
> like "show"?  Not requesting to change anything, but just being
> curious.

No. I changed it to "show" to avoid the surprise.

Other than that I included the test changes you suggested. I did however
adjust the sed 'a' command. It seems that GNU sed and BSD sed have incompatible 
behaviour
here. Unfortunately this also seems to screw up the indentation.

---
 Documentation/diff-config.txt |4 ++
 diff.c|9 -
 t/t4055-diff-context.sh   |   94 +
 3 files changed, 106 insertions(+), 1 deletions(-)
 create mode 100755 t/t4055-diff-context.sh

diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 67a90a8..75ab8a5 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -56,6 +56,10 @@ diff.statGraphWidth::
Limit the width of the graph part in --stat output. If set, applies
to all commands generating --stat output except format-patch.
 
+diff.context::
+   Generate diffs with  lines of context instead of the default of
+   3. This value is overridden by the -U option.
+
 diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/diff.c b/diff.c
index 35d3f07..86e5f2a 100644
--- a/diff.c
+++ b/diff.c
@@ -26,6 +26,7 @@ static int diff_detect_rename_default;
 static int diff_rename_limit_default = 400;
 static int diff_suppress_blank_empty;
 static int diff_use_color_default = -1;
+static int diff_context_default = 3;
 static const char *diff_word_regex_cfg;
 static const char *external_diff_cmd_cfg;
 int diff_auto_refresh_index = 1;
@@ -141,6 +142,12 @@ int git_diff_ui_config(const char *var, const char *value, 
void *cb)
diff_use_color_default = git_config_colorbool(var, value);
return 0;
}
+   if (!strcmp(var, "diff.context")) {
+   diff_context_default = git_config_int(var, value);
+   if (diff_context_default < 0)
+   return -1;
+   return 0;
+   }
if (!strcmp(var, "diff.renames")) {
diff_detect_rename_default = git_config_rename(var, value);
return 0;
@@ -3170,7 +3177,7 @@ void diff_setup(struct diff_options *options)
options->break_opt = -1;
options->rename_limit = -1;
options->dirstat_permille = diff_dirstat_permille_default;
-   options->context = 3;
+   options->context = diff_context_default;
DIFF_OPT_SET(options, RENAME_EMPTY);
 
options->change = diff_change;
diff --git a/t/t4055-diff-context.sh b/t/t4055-diff-context.sh
new file mode 100755
index 000..60348b7
--- /dev/null
+++ b/t/t4055-diff-context.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Mozilla Foundation
+#
+
+test_description='diff.context configuration'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+   cat >x <<-\EOF &&
+   firstline
+   b
+   c
+   d
+   e
+   f
+   preline
+   postline
+   i
+   j
+   k
+   l
+   m
+   n
+   EOF
+   git update-index --add x &&
+   git commit -m initial &&
+
+   git cat-file blob HEAD:x |
+   sed "s/preline/preline\\
+ADDED/" >x &&
+   git update-index --add x &&
+   git commit -m next &&
+
+   git cat-file blob HEAD:x |
+   sed s/ADDED/MODIFIED/ >x
+'
+
+test_expect_success 'the defau

Re: Fix potential hang in https handshake.

[Junio C Hamano]

Jeff King  writes:

> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
>> > IOW, it seems like we are _already_ following the advice referenced in
>> > curl's manpage. Is there some case I am missing? Confused...
>> 
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:

Yeah, that sounds like a more targetted workaround (read: better).

>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
>   FD_ZERO(&excfds);
>   curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
> &max_fd);
>  
> + /*
> +  * Sometimes curl will give a really long timeout for a
> +  * CONNECT when there are no fds to read, but we can
> +  * get better results by running curl_multi_perform
> +  * more frequently.
> +  */
> + if (maxfd < 0 &&
> + (select_timeout.tv_sec > 0 ||
> +  select_timeout.tv_usec > 5)) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 5;
> + }
> +
>   select(max_fd+1, &readfds, &writefds, &excfds, 
> &select_timeout);
>   }
>   }
>
> -Peff
--
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: Fix potential hang in https handshake.

[Jeff King]

On Fri, Oct 19, 2012 at 01:37:06PM -0700, Stefan Zager wrote:

> > diff --git a/http.c b/http.c
> > index df9bb71..cd07cdf 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> > FD_ZERO(&excfds);
> > curl_multi_fdset(curlm, &readfds, &writefds, 
> > &excfds, &max_fd);
> >
> > +   /*
> > +* Sometimes curl will give a really long timeout 
> > for a
> > +* CONNECT when there are no fds to read, but we can
> > +* get better results by running curl_multi_perform
> > +* more frequently.
> > +*/
> > +   if (maxfd < 0 &&
> > +   (select_timeout.tv_sec > 0 ||
> > +select_timeout.tv_usec > 5)) {
> > +   select_timeout.tv_sec = 0;
> > +   select_timeout.tv_usec = 5;
> > +   }
> > +
> > select(max_fd+1, &readfds, &writefds, &excfds, 
> > &select_timeout);
> > }
> > }
> >
> I have no objection to this; any one else?

If you wouldn't mind, I was hoping you could flesh out the comment a bit
more with real details of when this happens (and/or put them in the
commit message). If this is indeed a bug to be worked around, it will be
a huge help to somebody reading this code in a year who can confirm that
modern curl does not need it anymore.

-Peff
--
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: Fix potential hang in https handshake.

[Stefan Zager]

On Fri, Oct 19, 2012 at 1:27 PM, Jeff King  wrote:
>
> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
> > > IOW, it seems like we are _already_ following the advice referenced in
> > > curl's manpage. Is there some case I am missing? Confused...
> >
> > The issue with the current code is sometimes when libcurl is opening a
> > CONNECT style connection through an HTTP proxy it returns a crazy high
> > timeout (>240 seconds) and no fds. In this case Git waits forever.
> > Stefan observed that using a timeout of 50 ms in this situation to
> > poll libcurl is better, as it figures out a lot more quickly that it
> > is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:
>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
> &max_fd);
>
> +   /*
> +* Sometimes curl will give a really long timeout for 
> a
> +* CONNECT when there are no fds to read, but we can
> +* get better results by running curl_multi_perform
> +* more frequently.
> +*/
> +   if (maxfd < 0 &&
> +   (select_timeout.tv_sec > 0 ||
> +select_timeout.tv_usec > 5)) {
> +   select_timeout.tv_sec = 0;
> +   select_timeout.tv_usec = 5;
> +   }
> +
> select(max_fd+1, &readfds, &writefds, &excfds, 
> &select_timeout);
> }
> }
>
> -Peff

I have no objection to this; any one else?

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

Re: Fix potential hang in https handshake.

[Jeff King]

On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:

> > IOW, it seems like we are _already_ following the advice referenced in
> > curl's manpage. Is there some case I am missing? Confused...
> 
> The issue with the current code is sometimes when libcurl is opening a
> CONNECT style connection through an HTTP proxy it returns a crazy high
> timeout (>240 seconds) and no fds. In this case Git waits forever.
> Stefan observed that using a timeout of 50 ms in this situation to
> poll libcurl is better, as it figures out a lot more quickly that it
> is connected to the proxy and can issue the request.

Ah. That sounds like a bug in curl to me. But either way, if we want to
work around it, wouldn't the right thing be to override curl's timeout
in that instance? Like:

diff --git a/http.c b/http.c
index df9bb71..cd07cdf 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, 
&max_fd);
 
+   /*
+* Sometimes curl will give a really long timeout for a
+* CONNECT when there are no fds to read, but we can
+* get better results by running curl_multi_perform
+* more frequently.
+*/
+   if (maxfd < 0 &&
+   (select_timeout.tv_sec > 0 ||
+select_timeout.tv_usec > 5)) {
+   select_timeout.tv_sec = 0;
+   select_timeout.tv_usec = 5;
+   }
+
select(max_fd+1, &readfds, &writefds, &excfds, 
&select_timeout);
}
}

-Peff
--
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: libgit2 status

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Thiago Farina wrote:
>> [...]
>> With some structure like:
>>
>> include/git.h
>> src/git.c
>>
>> ...
>>
>> whatever.
>> [...]
>
> Junio- is it reasonable to expect the directory-restructuring by 2.0?

I actually hate "include/git.h vs src/git.c"; you have distinction
between .c and .h already.
--
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: A design for distributed submodules

[Jens Lehmann]

Am 19.10.2012 02:31, schrieb Lauri Alanko:
> I think I finally agree that it's best to develop submodules further
> rather than introduce a new tool for the functionality I require. Here
> are some explicit proposals for submodules so we can at least establish
> agreement on what should be done. These are in order of decreasing
> importance (to me).

Good to hear that!

> * Upstreamless submodules
> 
> If there is no 'url' key defined for a submodule in .gitconfig, there is
> no "authoritative upstream" for it. When a recursive
> fetch/pull/clone/push is performed on a remote superproject, its
> upstreamless submodules are also fetched/pulled/cloned/pushed directly
> from/to the submodule repositories under the superproject .git/modules.
> If this is the first time that remote's submodules are accessed, that
> remote is initialized for the local submodules: the submodule of the
> remote superproject becomes a remote of the local submodule, and is
> given the same name as the remote of the superproject.
> 
> So, suppose we have a superproject with .gitmodules:
> 
> [submodule "sub"]
> path = sub
> 
> which is hosted at repositories at URL1 and URL2. Then we do:
> 
> git clone --recursive URL1 super
> cd super
> git remote add other URL2
> git fetch --recursive URL2
> 
> Now .git/modules/sub/config has:
> 
> [remote "origin"]
> url = URL1/.git/modules/sub
> [remote "other"]
> url = URL2/.git/modules/sub

So you want to automatically propagate the new superproject remote
"other" into the submodules?

> So the effect is similar to just setting the submodule's url as
> ".git/modules/sub", except that:
> 
>  - it hides the implementation detail of the exact location of the
>submodule repository from the publicly visible configuration file
> 
>  - it also works with bare remotes (where the actual remote submodule
>location would be URL/modules/sub)
> 
>  - it allows multiple simultaneous superproject remotes (where
>git-submodule currently always resolves relative urls against
>branch.$branch.remote with no option to fetch from a different
>remote).

Maybe it's too late on a Friday evening in my timezone, but currently
I can't wrap my mind around what you have in mind here ... will try
again later.

> * Submodule discovery across all refs
> 
> This is what Jens already mentioned. If we fetch multiple refs of a
> remote superproject, we also need to fetch _all_ of the submodules
> referenced by _any_ of the refs, not just the ones in the currently
> active branch.

That is how things already work now (and it is done in an optimized
way because we only do a fetch in a submodule when the referenced
commit isn't already present locally). But the current limitation
is that only populated submodules are updated (we do a "git fetch"
inside the submodules work tree), so e.g. currently we can't follow
renames. We should also do a fetch for submodules which aren't
checked out but whose repo is found in .git/modules/.

> Finding the complete list of submodules probably has to
> be implemented by reading .gitmodules in all of the (updated) refs,
> which is a bit ugly, but not too bad.

Yes, this will be necessary to get the correct path -> name mapping
for submodules which aren't found in the work tree (e.g. because
they are renamed). (I will also need to peek into another commit's
.gitmodules file to make the recursive checkout work for appearing
submodules for the same reason)

> * Recording the active branch of a submodule
> 
> When a submodule is added, its active branch should be stored in
> .gitmodules as submodule.$sub.branch. Then, when the submodule is
> checked out, and the head of that branch is the same as the commit in
> the gitlink (i.e. the superproject tree is "current"), then that branch
> is set as the active branch in the checked-out submodule working tree.
> Otherwise, a detached head is used.

We had some discussions about a "floating" submodule model where the
submodules follow the tip of a branch configured in .gitmodules. That
looked similar to what you have in mind, except that the tip of that
branch is always used.

> * Multiple working trees for a submodule
> 
> A superproject may have multiple paths for the same submodule,
> presumably for different commits. This is for cases where the
> superproject is a snapshot of a developer's directory hierarchy, and the
> developer is simultaneously working on multiple branches of a submodule
> and it is convenient to have separate working trees for each of them.
> 
> This is a bit hard to express with the current .gitconfig format, since
> paths are attributes of repository ids instead of vice versa. I'd
> introduce an alternative section format where you can say:
> 
> [mount "path1"]
>   module = sub
>   branch = master
> 
> [mount "path2"]
>   module = sub
>   branch = topic
> 
> Implementing this is a bit intricate, since we need to use the
> git-new-workdir method to create multiple working directories that share
> the sa

Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes

[Junio C Hamano]

Junio C Hamano  writes:

> As long as what it does is explained in format-patch, that is fine.
>
> I do not think this deserves to be in the SubmittingPatches.  We do
> tell people to hide "here is the context of the change" additional
> explanation after three dashes, but how the submitters prepare that
> text is entirely up to them (and I personally do not think notes is
> not necessarily the right tool to do so).

Just in case, here is what I'll queue as a placeholder on 'pu'.

-- >8 --
Subject: [PATCH] Documentation: decribe format-patch --notes

Even though I coded this, I am not sure what use scenarios would benefit
from this option, so the description is unnecessarily negative at this
moment. People who do want to use this feature need to come up with a
more plausible use case and replace it.

Signed-off-by: Junio C Hamano 
---
 Documentation/git-format-patch.txt | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-format-patch.txt 
b/Documentation/git-format-patch.txt
index 6d43f56..066dc8b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -20,7 +20,7 @@ SYNOPSIS
   [--ignore-if-in-upstream]
   [--subject-prefix=Subject-Prefix]
   [--to=] [--cc=]
-  [--cover-letter] [--quiet]
+  [--cover-letter] [--quiet] [--notes[=]]
   []
   [  |  ]
 
@@ -191,6 +191,19 @@ will want to ensure that threading is disabled for `git 
send-email`.
containing the shortlog and the overall diffstat.  You can
fill in a description in the file before sending it out.
 
+--notes[=]::
+   Append the notes (see linkgit:git-notes[1]) for the commit
+   after the three-dash line.
++
+The expected use case of this is to write supporting explanation for
+the commit that does not belong to the commit log message proper
+when (or after) you create the commit, and include it in your patch
+submission.  But if you can plan ahead and write it down, there may
+not be a good reason not to write it in your commit message, and if
+you can't, you can always edit the output of format-patch before
+sending it out, so the practical value of this option is somewhat
+dubious, unless your workflow is broken.
+
 --[no]-signature=::
Add a signature to each message produced. Per RFC 3676 the signature
is separated from the body by a line with '-- ' on it. If the
-- 
1.8.0.rc3.162.g1f53438

--
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] Cache stat_tracking_info() for faster status and branch -v

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> stat_tracking_info() is used to calculated how many commits ahead or
> behind for a branch. Rev walking can be slow especially when the
> branch is way behind its remote end. By caching the results, we won't
> have to rev walk every time we need these information.
> stat_tracking_info() cost can be greatly reduced this way.
>
> This makes sure "git status" instant no matter how far behind HEAD
> is, except the first time after HEAD changes. This also makes
> "branch -v" usable (for me) as it's now also instant versus 3.5
> seconds in non-cache case on my machine.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  I wanted guaranteed-fast status for another reason, but it turns out
>  "branch -v" benefits even more. Recent commit walking is not
>  efficiently optimized even with Shawn's pack bitmaps. This may be
>  useful some people, I guess.

Not particularly interested in the cause, but not so strongly
against it to veto it.

The design looks questionable.

You can fork one or more branches off of a single branch.  You may
fork your 'frotz' branch off of remotes/origin/master but also
another 'xyzzy' branch may be forked from the same.

I understand that you are trying to optimize, given two commit
object names X and Y, the cost to learn the symmetric distances
between them.

Doesn't it make more sense to use a notes-cache that is keyed off of
the commit object name X of the remote?  You will have a single note
that stores a blob for the commit object remotes/origin/master, and
the blob tells you how far the commit at the tip of 'frotz' is from
it, and the same for 'xyzzy'.

You would obviouly need to run "gc" on such a notes-cache tree from
time to time, removing notes for commits that are not tip of any
branch that could be a fork point, and from the remaining notes
blobs, entries that describe commits that are not tip of any branch,
if you go that route.

>
>  remote.c | 42 ++
>  1 file changed, 42 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index 04fd9ea..db825b8 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1549,6 +1549,7 @@ int stat_tracking_info(struct branch *branch, int 
> *num_ours, int *num_theirs)
>   struct rev_info revs;
>   const char *rev_argv[10], *base;
>   int rev_argc;
> + int fd;
>  
>   /*
>* Nothing to report unless we are marked to build on top of
> @@ -1579,6 +1580,33 @@ int stat_tracking_info(struct branch *branch, int 
> *num_ours, int *num_theirs)
>   if (theirs == ours)
>   return 0;
>  
> + if (!access(git_path("stat_tracking_cache/%s",
> +  branch->refname), R_OK)) {
> + struct strbuf sb = STRBUF_INIT;
> + unsigned char sha1_ours[20], sha1_theirs[20];
> + int n1, n2;
> + if ((fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> +O_RDONLY)) != -1 &&
> + strbuf_read(&sb, fd, 0) != -1 &&
> + sb.len > (40 + 1) * 2 &&
> + !get_sha1_hex(sb.buf, sha1_ours) &&
> + sb.buf[40] == '\n' &&
> + !get_sha1_hex(sb.buf + 41, sha1_theirs) &&
> + sb.buf[81] == '\n' &&
> + !hashcmp(sha1_ours, ours->object.sha1) &&
> + !hashcmp(sha1_theirs, theirs->object.sha1) &&
> + sscanf(sb.buf + 82, "%d\n%d\n", &n1, &n2) == 2) {
> + *num_ours = n1;
> + *num_theirs = n2;
> + close(fd);
> + strbuf_release(&sb);
> + return 1;
> + }
> + close(fd);
> + strbuf_release(&sb);
> + }
> +
>   /* Run "rev-list --left-right ours...theirs" internally... */
>   rev_argc = 0;
>   rev_argv[rev_argc++] = NULL;
> @@ -1608,6 +1636,20 @@ int stat_tracking_info(struct branch *branch, int 
> *num_ours, int *num_theirs)
>   (*num_theirs)++;
>   }
>  
> + if (!safe_create_leading_directories(git_path("stat_tracking_cache/%s",
> +   branch->refname)) &&
> + (fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> +O_CREAT | O_TRUNC | O_RDWR, 0644)) != -1) {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(ours->object.sha1));
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(theirs->object.sha1));
> + strbuf_addf(&sb, "%d\n%d\n", *num_ours, *num_theirs);
> + write(fd, sb.buf, sb.len);
> + strbuf_release(&sb);
> + close(fd);
> + }
> +
>   /* clear object flags smudged by the above traversal */
>   clear_commit_marks(ours, ALL_REV_FLAGS);
>   clear_commit_marks(theirs, ALL_REV_FLAGS);
--
To unsubscribe from

Re: [msysGit] Re: Git for Windows and line endings

[Junio C Hamano]

Chris B  writes:

> - If there was SO MUCH thought into this, then it was too much...

I do not have much to add to what area experts already said on bits
specific to Git for Windows, but on just this part:

> - Our builds were not breaking, it was production due to deployment
> model utilizing Git. What if there was a process to extract from Git
> and then distribute?

Do you mean something like "git archive"?  Or do you have something
else in mind?

> - Developers are not expecting revision control system to make changes
> to files they commit.

But isn't there a distinction between the logical content and its
physical representation?  In source code (that is what developers
use a source code management system for), especially those of
cross-platform projects, the logical lines end with LF and physical
lines end with whatever is convenient on the platform of each
participant of the project.  There needs a way to convert between
the two.

It does not sound fair to call it a crime if the port to a platform,
whose users (at least the majority of them) expect the latter to be
CRLF, chose to default to that to help the majority, as long as
there are ways for the minority power users to choose to use LF in
the physical representation on their working trees.
--
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: Fix potential hang in https handshake.

[Daniel Stenberg]

On Fri, 19 Oct 2012, Shawn Pearce wrote:

The issue with the current code is sometimes when libcurl is opening a 
CONNECT style connection through an HTTP proxy it returns a crazy high 
timeout (>240 seconds) and no fds. In this case Git waits forever.


Is this repeatable with a recent libcurl? It certainly sounds like a bug to 
me, and I might be interested in giving a try at tracking it down...


--

 / 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

[PATCH] tree-walk: use enum interesting instead of integer

[Nguyễn Thái Ngọc Duy]

Commit d688cf0 (tree_entry_interesting(): give meaningful names to
return values - 2011-10-24) converts most of the tree_entry_interesting
values to the new enum, except "never_interesting". This completes the
conversion.
---
 tree-walk.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tree-walk.c b/tree-walk.c
index 0e49299..42fe610 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -490,11 +490,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const 
char *name, unsigned ch
 
 static int match_entry(const struct name_entry *entry, int pathlen,
   const char *match, int matchlen,
-  int *never_interesting)
+  enum interesting *never_interesting)
 {
int m = -1; /* signals that we haven't called strncmp() */
 
-   if (*never_interesting) {
+   if (*never_interesting != entry_not_interesting) {
/*
 * We have not seen any match that sorts later
 * than the current path.
@@ -522,7 +522,7 @@ static int match_entry(const struct name_entry *entry, int 
pathlen,
 * the variable to -1 and that is what will be
 * returned, allowing the caller to terminate early.
 */
-   *never_interesting = 0;
+   *never_interesting = entry_not_interesting;
}
 
if (pathlen > matchlen)
@@ -584,7 +584,7 @@ enum interesting tree_entry_interesting(const struct 
name_entry *entry,
 {
int i;
int pathlen, baselen = base->len - base_offset;
-   int never_interesting = ps->has_wildcard ?
+   enum interesting never_interesting = ps->has_wildcard ?
entry_not_interesting : all_entries_not_interesting;
 
if (!ps->nr) {
-- 
1.8.0.rc2.22.gad9383a

--
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: Fix potential hang in https handshake.

[Junio C Hamano]

Stefan Zager  writes:

> On Oct 19, 2012 7:11 AM, "Shawn Pearce"  wrote:
>>
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Correct.  Anecdotally, the zero-file-descriptor situation happens only once
> per process invocation, so the risk of passing a too-long timeout to
> select() is small.

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: Unexpected directories from read-tree

[Uri Moszkowicz]

I am using 1.8.0-rc2 but also tried 1.7.8.4. Thanks for the suggestion
to use "ls-files -t" - that's exactly what I was looking for. With
that I was easily able to tell what the problem is: missing "/" from
the sparse-checkout file.

On Thu, Oct 18, 2012 at 10:34 PM, Nguyen Thai Ngoc Duy
 wrote:
> On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz  wrote:
>> I'm testing out the sparse checkout feature of Git on my large (14GB)
>> repository and am running into a problem. When I add "dir1/" to
>> sparse-checkout and then run "git read-tree -mu HEAD" I see dir1 as
>> expected. But when I add "dir2/" to sparse-checkout and read-tree
>> again I see dir2 and dir3 appear and they're not nested. If I replace
>> "dir2/" with "dir3/" in the sparse-checkout file, then I see dir1 and
>> dir3 but not dir2 as expected again. How can I debug this problem?
>
> Posting here is step 1. What version are you using? You can look at
> unpack-trees.c The function that does the check is excluded_from_list.
> You should check "ls-files -t", see if CE_SKIP_WORKTREE is set
> correctly for all dir1/*, dir2/* and dir3/*. Can you recreate a
> minimal test case for the problem?
> --
> 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

Re: [msysGit] Re: Git for Windows and line endings

[Chris B]

Hi.  I'm sorry about the tone of the email; I was writing it after
spending a lot of energy fixing things up and I should have taken some
time to breathe. I recognize this is likely not going to change and
even if I could jump in to contribute it wouldn't matter. I also
recognize that changing it now might cause more problems. I am hopeful
though.

I would like to point out:
- Git on Linux does not mess around with line endings. I can create
and edit a file in either line ending on Linux and commit and still
have it untouched.
- Git on Windows via Cygwin also does not mess around.
- If those flavors of Git don't mess around, why should msysgit do it?

- Windows has been able to cope with UNIX line endings a long time; no
developer is using a default Notepad to open files with high
expectations. Any Windows development tool and editor worth anything
I've used is able to handle both just fine.
- VIM also handles Windows line endings just fine as well. I just
tested it on a Linux machine. Maybe old version? (pure VI is not even
on this machine but hard to press these days it can't handle it.)
- The files in .git folder are in UNIX format anyway, so why are those
not also included in line ending changes? Isn't is because there is a
Windows app (msysgit) running on Windows that expects the UNIX line
ending? So in the same manor, someone might have a Windows system
using some Cygwin components perhaps, or a Windows C program possibly
poorly written or just old, that demand some text files to be left
alone in the format we saved it.

- If there was SO MUCH thought into this, then it was too much; it was
the wrong thought. There should not have been much at all, and just
allow Git to do what it does: store things *exactly* as you put it in.
Allow the clients to worry about things like line endings should they
have the need to worry about it. I'm not seeing how the revision
system has any business making alterations to things one commits into
it.

- Our builds were not breaking, it was production due to deployment
model utilizing Git. What if there was a process to extract from Git
and then distribute? Sounds like it's simple and should work and there
are good advantages to this process to overcome speed of deployment
issues. That process is free to be either Linux or Windows, and to
distribute to either a Linux or Windows server. This process you may
consider a mistake, but the point is that Git is just storing things,
not worried about the process in which it is used.

- While there might be options to make the other flavors of Git mess
around with line endings, the default is to not touch it which is
critical. Because as you bring on developers you never know what they
selected during the installation, and you have to go back and have
them change it if they did something different.

- Developers are not expecting revision control system to make changes
to files they commit.
--
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: Fix potential hang in https handshake.

[Shawn Pearce]

On Fri, Oct 19, 2012 at 3:36 AM, Jeff King  wrote:
> On Thu, Oct 18, 2012 at 03:59:41PM -0700, Junio C Hamano wrote:
>
>> > It will sometimes happen that curl_multi_fdset() doesn't
>> > return any file descriptors.  In that case, it's recommended
>> > that the application sleep for a short time before running
>> > curl_multi_perform() again.
>> >
>> > http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
>> >
>> > Signed-off-by: Stefan Zager 
>> > ---
>>
>> Thanks.  Would it be a better idea to "patch up" in problematic
>> case, instead of making this logic too deeply nested, like this
>> instead, I have to wonder...
>>
>>
>>   ... all the existing code above unchanged ...
>>   curl_multi_fdset(..., &max_fd);
>> + if (max_fd < 0) {
>> + /* nothing actionable??? */
>> + select_timeout.tv_sec = 0;
>> + select_timeout.tv_usec = 5;
>> + }
>>
>>   select(max_fd+1, ..., &select_timeout);
>
> But wouldn't that override a potentially shorter timeout that curl gave
> us via curl_multi_timeout, making us unnecessarily slow to hand control
> back to curl?
>
> The current logic is:
>
>   - if curl says there is something to do now (timeout == 0), do it
> immediately
>
>   - if curl gives us a timeout, use it with select
>
>   - otherwise, feed 50ms to selection
>
> It should not matter what we get from curl_multi_fdset. If there are
> fds, great, we will feed them to select with the timeout, and we may
> break out early if there is work to do. If not, then we are already
> doing this wait.
>
> IOW, it seems like we are _already_ following the advice referenced in
> curl's manpage. Is there some case I am missing? Confused...

The issue with the current code is sometimes when libcurl is opening a
CONNECT style connection through an HTTP proxy it returns a crazy high
timeout (>240 seconds) and no fds. In this case Git waits forever.
Stefan observed that using a timeout of 50 ms in this situation to
poll libcurl is better, as it figures out a lot more quickly that it
is connected to the proxy and can issue the request.
--
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 0/2] gitk: fix --full-diff handling

[Felipe Contreras]

On Fri, Oct 19, 2012 at 3:12 PM, Johannes Sixt  wrote:
> Am 10/19/2012 12:56, schrieb Felipe Contreras:
>> I find usel to do 'git log --full-duff -- file' to find out all the commits
>> that touched the file, and show the full diff (not just the one of the file).
>>
>> Unfortunately gitk doesn't honour this option; the diff is limited in the UI.
>
> There is Edit->Preferences->General->Limit diff to listed paths. Doesn't
> it do what you want if you switch it off?

Hmm, I guess so, but it's not triggered from the command line. Maybe
the --full-diff option should enable that flag.

-- 
Felipe Contreras
--
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

[DOCBUG] git subtree synopsis needs updating

[Yann Dirson]

As the examples in git-subtree.txt show, the synopsis in the same file should
surely get a patch along the lines of:

-'git subtree' add   -P  
+'git subtree' add   -P   

Failure to specify the repository (by just specifying a local commit) fails with
the cryptic:

 warning: read-tree: emptying the index with no arguments is deprecated; use 
--empty
 fatal: just how do you expect me to merge 0 trees?


Furthermore, the doc paragraph for add, aside from mentionning , 
also
mentions a  which the synopsis does not show either.


As a sidenote it someone wants to do some maintainance, using "." as repository 
when
the branch to subtree-add is already locally available does not work well either
(fails with "could not find ref myremote/myhead").

-- 
Yann Dirson - Bertin Technologies
--
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 0/2] gitk: fix --full-diff handling

[Johannes Sixt]

Am 10/19/2012 12:56, schrieb Felipe Contreras:
> I find usel to do 'git log --full-duff -- file' to find out all the commits
> that touched the file, and show the full diff (not just the one of the file).
> 
> Unfortunately gitk doesn't honour this option; the diff is limited in the UI.

There is Edit->Preferences->General->Limit diff to listed paths. Doesn't
it do what you want if you switch it off?

-- 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

[PATCH 2/2] gitk: handle --full-diff correctly

[Felipe Contreras]

Otherwise the files are missing from the diff, and the list of files.

Signed-off-by: Felipe Contreras 
---
 gitk-git/gitk | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index b79dfdf..8109eed 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -155,7 +155,7 @@ proc unmerged_files {files} {
 }
 
 proc parseviewargs {n arglist} {
-global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs 
vfileargs env
 global worddiff git_version
 
 set vdatemode($n) 0
@@ -165,6 +165,7 @@ proc parseviewargs {n arglist} {
 set nextisval 0
 set revargs {}
 set origargs $arglist
+set fileargs {}
 set allknown 1
 set filtered 0
 set i -1
@@ -187,7 +188,7 @@ proc parseviewargs {n arglist} {
"--no-renames" - "--full-index" - "--binary" - "--abbrev=*" -
"--find-copies-harder" - "-l*" - "--ext-diff" - "--no-ext-diff" -
"--src-prefix=*" - "--dst-prefix=*" - "--no-prefix" -
-   "-O*" - "--text" - "--full-diff" - "--ignore-space-at-eol" -
+   "-O*" - "--text" - "--ignore-space-at-eol" -
"--ignore-space-change" - "-U*" - "--unified=*" {
# These request or affect diff output, which we don't want.
# Some could be used to set our defaults for diff display.
@@ -233,6 +234,9 @@ proc parseviewargs {n arglist} {
set filtered 1
lappend glflags $arg
}
+   "--full-diff" {
+   lappend fileargs $arg
+   }
"-n" {
# This appears to be the only one that has a value as a
# separate word following it
@@ -276,6 +280,7 @@ proc parseviewargs {n arglist} {
 set vrevs($n) $revargs
 set vfiltered($n) $filtered
 set vorigargs($n) $origargs
+set vfileargs($n) $fileargs
 return $allknown
 }
 
@@ -7519,10 +7524,11 @@ proc diffcmd {ids flags} {
 }
 
 proc gettreediffs {ids} {
-global treediff treepending limitdiffs vfilelimit curview
+global treediff treepending limitdiffs vfilelimit vfileargs curview
 
 set cmd [diffcmd $ids {--no-commit-id}]
 if {$limitdiffs && $vfilelimit($curview) ne {}} {
+   set cmd [concat $cmd $vfileargs($curview)]
set cmd [concat $cmd -- $vfilelimit($curview)]
 }
 if {[catch {set gdtf [open $cmd r]}]} return
@@ -7613,7 +7619,7 @@ proc getblobdiffs {ids} {
 global diffcontext
 global ignorespace
 global worddiff
-global limitdiffs vfilelimit curview
+global limitdiffs vfilelimit vfileargs curview
 global diffencoding targetline diffnparents
 global git_version currdiffsubmod
 
@@ -7633,6 +7639,7 @@ proc getblobdiffs {ids} {
append cmd " --word-diff=porcelain"
 }
 if {$limitdiffs && $vfilelimit($curview) ne {}} {
+   set cmd [concat $cmd $vfileargs($curview)]
set cmd [concat $cmd -- $vfilelimit($curview)]
 }
 if {[catch {set bdf [open $cmd r]} err]} {
-- 
1.8.0.rc2.7.g0961fdf.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

[PATCH 1/2] gitk: simplify file filtering

[Felipe Contreras]

git diff is perfectly able to do this with '-- files', no need for
manual filtering.

Signed-off-by: Felipe Contreras 
---
 gitk-git/gitk | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..b79dfdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7519,9 +7519,13 @@ proc diffcmd {ids flags} {
 }
 
 proc gettreediffs {ids} {
-global treediff treepending
+global treediff treepending limitdiffs vfilelimit curview
 
-if {[catch {set gdtf [open [diffcmd $ids {--no-commit-id}] r]}]} return
+set cmd [diffcmd $ids {--no-commit-id}]
+if {$limitdiffs && $vfilelimit($curview) ne {}} {
+   set cmd [concat $cmd -- $vfilelimit($curview)]
+}
+if {[catch {set gdtf [open $cmd r]}]} return
 
 set treepending $ids
 set treediff {}
@@ -7565,17 +7569,7 @@ proc gettreediffline {gdtf ids} {
return [expr {$nr >= $max? 2: 1}]
 }
 close $gdtf
-if {$limitdiffs && $vfilelimit($curview) ne {}} {
-   set flist {}
-   foreach f $treediff {
-   if {[path_filter $vfilelimit($curview) $f]} {
-   lappend flist $f
-   }
-   }
-   set treediffs($ids) $flist
-} else {
-   set treediffs($ids) $treediff
-}
+set treediffs($ids) $treediff
 unset treepending
 if {$cmitmode eq "tree" && [llength $diffids] == 1} {
gettree $diffids
-- 
1.8.0.rc2.7.g0961fdf.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

[PATCH 0/2] gitk: fix --full-diff handling

[Felipe Contreras]

Hi,

I find usel to do 'git log --full-duff -- file' to find out all the commits
that touched the file, and show the full diff (not just the one of the file).

Unfortunately gitk doesn't honour this option; the diff is limited in the UI.

The following patches fix that.

Felipe Contreras (2):
  gitk: simplify file filtering
  gitk: handle --full-diff correctly

 gitk-git/gitk | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

-- 
1.8.0.rc2.7.g0961fdf.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: Fix potential hang in https handshake.

[Jeff King]

On Thu, Oct 18, 2012 at 03:59:41PM -0700, Junio C Hamano wrote:

> > It will sometimes happen that curl_multi_fdset() doesn't
> > return any file descriptors.  In that case, it's recommended
> > that the application sleep for a short time before running
> > curl_multi_perform() again.
> >
> > http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
> >
> > Signed-off-by: Stefan Zager 
> > ---
> 
> Thanks.  Would it be a better idea to "patch up" in problematic
> case, instead of making this logic too deeply nested, like this
> instead, I have to wonder...
> 
> 
>   ... all the existing code above unchanged ...
>   curl_multi_fdset(..., &max_fd);
> + if (max_fd < 0) {
> + /* nothing actionable??? */
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 5;
> + }
> 
>   select(max_fd+1, ..., &select_timeout);

But wouldn't that override a potentially shorter timeout that curl gave
us via curl_multi_timeout, making us unnecessarily slow to hand control
back to curl?

The current logic is:

  - if curl says there is something to do now (timeout == 0), do it
immediately

  - if curl gives us a timeout, use it with select

  - otherwise, feed 50ms to selection

It should not matter what we get from curl_multi_fdset. If there are
fds, great, we will feed them to select with the timeout, and we may
break out early if there is work to do. If not, then we are already
doing this wait.

IOW, it seems like we are _already_ following the advice referenced in
curl's manpage. Is there some case I am missing? Confused...

-Peff
--
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