Re: [PATCH] Retry HTTP requests on SSL connect failures

[Shawn Pearce]

On Mon, Oct 1, 2012 at 3:18 PM, Jeff King  wrote:
> On Mon, Oct 01, 2012 at 02:23:06PM -0700, Shawn O. Pearce wrote:
>>
>> When libcurl fails to connect to an SSL server always retry the
>> request once. Since the connection failed before the HTTP headers
>> can be sent, no data has exchanged hands, so the remote side has
>> not learned of the request and will not perform it twice.
>
> I find this a little distasteful just because we haven't figured out the
> actual _reason_ for the failure. That is, I'm not convinced this isn't
> something that curl or the ssl library can't handle internally if we
> would only configure them correctly. Did you ever follow up on tweaking
> the session caching options for curl?

No. I didn't try because I reproduced the issue on the initial "GET
/.../info/refs?service=git-upload-pack" request with no authentication
required. So the very first thing the remote-https process did was
fail on an SSL error. During this run I was using a patched Git that
had a different version of the retry logic, but it immediately retried
and the retry was successful. At that point I decided the SSL session
cache wasn't possibly relevant since the first request failed and the
immediate retry was OK.

> Have you tried running your fails-after-a-few-hours request with other
> clients that don't have the problem and seeing what they do

This is harder to reproduce than you think. It took me about 5 days of
continuous polling to reproduce the error. And I have thus far only
reproduced it against our production servers. This makes it very hard
to test anything. Or to prove that any given patch is better than a
different version.

> (I'm
> thinking a small webkit harness or something would be the most
> feasible)?

So I suspect the contrib/persistent-https proxy thing in Go actually
papers over this problem by having the Go SSL client handle the
connection. But this is only based on a test I ran for several days
through that proxy that did not reproduce the bug. This doesn't mean
it doesn't reproduce with the proxy, it just means _I_ didn't get
lucky with an error in a ~48 hour run.

> which means it shouldn't really be affecting the general populace. So
> even though it feels like a dirty hack, at least it is self-contained,
> and it does fix a real-world problem. If your answer to the above
> questions is "hunting this further is just not worth the effort", I can
> live with that.

I am sort of at that point, but the hack is so ugly... yea, we
shouldn't have to do this. Or pollute our code with it. I'm willing to
go back and iterate on this further, but its going to be a while
before I can provide any more information.

>> diff --git a/remote-curl.c b/remote-curl.c
>> index a269608..04a379c 100644
>> --- a/remote-curl.c
>> +++ b/remote-curl.c
>> @@ -353,6 +353,8 @@ static int run_slot(struct active_request_slot *slot)
>>
>>   slot->results = &results;
>>   slot->curl_result = curl_easy_perform(slot->curl);
>> + if (slot->curl_result == CURLE_SSL_CONNECT_ERROR)
>> + slot->curl_result = curl_easy_perform(slot->curl);
>>   finish_active_slot(slot);
>
> How come the first hunk gets a nice for-loop and this one doesn't?

Both hunks retry exactly once after an SSL connect error. I just tried
to pick something reasonably clean to implement. This hunk seemed
simple with the if, the other was uglier and a loop seemed the most
simple way to get a retry in there.

> Also, are these hunks the only two spots where this error can come up?
> The first one does http_request, which handles smart-http GET requests.
> the second does run_slot, which handles smart-http POST requests.

Grrr. I thought I caught all of the curl perform calls but I guess I
missed the dumb transport.

> Some of the dumb http fetches will go through http_request. But some
> will not. And I think almost none of dumb http push will.

Well, don't use those? :-)
--
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

push.default documented in "man git-push"?

[David Glasser]

Is the newish push.default documented in the "git push" manpage
anywhere? I don't see it mentioned (and there are several references
to the "default" behavior), but maybe I'm missing something. Is it
left out on purpose (ie, config values aren't supposed to be mentioned
in command manpages)?

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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] Retry HTTP requests on SSL connect failures

[Drew Northup]

On Mon, Oct 1, 2012 at 5:23 PM, Shawn O. Pearce  wrote:
> From: "Shawn O. Pearce" 
>
> When libcurl fails to connect to an SSL server always retry the
> request once. Since the connection failed before the HTTP headers
> can be sent, no data has exchanged hands, so the remote side has
> not learned of the request and will not perform it twice.
>
> In the wild we have seen git-remote-https fail to connect to
> some load-balanced SSL servers sporadically, while modern popular
> browsers (e.g. Firefox and Chromium) have no trouble with the same
> server pool.
>
> Lets assume the site operators (Hi Google!) have a clue and are
> doing everything they already can to ensure secure, successful
> SSL connections from a wide range of HTTP clients. Implementing a
> single level of retry in the client can make it more robust against
> transient failure modes.

Ok, this begs for some background info...
@Dayjob one of the many things I do is mange our load balancers
(redundant pair in our case). If the attempted SSL connections in one
"bin" (time-slot) exceeds the licensed size of that "bin" then the
excess attempts are just "dropped on the floor." Normal web browsers
detect this initial failure and try again. This may be implemented
internally—I haven't checked.

Google, as I am sure you are well aware, doesn't rely upon a
traditional L2/L3 network level load balancing architecture.
Therefore, I would not attempt to argue that the results that apply to
their systems would apply much of anywhere else. (They have done
presentations publicly, which are archived on the 'net, about how they
do things.)

-- 
-Drew Northup
--
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
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] Retry HTTP requests on SSL connect failures

[Junio C Hamano]

Jeff King  writes:

> On Mon, Oct 01, 2012 at 02:53:17PM -0700, Junio C Hamano wrote:
>
>> "Shawn O. Pearce"  writes:
>> 
>> > +  for (attempts = 0; attempts < 2; attempts++) {
>> > +  if (start_active_slot(slot)) {
>> > +  run_active_slot(slot);
>> > +  if (slot->results->curl_result == 
>> > CURLE_SSL_CONNECT_ERROR)
>> > +  continue;
>> 
>> Is it safe to continue and let start_active_slot() to add the same
>> curl handle again when USE_CURL_MULTI is in effect?
>
> I _think_ so. 

It seems that at the beginning of curl_multi_add_handle() there is a
check to see if the incoming slot->curl has already been added to
some curl-multi-handle and the function would return an error code
CURLM_BAD_EASY_HANDLE without doing anything useful.  Doesn't the
second attempt to call start_active_slot() set the slot->in_use to
zero and return false, skipping the call to run_active_slot() in
that case?
--
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] gitk: refresh the index before running diff-files

[Junio C Hamano]

Jeff King  writes:

> I don't buy the "gitk should be read-only" argument from that thread. I
> think we decided a while back[1] that the stat cache is not really a
> user-visible modification; you're not updating the index in any
> meaningful way that impacts the user's workflow, but merely refreshing
> our cache of what is in the filesystem.

I think it is OK as long as a failure to "update-index --refresh"
does not lead to a user-visible error (I think we made sure that the
the opportunistic refresh "git diff" and "git status" does won't
report an error, when you are trying to help your co-worker by
visiting her repository and running these commands, only to peek).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] Git v1.8.0-rc0

[Junio C Hamano]

A release candidate Git v1.8.0-rc0 is now available for testing at
the usual places.  There are a couple of leftover features we might
merge before the final release, but other than that, this is meant
to be more or less feature-complete preview of the upcoming 1.8.0.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

a5143163b9d17e1afd7e66d7c6e7457c2e09a022  git-1.8.0.rc0.tar.gz
679891dad4b0168ddd618c1de05978e35189c1bf  git-htmldocs-1.8.0.rc0.tar.gz
eab59abd44a941e382eca6ae5e1d357b337328d0  git-manpages-1.8.0.rc0.tar.gz

Also the following public repositories all have a copy of the v1.8.0-rc0
tag and the master branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v1.8.0 Release Notes (draft)


Backward compatibility notes


In the next major release, we will change the behaviour of the "git
push" command.  When "git push [$there]" does not say what to push, we
have used the traditional "matching" semantics (all your branches were
sent to the remote as long as there already are branches of the same
name over there).  We will use the "simple" semantics, that pushes the
current branch to the branch with the same name only when the current
branch is set to integrate with that remote branch.  There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable.

"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future.  "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments.


Updates since v1.7.12
-

UI, Workflows & Features

 * A credential helper for Win32 to allow access to the keychain of
   the logged-in user has been added.

 * An initial port to HP NonStop.

 * A credential helper to allow access to the Gnome keyring has been
   added.

 * When "git am" sanitizes the Subject: line, we strip the prefix from
   "Re: subject" and also from a less common "re: subject", but left
   even less common "RE: subject" intact.

 * It was tempting to say "git branch --set-upstream origin/master",
   but that tells Git to arrange the local branch "origin/master" to
   integrate with the currently checked out branch, which is highly
   unlikely what the user meant.  The option is deprecated; use the
   new "--set-upstream-to" (with a short-and-sweet "-u") option
   instead.

 * "git cherry-pick" learned the "--allow-empty-message" option to
   allow it to replay a commit without any log message.

 * After "git cherry-pick -s" gave control back to the user asking
   help to resolve conflicts, concluding "git commit" used to need to
   be run with "-s" if the user wants to sign it off; now the command
   leaves the sign-off line in the log template.

 * "git daemon" learned the "--access-hook" option to allow an
   external command to decline service based on the client address,
   repository path, etc.

 * "git difftool --dir-diff" learned to use symbolic links to prepare
   temporary copy of the working tree when available.

 * "git grep" learned to use a non-standard pattern type by default if
   a configuration variable tells it to.

 * "git merge-base" learned "--is-ancestor A B" option to tell if A is
   an ancestor of B.  The result is indicated by its exit status code.

 * "git mergetool" allows users to override the actual command used
   with the mergetool.$name.cmd configuration variable even for built-in
   mergetool backends.

 * The "-Xours" backend option to "git merge -s recursive" now takes
   effect even on binary files.

 * "git rebase -i" learned the "--edit-todo" option to open an editor
   to edit the insn sheet.


Foreign Interface

 * "git svn" has been updated to work with SVN 1.7.

 * "git p4" learned "--conflicts" option to specify what to do when
   encountering a conflict during "p4 submit".


Performance, Internal Implementation, etc. (please report possible regressions)

 * Git ships with a fall-back regexp implementation for platforms with
   buggy regexp library, but it was easy for people to keep using their
   platform regexp.  A new test has been added to check this.

 * The "check-docs" build target has been updated and greatly
   simplified.

 * The test suite is run under MALLOC_CHECK_ when running with glibc
   that supports the feature.

 * The documentation in the TeXinfo format was using indented output
   for materials meant to be examples that are better typeset in
   monospace.

 * Compatibility wrapper around some mkdir(2) implementations that
   reject parameter with trailing slash has been introduced.

 * Compatibility wrapper for systems that lac

Re: [PATCH] gitk: refresh the index before running diff-files

[Jeff King]

On Sun, Sep 30, 2012 at 01:34:58PM -0700, Jonathan Nieder wrote:

> Jeff King wrote:
> > On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:
> 
> >> Unfortunately this will wait for the git update-index command to
> >> complete, making the GUI unresponsive while it executes, and that can
> >> take minutes on a large repository (e.g. the linux kernel) on a
> >> machine with a slow disk and a cold disk cache.  We will need to make
> >> the git update-index execute asynchronously.
> >
> > Good point. We're getting out of my very limited tcl cargo-culting
> > skills now, so I'll let somebody more clueful do that fix.
> 
> You might find the following patch and discussion entertaining:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/144182
> 
> Not my itch, but it was fun to write back then. ;-)

Not really my itch either, which is why I'm trying to dump the tcl work
on somebody else. :) For what it's worth, your patch from that thread
looks like a sane approach.

I don't buy the "gitk should be read-only" argument from that thread. I
think we decided a while back[1] that the stat cache is not really a
user-visible modification; you're not updating the index in any
meaningful way that impacts the user's workflow, but merely refreshing
our cache of what is in the filesystem.  That may have performance
implications (which is why we do not do it in all commands by default),
but it really is a cache, and updating it should be no different than
updating gitk.cache (i.e., do it if we can, but do not complain if we
are in a read-only repository).

-Peff

[1] I did not track down the threads, but I consider this resolved by
all of the discussion that led to "git diff" refreshing (and saving)
the index rather than printing patch-less stat-dirty entries. The
original argument against refreshing was that the stat-dirtiness was
somehow interesting to users, but I think experience has shown that
people are happy to have it happen magically behind the scenes.
--
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] Retry HTTP requests on SSL connect failures

[Jeff King]

On Mon, Oct 01, 2012 at 02:53:17PM -0700, Junio C Hamano wrote:

> "Shawn O. Pearce"  writes:
> 
> > +   for (attempts = 0; attempts < 2; attempts++) {
> > +   if (start_active_slot(slot)) {
> > +   run_active_slot(slot);
> > +   if (slot->results->curl_result == 
> > CURLE_SSL_CONNECT_ERROR)
> > +   continue;
> 
> Is it safe to continue and let start_active_slot() to add the same
> curl handle again when USE_CURL_MULTI is in effect?

I _think_ so. We reuse the slots anyway. So the usual workflow would be
get_active_slot, then start_active_slot, then run_active_slot. This loop
omits get_active_slot, which is responsible for (re-)initializing a
bunch of aspects of the slot. But we wouldn't want that here, since it
would mean we'd have to set up our URL, callbacks, etc, again.

My only worry would be that the failed curl request actually ended up
writing some data or made some other state change. But since we are
explicitly catching only ssl connection failures, presumably that would
not have happened.

-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: [PATCH] Retry HTTP requests on SSL connect failures

[Jeff King]

On Mon, Oct 01, 2012 at 02:23:06PM -0700, Shawn O. Pearce wrote:

> From: "Shawn O. Pearce" 
> 
> When libcurl fails to connect to an SSL server always retry the
> request once. Since the connection failed before the HTTP headers
> can be sent, no data has exchanged hands, so the remote side has
> not learned of the request and will not perform it twice.
> 
> In the wild we have seen git-remote-https fail to connect to
> some load-balanced SSL servers sporadically, while modern popular
> browsers (e.g. Firefox and Chromium) have no trouble with the same
> server pool.
> 
> Lets assume the site operators (Hi Google!) have a clue and are
> doing everything they already can to ensure secure, successful
> SSL connections from a wide range of HTTP clients. Implementing a
> single level of retry in the client can make it more robust against
> transient failure modes.

I find this a little distasteful just because we haven't figured out the
actual _reason_ for the failure. That is, I'm not convinced this isn't
something that curl or the ssl library can't handle internally if we
would only configure them correctly. Did you ever follow up on tweaking
the session caching options for curl?

Have you tried running your fails-after-a-few-hours request with other
clients that don't have the problem and seeing what they do (I'm
thinking a small webkit harness or something would be the most
feasible)?

That being said, you did make it so that it only kicks in during ssl
connect errors:

> + for (attempts = 0; attempts < 2; attempts++) {
> + if (start_active_slot(slot)) {
> + run_active_slot(slot);
> + if (slot->results->curl_result == 
> CURLE_SSL_CONNECT_ERROR)
> + continue;
> + ret = handle_curl_result(slot);
> + } else {
> + error("Unable to start HTTP request for %s", url);
> + ret = HTTP_START_FAILED;
> + }
> + break;

which means it shouldn't really be affecting the general populace. So
even though it feels like a dirty hack, at least it is self-contained,
and it does fix a real-world problem. If your answer to the above
questions is "hunting this further is just not worth the effort", I can
live with that.

> diff --git a/remote-curl.c b/remote-curl.c
> index a269608..04a379c 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -353,6 +353,8 @@ static int run_slot(struct active_request_slot *slot)
>  
>   slot->results = &results;
>   slot->curl_result = curl_easy_perform(slot->curl);
> + if (slot->curl_result == CURLE_SSL_CONNECT_ERROR)
> + slot->curl_result = curl_easy_perform(slot->curl);
>   finish_active_slot(slot);

How come the first hunk gets a nice for-loop and this one doesn't?

Also, are these hunks the only two spots where this error can come up?
The first one does http_request, which handles smart-http GET requests.
the second does run_slot, which handles smart-http POST requests.

Some of the dumb http fetches will go through http_request. But some
will not. And I think almost none of dumb http push will.

-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: [PATCH] Retry HTTP requests on SSL connect failures

[Junio C Hamano]

"Shawn O. Pearce"  writes:

> + for (attempts = 0; attempts < 2; attempts++) {
> + if (start_active_slot(slot)) {
> + run_active_slot(slot);
> + if (slot->results->curl_result == 
> CURLE_SSL_CONNECT_ERROR)
> + continue;

Is it safe to continue and let start_active_slot() to add the same
curl handle again when USE_CURL_MULTI is in effect?

> + ret = handle_curl_result(slot);
> + } else {
> + error("Unable to start HTTP request for %s", url);
> + ret = HTTP_START_FAILED;
> + }
> + break;
>   }
>  
>   curl_slist_free_all(headers);
> diff --git a/remote-curl.c b/remote-curl.c
> index a269608..04a379c 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -353,6 +353,8 @@ static int run_slot(struct active_request_slot *slot)
>  
>   slot->results = &results;
>   slot->curl_result = curl_easy_perform(slot->curl);
> + if (slot->curl_result == CURLE_SSL_CONNECT_ERROR)
> + slot->curl_result = curl_easy_perform(slot->curl);
>   finish_active_slot(slot);
>  
>   err = handle_curl_result(slot);
--
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] Retry HTTP requests on SSL connect failures

[Junio C Hamano]

"Shawn O. Pearce"  writes:

> Lets assume the site operators (Hi Google!) have a clue and are
> doing everything they already can to ensure secure, successful
> SSL connections from a wide range of HTTP clients. Implementing a
> single level of retry in the client can make it more robust against
> transient failure modes.
> ---

Sign off?

>  http.c| 19 ---
>  remote-curl.c |  2 ++
>  2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/http.c b/http.c
> index 345c171..953f2e6 100644
> --- a/http.c
> +++ b/http.c
> @@ -784,7 +784,7 @@ static int http_request(const char *url, void *result, 
> int target, int options)
>   struct slot_results results;
>   struct curl_slist *headers = NULL;
>   struct strbuf buf = STRBUF_INIT;
> - int ret;
> + int ret, attempts;
>  
>   slot = get_active_slot();
>   slot->results = &results;
> @@ -820,12 +820,17 @@ static int http_request(const char *url, void *result, 
> int target, int options)
>   curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
>   curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "gzip");
>  
> - if (start_active_slot(slot)) {
> - run_active_slot(slot);
> - ret = handle_curl_result(slot);
> - } else {
> - error("Unable to start HTTP request for %s", url);
> - ret = HTTP_START_FAILED;
> + for (attempts = 0; attempts < 2; attempts++) {
> + if (start_active_slot(slot)) {
> + run_active_slot(slot);
> + if (slot->results->curl_result == 
> CURLE_SSL_CONNECT_ERROR)
> + continue;
> + ret = handle_curl_result(slot);
> + } else {
> + error("Unable to start HTTP request for %s", url);
> + ret = HTTP_START_FAILED;
> + }
> + break;
>   }

Two naïve questions, that applies to this and the one in 
remote-curl.c::run_slot().

 (1) why only twice?
 (2) no need for "wait a bit and then retry"?

> diff --git a/remote-curl.c b/remote-curl.c
> index a269608..04a379c 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -353,6 +353,8 @@ static int run_slot(struct active_request_slot *slot)
>  
>   slot->results = &results;
>   slot->curl_result = curl_easy_perform(slot->curl);
> + if (slot->curl_result == CURLE_SSL_CONNECT_ERROR)
> + slot->curl_result = curl_easy_perform(slot->curl);
>   finish_active_slot(slot);
>  
>   err = handle_curl_result(slot);
--
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] Retry HTTP requests on SSL connect failures

[Shawn O. Pearce]

From: "Shawn O. Pearce" 

When libcurl fails to connect to an SSL server always retry the
request once. Since the connection failed before the HTTP headers
can be sent, no data has exchanged hands, so the remote side has
not learned of the request and will not perform it twice.

In the wild we have seen git-remote-https fail to connect to
some load-balanced SSL servers sporadically, while modern popular
browsers (e.g. Firefox and Chromium) have no trouble with the same
server pool.

Lets assume the site operators (Hi Google!) have a clue and are
doing everything they already can to ensure secure, successful
SSL connections from a wide range of HTTP clients. Implementing a
single level of retry in the client can make it more robust against
transient failure modes.
---
 http.c| 19 ---
 remote-curl.c |  2 ++
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/http.c b/http.c
index 345c171..953f2e6 100644
--- a/http.c
+++ b/http.c
@@ -784,7 +784,7 @@ static int http_request(const char *url, void *result, int 
target, int options)
struct slot_results results;
struct curl_slist *headers = NULL;
struct strbuf buf = STRBUF_INIT;
-   int ret;
+   int ret, attempts;
 
slot = get_active_slot();
slot->results = &results;
@@ -820,12 +820,17 @@ static int http_request(const char *url, void *result, 
int target, int options)
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "gzip");
 
-   if (start_active_slot(slot)) {
-   run_active_slot(slot);
-   ret = handle_curl_result(slot);
-   } else {
-   error("Unable to start HTTP request for %s", url);
-   ret = HTTP_START_FAILED;
+   for (attempts = 0; attempts < 2; attempts++) {
+   if (start_active_slot(slot)) {
+   run_active_slot(slot);
+   if (slot->results->curl_result == 
CURLE_SSL_CONNECT_ERROR)
+   continue;
+   ret = handle_curl_result(slot);
+   } else {
+   error("Unable to start HTTP request for %s", url);
+   ret = HTTP_START_FAILED;
+   }
+   break;
}
 
curl_slist_free_all(headers);
diff --git a/remote-curl.c b/remote-curl.c
index a269608..04a379c 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -353,6 +353,8 @@ static int run_slot(struct active_request_slot *slot)
 
slot->results = &results;
slot->curl_result = curl_easy_perform(slot->curl);
+   if (slot->curl_result == CURLE_SSL_CONNECT_ERROR)
+   slot->curl_result = curl_easy_perform(slot->curl);
finish_active_slot(slot);
 
err = handle_curl_result(slot);
-- 
1.7.12.1.590.g4bb1bc4

--
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: "submodule" mistake and a problem

[Howard Miller]

I was not aware of git subtree. I'll go and do some reading. Thanks
for the pointer!

On 1 October 2012 17:40, Jens Lehmann  wrote:
>
> Am 01.10.2012 14:05, schrieb Howard Miller:
> >>
> >> Perhaps:
> >>
> >>   git rm -f --cached path/to/subdir   # remove from index, keep files
> >>   git add path/to/subdir
> >>
> >> -- Hannes
> >
> > Fantastic worked perfectly.  I'll write that down somewhere for
> > the next time I do it :)
> >
> > Is there a better way of handling sub-modules like that? I've looked
> > at git submodules but just got into more of a mess. It would be nice
> > to push a project complete with a (git) submodule upstream but it
> > seems tricky or impossible.
>
> Git submodules are distinct repositories by design, so you'd have to
> create an upstream repository for the submodule too to make that work.
> But I have the impression that you want to import another repository
> into a directory of your repo, so maybe git subtree is what you want.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Junio C Hamano]

Simon Oosthoek  writes:

> It's possible to set PS1 to nothing and print a string from
> PROMPT_COMMAND, but then you miss out on all the features of the PS1
> interpretation by bash and compared to the use of __git_ps1 at the
> moment, it has to put out quite a different string. Because if you like
> to see user@host+workdir (git-status)[$#]
> the current users of __git_ps1 say PS1="\u@host+\w $(__git_ps1 "%s")\$
> ", but all __git+ps1 has to put out is "(branch)" or "(branch *)", etc.
>
> If it has to print the same prompt in PC mode, it has to add all the
> user/host/workdir/[$#] data as well, withouth being able to use the bash
> internal interpretation (because that is only working when PS1 is set).

The longer I read your explanation, the less useful the "PC mode"
sounds like, at least to me.  So why does an user even want to use
such a mechanism, instead of PS1?  And even if the user wants to use
it by doing \w, \u etc. himself, she can do that with

PROMPT_COMMAND='
PS1=$(printf "\u \h \w %s$ " $(__git_ps1 "%s"))
'

just fine, no?

So I still do not see the problem, even taking your "Set PS1 in the
command, without spitting anything out of the command" use case into
account.

Confused
--
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: Deletion of remote branches

[Junio C Hamano]

"Philip Oakley"  writes:

>> All of the above are expected and working as designed.  Remote
>> tracking branches are local _copies_ of what you have over there at
>> the remote repository. The latter is the authoritative version, and
>> you asked "ls-remote" to go over the network to view them.
>>
> Is there a definitive naming convention for the two types of 'remote 
> branch'?
>
> IIRC (somewhere) the 'tracking' term was to be deprecated, though it is 
> still in common use. It is usually only the context that clarifies if it 
> is the local or the distant copy/repo.

That is somewhat different from what I recall:

 - "refs/remotes/$there/$that" is a copy of $that branch at the
   remote $there; we call that a "remote tracking branch".

   When people say "remote branch", they often mean $that branch at
   the remote $there, not your local copy of it.

   When you say "remote tracking branch", you are talking about
   something you locally have to track the corresponding "remote
   branch".  This use is not deprecated at all.  That is the only
   sane way to clarify which one of the two you are talking about.

 - If your branch "foo" always integrates with branch "bar" at the
   remote "xyzzy", you would often run

git pull xyzzy bar
git pull --rebase xyzzy bar

   after running "git chekcout foo".  You may even have this in your
   per-repository configuration:

[branch "foo"]
remote = xyzzy
merge = refs/heads/bar

   In such a situation, some people (used to) say that "foo tracks
   bar from xyzzy".  While such a colloquial use is perfectly fine
   when it is clear that "foo" being discussed is your local branch,
   the verb "track" in that sentence is used to mean an entirely
   different kind of relationship between your "remotes/xyzzy/bar"
   and the branch "bar" at remote "xyzzy", where the former is the
   "remote tracking branch" for the latter, leading to confusion.
   This use of 'track' is what is discouraged these days.

I think we call the latter @{upstream} of "foo" these days.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 21:54, Junio C Hamano wrote:
> Now you lost me.  The documentation of PROMPT_COMMAND in "man bash"
> says this:
> 
>PROMPT_COMMAND
>   If set, the value is executed as a command prior to
>   issuing each primary prompt.
> 
> So yes, if you say "PROMPT_COMMAND='whatever'", you will get output
> from 'whatever' followed by what $PS1 would normally give you.  
> If you do not want to see PS1 after 'whatever' gives you, you have
> to set it to an empty string.
> 
> On the other hand, they way people have been using __git_ps1 is (as
> described in the prompt script) to do something like this:
> 
>   PS1='...cruft... $(__git_ps1 "%s") ...cruft...'
> 
> To keep supporting them, __git_ps1 has to be a function that writes
> the prompt string to its standard output.  The external interface of
> PROMPT_COMMAND also is that it wants a command that emits the string
> desired for the prompt to its standard output.  I do not see any
> "when it is used like this, X, but when it is used like that, Y"
> kind of issue around it, either.
> 
> So what is the problem
> 

Well, I hadn't thought about that way of using it. It works in a way...

But PS1 is set and interpreted in a special way by bash (I gather from
examples, I'm kind of confused by it).

It's possible to set PS1 to nothing and print a string from
PROMPT_COMMAND, but then you miss out on all the features of the PS1
interpretation by bash and compared to the use of __git_ps1 at the
moment, it has to put out quite a different string. Because if you like
to see user@host+workdir (git-status)[$#]
the current users of __git_ps1 say PS1="\u@host+\w $(__git_ps1 "%s")\$
", but all __git+ps1 has to put out is "(branch)" or "(branch *)", etc.

If it has to print the same prompt in PC mode, it has to add all the
user/host/workdir/[$#] data as well, withouth being able to use the bash
internal interpretation (because that is only working when PS1 is set).

The example(s) I found when googling for a solution were to set PS1
inside the PC function, in a way that it was possible to add color
encodings, without messing up the wrapping. This is _impossible_ using
command substitution, because then bash doesn't interpret the \[ and \]
around the color codes, and that messes up the accounting of how long
the prompt string is.

/Simon

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git pull --no-ff documentation

[Junio C Hamano]

"Philip Oakley"  writes:

>> This actually is not about --no-ff but about --no-tags.  Any option
>> that "pull" itself does not care about stops the command line parser
>> and the remainder of the command line is fed to underlying "fetch".
>>
>
> Should this be said within the documentation's synopsis ?
>
> e.g.
> git pull [pull_options] [merge_options] [fetch_options [
> […]]

We certainly could do that, but I was hoping somebody would
volunteer to make it easier to the end users so that they do not
have to remember which one is which.

The "perhaps something like this?" patch was a hint to show the
first step in that preferrable direction.

--
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: Deletion of remote branches

[Philip Oakley]

From: "Junio C Hamano" 

Jens Hausherr  writes:


I came across an issue with deleting remote branches: When deleting a
branch using "git branch ­r ­d " the branch is deleted and no
longer shown by "git branch ­r".

"git ls-remote --heads" on the other hand still lists the ref for the 
last

branch commit.

If I delete the branch using "git push origin :" the branch 
is

removed completely (i.e. git ls-remote  no longer returns a ref).


All of the above are expected and working as designed.  Remote
tracking branches are local _copies_ of what you have over there at
the remote repository. The latter is the authoritative version, and
you asked "ls-remote" to go over the network to view them.

Is there a definitive naming convention for the two types of 'remote 
branch'?


IIRC (somewhere) the 'tracking' term was to be deprecated, though it is 
still in common use. It is usually only the context that clarifies if it 
is the local or the distant copy/repo.


Distinct names make for less confusion.


If you are trying to remove the branches you show to others and
yourself who are observing that remote repository from your local
workstation, you can first "git push origin :" to remove it
in the remote repository. You can run your next fetch with "--prune"
to get rid of remotes/origin/, I think.



Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git pull --no-ff documentation

[Philip Oakley]

From: "Junio C Hamano" 

乙酸鋰  writes:


The order of options in git pull is not clear in the documentation
It only says
git pull [options] [ [...]]
So we have no idea which options should come first

I tried
git pull -v --no-tags --progress --no-ff origin
but failed with unknown option 'no-ff'.

But if I ran
git pull -v --no-ff  --no-tags --progress origin
it succeeded.


This actually is not about --no-ff but about --no-tags.  Any option
that "pull" itself does not care about stops the command line parser
and the remainder of the command line is fed to underlying "fetch".



Should this be said within the documentation's synopsis ?

e.g.
git pull [pull_options] [merge_options] [fetch_options [ 
[…]]



Perhaps something like this?  But you should trace the codepath
involved to see if this covers all uses of the --tags before using
it for real projects, as I didn't.

git-pull.sh | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)

diff --git i/git-pull.sh w/git-pull.sh
index 2a10047..a53c1e5 100755
--- i/git-pull.sh
+++ w/git-pull.sh
@@ -39,7 +39,7 @@ test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge

strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress= recurse_submodules= fetch_tags=
merge_args= edit=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
@@ -62,6 +62,8 @@ do
 progress=--no-progress ;;
 -n|--no-stat|--no-summary)
 diffstat=--no-stat ;;
+ -t|--t|--ta|--tag|--tags|--no-tags)
+ fetch_tags="$1" ;;
 --stat|--summary)
 diffstat=--stat ;;
 --log|--no-log)
@@ -141,15 +143,12 @@ done

error_on_no_merge_candidates () {
 exec >&2
- for opt
- do
- case "$opt" in
- -t|--t|--ta|--tag|--tags)
- echo "Fetching tags only, you probably meant:"
- echo "  git fetch --tags"
- exit 1
- esac
- done
+ case "$fetch_tags" in
+ -t|--t|--ta|--tag|--tags)
+ echo "Fetching tags only, you probably meant:"
+ echo "  git fetch --tags"
+ exit 1
+ esac

 if test true = "$rebase"
 then
@@ -213,7 +212,7 @@ test true = "$rebase" && {
 done
}
orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run 
$recurse_submodules --update-head-ok "$@" || exit 1
+git fetch $verbosity $progress $dry_run $recurse_submodules 
$fetch_tags --update-head-ok "$@" || exit 1

test -z "$dry_run" || exit 0

curr_head=$(git rev-parse -q --verify HEAD)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2441/5300 - Release Date: 
09/30/12




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Junio C Hamano]

Simon Oosthoek  writes:

> On 01/10/12 21:13, Junio C Hamano wrote:
>
>> Hrm, let me ask a stupid question.  Why do we even need __git_ps1_pc
>> in the first place?  Wouldn't it be just the matter of
>> 
>>  PROMPT_COMMAND='__git_ps1 "%s"'
>> 
>> once you have __git_ps1 that works?
>
> Apart from one small detail, PS1 must be set directly when __git_ps1 is
> called as a PROMPT_COMMAND, while in command substitution mode,
> __git_ps1 needs to put out a string value to substitute...

Now you lost me.  The documentation of PROMPT_COMMAND in "man bash"
says this:

   PROMPT_COMMAND
  If set, the value is executed as a command prior to
  issuing each primary prompt.

So yes, if you say "PROMPT_COMMAND='whatever'", you will get output
from 'whatever' followed by what $PS1 would normally give you.  
If you do not want to see PS1 after 'whatever' gives you, you have
to set it to an empty string.

On the other hand, they way people have been using __git_ps1 is (as
described in the prompt script) to do something like this:

PS1='...cruft... $(__git_ps1 "%s") ...cruft...'

To keep supporting them, __git_ps1 has to be a function that writes
the prompt string to its standard output.  The external interface of
PROMPT_COMMAND also is that it wants a command that emits the string
desired for the prompt to its standard output.  I do not see any
"when it is used like this, X, but when it is used like that, Y"
kind of issue around it, either.

So what is the problem
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 21:13, Junio C Hamano wrote:

> Hrm, let me ask a stupid question.  Why do we even need __git_ps1_pc
> in the first place?  Wouldn't it be just the matter of
> 
>   PROMPT_COMMAND='__git_ps1 "%s"'
> 
> once you have __git_ps1 that works?

Apart from one small detail, PS1 must be set directly when __git_ps1 is
called as a PROMPT_COMMAND, while in command substitution mode,
__git_ps1 needs to put out a string value to substitute...

This is the way it works now (I'll send the patch later this week, I
want to test it some more...)

/Simon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Remove the hard coded length limit on variable names in config files

[Junio C Hamano]

Ben Walton  writes:

> Previously while reading the variable names in config files, there was
> a 256 character limit with at most 128 of those characters being used
> by the section header portion of the variable name.  This limitation
> was only enforced while reading the config files.  It was possible to
> write a config file that was not subsequently readable.
>
> Instead of enforcing this limitation for both reading and writing,
> remove it entirely by changing the var member of the config_file
> struct to a strbuf instead of a fixed length buffer.  Update all of
> the parsing functions in config.c to use the strbuf instead of the
> static buffer.
>
> The parsing functions that returned the base length of the variable
> name now return simply 0 for success and -1 for failure.  The base
> length information is obtained through the strbuf's len member.
>
> We now send the buf member of the strbuf to external callback
> functions to preserve the external api.  None of the external callers
> rely on the old size limitation for sizing their own buffers so
> removing the limit should have no externally visible effect.
>
> Signed-off-by: Ben Walton 
> ---
>  config.c |   59 +--
>  1 file changed, 29 insertions(+), 30 deletions(-)

Makes sense, and I found the patch very readable.

Thanks, both.
--
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] submodule: make 'show' an alias for 'summary'

[Jens Lehmann]

Am 01.10.2012 19:33, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 01.10.2012 08:45, schrieb Ramkumar Ramachandra:
>>> Jens Lehmann wrote:
 I'm very interested in your feedback as a first time submodule user,
 what you wrote above makes sense and explains why you did that patch
 (and it would have been nice to read some of it in the commit message
 ;-). What information did you expect to get from a "git submodule
 show" which isn't already provided by "git status" and "git diff"
 (especially as they give you some information the "git submodule"
 commands don't)?
>>>
>>> I expected 'git submodule show' to list all the submodules, and show
>>> changes to specific submodules like the 'git submodule summary'
>>> output.
>>
>> Ok, but "git submodule summary" doesn't list all the submodules,
>> only those with changes. Maybe "git submodule status" is closer
>> to what you expect (except for the missing changes)?
> 
> Yes, "git submodule status" with "git submodule summary"-style change output.

So just aliasing "show" to "summary" would not have done the trick,
right? ;-)

>> And - apart from the list of all submodules - the changes to them
>> are given by "git status" and "git diff --submodule" too, right?
> 
> Oh, I didn't know about "git diff --submodule" at all.
> 
>> (sometimes I forget that "--submodule" is not enabled by default,
>> as I'm a heavy "git gui" user, and that option is used there. We
>> might need a config option to turn that on)
> 
> That's a good idea.  I'll write a patch tomorrow.

Cool! I suspect showing the difference in shortlog style is much
more useful than seeing the hashes.

>> Me too would expect a show command to show me a list of all the
>> submodules and maybe some extra information (is it populated or
>> not, does it have its .git directory embedded, does it contain
>> changes). So maybe "show" should be a slightly pimped "status"?
> 
> Sure.  Do we want to create a new subcommand though?  Aren't "status"
> and "summary" enough already?

Yes, I don't think we need a new command. Maybe someday we will
change "git submodule status" to contain less hash and maybe some
other infos, but we're not there yet.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Junio C Hamano]

Junio C Hamano  writes:

>> I agree that it's ugly. How about the following:
>>
>> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that
>> mode support color hints.
>>
>> This way there's one function, so no overlap.
>
> I think the logical progression would be
>
>  - there are parts of __git_ps1 you want to reuse for your
>__git_ps1_pc; separate that part out as a helper function,
>and make __git_ps1 call it, without changing what __git_ps1
>does (i.e. no colors, etc.)
>
>  - add __git_ps1_pc that uses the helper function you separated
>out.
>
>  - add whatever bells and whistles that are useful for users of
>either __git_ps1 or __git_ps1_pc to that helper function.

Hrm, let me ask a stupid question.  Why do we even need __git_ps1_pc
in the first place?  Wouldn't it be just the matter of

PROMPT_COMMAND='__git_ps1 "%s"'

once you have __git_ps1 that works?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 19:16, Junio C Hamano wrote:
> Simon Oosthoek  writes:
> 
>> On 09/28/2012 07:58 PM, Junio C Hamano wrote:
>>> Simon Oosthoek  writes:
>>>
 +# __git_ps1_pc accepts 0 arguments (for now)
 +# It is meant to be used as PROMPT_COMMAND, it sets PS1
 +__git_ps1_pc ()
 +{
 +  local g="$(__gitdir)"
 +  if [ -n "$g" ]; then
 +...
 +  fi
 +}
>>>
>>> This looks awfully similar to the existing code in __git_ps1
>>> function.  Without refactoring to share the logic between them, it
>>> won't be maintainable.
>>>
>>
>> I agree that it's ugly. How about the following:
>>
>> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that
>> mode support color hints.
>>
>> This way there's one function, so no overlap.
> 
> I think the logical progression would be
> 
>  - there are parts of __git_ps1 you want to reuse for your
>__git_ps1_pc; separate that part out as a helper function,
>and make __git_ps1 call it, without changing what __git_ps1
>does (i.e. no colors, etc.)
> 
>  - add __git_ps1_pc that uses the helper function you separated
>out.
> 
>  - add whatever bells and whistles that are useful for users of
>either __git_ps1 or __git_ps1_pc to that helper function.
> 
> 

Since this is the shell, it could turn out to be ugly this way:

function ps1_common {
set global variable (branchname, dirty state, untracked files,
divergence from upstream, etc.)
}

function __git_ps1 {
call ps1_common
print PS1 string based on format string or default (color in prompt
isn't an option) and include global variables where necessary
}

function __git_ps1_pc {
call ps1_common
set PS1=
based on hardcoded PS1 definition, expand the PS1 using global
variables (add color if requested)
}

The problem I see is that it would involve a lot of global variables
visible in the shell (OTOH, they could be used by other scripts, but
only when using this prompt ;-).
Or you could print a string, which can be caught in the relevant _ps1
function, but then this string needs to be chopped up and processed (by
a bunch of awk oneliners or bash-voodoo)

The latter introduces so much overhead (in processing and
maintainability) that I think it should not be considered.

That leaves passing the variables from one function to another using
globally scoped variables in the shell.

It can be done, but the current combined implementation has only the
global variables set by the user (GIT_PS1_SHOWDIRTYSTATE and so on) and
the rest remains local to the function.

The main obstacle to better code here is the need to work around the
shell's oddities. :-(

Cheers

Simon


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

"git am" crash (builtin/apply.c:2108) + small repro

[Alexey Spiridonov]

This reproduces in trunk, 1.7.8.4, and 1.7.9.5.

I suspect this has to do with a whitespace + no trailing newline
issues. The patch was generated by 1.7.9.5. I mangled it by hand to
get it to be small, but the initial crash happened on a large,
real-world output of "git format-patch".

Error messages:

~/GIT-AM-CRASH$ ../git/git am crashy.patch
Applying: Git crash bug
git: builtin/apply.c:2108: update_pre_post_images: Assertion
`fixed_preimage.nr == preimage->nr' failed.
/home/lesha/GIT-AM-CRASH/../git/git-am: line 811: 23819 Aborted
 git apply --index "$dotest/patch"
Patch failed at 0001 Git crash bug
The copy of the patch that failed is found in:
   /home/lesha/GIT-AM-CRASH/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Repro steps:

mkdir GIT-AM-CRASH
cd GIT-AM-CRASH
# download files into this directory
git init .
mkdir -p meep/spork
mv __init__.py meep/spork
git add meep/spork/__init__.py
git ci -am 'moo'
git am crashy.patch

Hope this helps!

Alexey


crashy.patch
Description: Binary data


__init__.py
Description: Binary data

Re: [PATCH 0/2] git-add: -s flag (silently ignore files)

[Junio C Hamano]

Olaf Klischat  writes:

> ... scenarios where you want to feed the file list into git add
> via find or other external commands (`find  | xargs git add'),
> which you wouldn't want to carefully tune...

Can you explain this kind of thing in the actual commit log message
when you reroll (if you will do so)?

I also cannot help but find that `scenario` an artificially made-up
one.  The description did not feel convincing enough, even if it
were in the proposed commit log message, to justify such an option.

A few questions.

 - What were the kind of patterns useful in the above `find` in your
   real life example?

 - The use of `find` means giving pathspecs from the command line,
   e.g. "git add foo/ \*.rb", wouldn't have been sufficient. Are
   there something we could improve this in more direct way?

 - Why was it too cumbersome to add the idiomatic

\( -name '*.o' -o -name '*~' \) -prune -o

   or something like that in front of whatever patterns were used?

 - Perhaps a filter that takes a list of paths and emits only the
   ignored paths (or only the unignored paths) would be a more
   generic approach?  You could feed the output from `find` to such
   a filter, and then drive not just "git add" but other commands
   that take paths if you solved it that way.

--
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: no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)

[Greg KH]

On Mon, Oct 01, 2012 at 06:03:47PM +, Arnd Bergmann wrote:
> On Monday 01 October 2012, Greg KH wrote:
> > Wait, what happened to the diffstat?  Does the latest version of git not
> > send out the diffstat for 'git request-pull'?  It used to on older
> > versions, I just updated the version on my machine that generated this
> > to
> > git version 1.7.12.2.421.g261b511
> > 
> > Do I have to give a new option to request-pull to have the diffstat show
> > up?  I'm using
> > git request-pull master 
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
> > char-misc-3.6
> > 
> > For this specific request pull.
> 
> It looks more like you just sent an empty pull request from v3.6-rc3 to 
> v3.6-rc3 (fea7a08acb135).

Ah crap, you are right, totally my fault.

I'll blame it on being Monday morning...

sorry for the noise...

greg k-h
--
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: no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)

[Arnd Bergmann]

On Monday 01 October 2012, Greg KH wrote:
> Wait, what happened to the diffstat?  Does the latest version of git not
> send out the diffstat for 'git request-pull'?  It used to on older
> versions, I just updated the version on my machine that generated this
> to
> git version 1.7.12.2.421.g261b511
> 
> Do I have to give a new option to request-pull to have the diffstat show
> up?  I'm using
> git request-pull master 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
> char-misc-3.6
> 
> For this specific request pull.

It looks more like you just sent an empty pull request from v3.6-rc3 to 
v3.6-rc3 (fea7a08acb135).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] git-add: -s flag added (silently ignore files)

[Matthieu Moy]

Junio C Hamano  writes:

>>  static struct option builtin_add_options[] = {
>>  OPT__DRY_RUN(&show_only, N_("dry run")),
>> @@ -329,6 +329,7 @@ static struct option builtin_add_options[] = {
>>  OPT_BOOLEAN( 0 , "refresh", &refresh_only, N_("don't add, only refresh 
>> the index")),
>>  OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, N_("just skip 
>> files which cannot be added because of errors")),
>>  OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, N_("check if - even 
>> missing - files are ignored in dry run")),
>> +OPT_BOOLEAN('s', "silent-ignores", &silent_ignores, N_("don't fail when 
>> ignored files are specified on the command line (ignore them silently)")),
>
> I'd prefer not to see a new option whose worth hasn't been proven in
> the field to squat on any short-and-sweet single letter option
> name and would suggest replacing that 's' with 0, at least for now.

Another option would be a -k (--keep-going) that would ignore the files,
but not silently. "git mv" has such an option already.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] git-add: -s flag added (silently ignore files)

[Junio C Hamano]

Olaf Klischat  writes:

> Signed-off-by: Olaf Klischat 
> ---

I am personally not sympathetic to the reasoning stated in the
proposed commit log message above your signed-off-by line; the
change is not justified at all.

But I'll comment on the code changes anyway.

>  builtin/add.c  |   14 +++---
>  t/t3700-add.sh |   17 -
>  2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index e664100..61bb9ce 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -313,7 +313,7 @@ static const char ignore_error[] =
>  N_("The following paths are ignored by one of your .gitignore files:\n");
>  
>  static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;
> -static int ignore_add_errors, addremove, intent_to_add, ignore_missing = 0;
> +static int ignore_add_errors, addremove, intent_to_add, ignore_missing, 
> silent_ignores = 0;
>  
>  static struct option builtin_add_options[] = {
>   OPT__DRY_RUN(&show_only, N_("dry run")),
> @@ -329,6 +329,7 @@ static struct option builtin_add_options[] = {
>   OPT_BOOLEAN( 0 , "refresh", &refresh_only, N_("don't add, only refresh 
> the index")),
>   OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, N_("just skip 
> files which cannot be added because of errors")),
>   OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, N_("check if - even 
> missing - files are ignored in dry run")),
> + OPT_BOOLEAN('s', "silent-ignores", &silent_ignores, N_("don't fail when 
> ignored files are specified on the command line (ignore them silently)")),

I'd prefer not to see a new option whose worth hasn't been proven in
the field to squat on any short-and-sweet single letter option
name and would suggest replacing that 's' with 0, at least for now.

> @@ -339,6 +340,11 @@ static int add_config(const char *var, const char 
> *value, void *cb)
>   ignore_add_errors = git_config_bool(var, value);
>   return 0;
>   }
> + if (!strcmp(var, "add.silentignores") ||
> + !strcmp(var, "add.silent-ignores")) {

The second variant is unwarranted.  We may have a variable or two
that are accepted with '-' or '_' in their names, but they are
backward compatibility measures, only to cover previous mistakes
that named them in these letters in the first place.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)

[Greg KH]

On Mon, Oct 01, 2012 at 10:54:33AM -0700, Greg KH wrote:
> The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
> 
>   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
> tags/char-misc-3.6
> 
> for you to fetch changes up to fea7a08acb13524b47711625eebea40a0ede69a0:
> 
>   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
> 
> 
> char/misc driver merge for 3.7-rc1
> 
> Here is the "big" char/misc driver tree update for the 3.7-rc1 merge
> window.
> 
> Nothing major, just a number of driver updates and fixes, all of which
> have been in the linux-next releases for a while now either in my tree,
> or in Andrew's (the lis3l driver changes came from his tree last week).
> 
> 


Wait, what happened to the diffstat?  Does the latest version of git not
send out the diffstat for 'git request-pull'?  It used to on older
versions, I just updated the version on my machine that generated this
to
git version 1.7.12.2.421.g261b511

Do I have to give a new option to request-pull to have the diffstat show
up?  I'm using
git request-pull master 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
char-misc-3.6

For this specific request pull.

greg k-h
--
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] submodule: make 'show' an alias for 'summary'

[Junio C Hamano]

Jens Lehmann  writes:

> Me too would expect a show command to show me a list of all the
> submodules and maybe some extra information (is it populated or
> not, does it have its .git directory embedded, does it contain
> changes). So maybe "show" should be a slightly pimped "status"?

What's the next inventive way somebody who did not read the
documentation will come up with to spell the subcommand known as
"status"?  "submodule list"?

Do we really want 47 different subcommands that give the same output
or slight variations thereof?
--
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] submodule: make 'show' an alias for 'summary'

[Ramkumar Ramachandra]

Hi Jens,

Jens Lehmann wrote:
> Am 01.10.2012 08:45, schrieb Ramkumar Ramachandra:
>> Jens Lehmann wrote:
>>> I'm very interested in your feedback as a first time submodule user,
>>> what you wrote above makes sense and explains why you did that patch
>>> (and it would have been nice to read some of it in the commit message
>>> ;-). What information did you expect to get from a "git submodule
>>> show" which isn't already provided by "git status" and "git diff"
>>> (especially as they give you some information the "git submodule"
>>> commands don't)?
>>
>> I expected 'git submodule show' to list all the submodules, and show
>> changes to specific submodules like the 'git submodule summary'
>> output.
>
> Ok, but "git submodule summary" doesn't list all the submodules,
> only those with changes. Maybe "git submodule status" is closer
> to what you expect (except for the missing changes)?

Yes, "git submodule status" with "git submodule summary"-style change output.

> And - apart from the list of all submodules - the changes to them
> are given by "git status" and "git diff --submodule" too, right?

Oh, I didn't know about "git diff --submodule" at all.

> (sometimes I forget that "--submodule" is not enabled by default,
> as I'm a heavy "git gui" user, and that option is used there. We
> might need a config option to turn that on)

That's a good idea.  I'll write a patch tomorrow.

> Me too would expect a show command to show me a list of all the
> submodules and maybe some extra information (is it populated or
> not, does it have its .git directory embedded, does it contain
> changes). So maybe "show" should be a slightly pimped "status"?

Sure.  Do we want to create a new subcommand though?  Aren't "status"
and "summary" enough already?

Ram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Add workaround for system where Shift-F5 mapped to Shift-XF86_Switch_VT_5

[Junio C Hamano]

Andrew Wong  writes:

> The same workaround was used for Shift-F4 in:
>   cea07cf8dc9b3677e0c50433c0d72bce83adbdc7
>
> Signed-off-by: Andrew Wong 
> ---
>  gitk-git/gitk | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..698b84a 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -2496,6 +2496,7 @@ proc makewindow {} {
>  bindkey f nextfile
>  bind .  updatecommits
>  bind .  reloadcommits
> +catch { bind .  reloadcommits }
>  bind .  showrefs
>  bind .  {newview 0}
>  catch { bind .  {newview 0} }

Wouldn't it make more sense to have a small helper function to wrap
binding both  and  to the same
thing and have F4 and F5 binding use that to avoid repetition?

--
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] submodule: make 'show' an alias for 'summary'

[Jens Lehmann]

Am 01.10.2012 08:45, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> I'm very interested in your feedback as a first time submodule user,
>> what you wrote above makes sense and explains why you did that patch
>> (and it would have been nice to read some of it in the commit message
>> ;-). What information did you expect to get from a "git submodule
>> show" which isn't already provided by "git status" and "git diff"
>> (especially as they give you some information the "git submodule"
>> commands don't)?
> 
> I expected 'git submodule show' to list all the submodules, and show
> changes to specific submodules like the 'git submodule summary'
> output.

Ok, but "git submodule summary" doesn't list all the submodules,
only those with changes. Maybe "git submodule status" is closer
to what you expect (except for the missing changes)?

And - apart from the list of all submodules - the changes to them
are given by "git status" and "git diff --submodule" too, right?
(sometimes I forget that "--submodule" is not enabled by default,
as I'm a heavy "git gui" user, and that option is used there. We
might need a config option to turn that on) Or is there something
you are missing from their output?

Me too would expect a show command to show me a list of all the
submodules and maybe some extra information (is it populated or
not, does it have its .git directory embedded, does it contain
changes). So maybe "show" should be a slightly pimped "status"?
--
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] more meaningful error message in gitk when git binary is not available

[Josef Assad]

On 10/01/2012 07:21 PM, Josef Assad wrote:
> On 10/01/2012 07:11 PM, Junio C Hamano wrote:
>> Josef Assad  writes:
>>
>>> Signed-off-by: Josef Assad 
>>> ---
>>>  gitk-git/gitk |6 ++
>>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> Thanks.
>>
>>> diff --git a/gitk-git/gitk b/gitk-git/gitk
>>> index d93bd99..7e2e0a7 100755
>>> --- a/gitk-git/gitk
>>> +++ b/gitk-git/gitk
>>> @@ -11680,6 +11680,12 @@ setui $uicolor
>>>
>>>  setoptions
>>>
>>> +# check that the git executables are available for use
>>> +if [catch {set gitexists [exec which git]}] {
>>> +show_error {} . [mc "Cannot find a suitable git executable."]
>>> +exit 1
>>> +}
>>> +
>>>  # check that we can find a .git directory somewhere...
>>>  if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
>>>  show_error {} . [mc "Cannot find a git repository here."]
>>
>> It is somewhat a stupid solution to add an extra fork that will only
>> waste cycles in the normal non-error case, especially when we
>> already have an error codepath that acts on lack of the "git"
>> command anyway, isn't it?
> 
> I don't think it's actually _stupid_, but I also think your solution
> works better if you're trying to avoid one more exec call.
> 
> Mine has one less level of indentation though, and it has clearer
> delineation between checking for and handling two distinct error
> conditions. :)
> 
>> The "rev-parse" you see in the post-context will fail when we are
>> not in a git repository, but it will also fail when we do not have
>> git.
>>
>> You can add the new check to if {[catch {... git rev-parse }]} block;
>> before unconditionally saying "cannot find a git repo", you check if
>> "git" even exists, and give an appropriate error message.  That way,
>> you do not punish normal use case with an extra useless fork.
>>
>> Something like this, I presume.
>>
>>
>>  gitk | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/gitk b/gitk
>> index d93bd99..60794a7 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -11682,7 +11682,12 @@ setoptions
>>  
>>  # check that we can find a .git directory somewhere...
>>  if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
>> -show_error {} . [mc "Cannot find a git repository here."]
>> +# we could have failed because there is no git to begin with
>> +if {[catch {exec git version}]} {
>> +show_error {} . [mc "You do not seem to have 'git' command."]
>> +} else {
>> +show_error {} . [mc "Cannot find a git repository here."]
>> +}
>>  exit 1
>>  }
> 
> I'm neutral though and not married to my patch in any way, just trying
> to be helpful. In my opinon, yours is cleaner, mine is a tiny bit more
> readable in a file already closing on 12k lines.
> 

Bah, forgot to Cc list. My bad.
--
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] submodule: use abbreviated sha1 in 'status' output

[Jens Lehmann]

Am 01.10.2012 08:42, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> That is just a single user so far indicating your patch /could/ be an
>> improvement. I think we need quite some more votes on that before we
>> should do a change like this.
> 
> I thought it's a porcelain command like 'git status'- we don't need
> votes to change the output format of 'git status', do we?

Sure, we are free to change porcelain output. But that doesn't mean
we shouldn't have a good reason to do so, no? And I'm not sure yet
that it's worth risking to break scripts and user expectations.

And Marc's comment also implies that the status command might not
be heavily used (surely I never use it), so maybe we are just
wasting our time here trying to improve it. And if real users show
interest in shortening the hashes, I won't object that change.
--
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: Deletion of remote branches

[Junio C Hamano]

Jens Hausherr  writes:

> I came across an issue with deleting remote branches: When deleting a
> branch using "git branch ­r ­d " the branch is deleted and no
> longer shown by "git branch ­r".
>
> "git ls-remote --heads" on the other hand still lists the ref for the last
> branch commit.
>
> If I delete the branch using "git push origin :" the branch is
> removed completely (i.e. git ls-remote  no longer returns a ref).

All of the above are expected and working as designed.  Remote
tracking branches are local _copies_ of what you have over there at
the remote repository. The latter is the authoritative version, and
you asked "ls-remote" to go over the network to view them.

If you are trying to remove the branches you show to others and
yourself who are observing that remote repository from your local
workstation, you can first "git push origin :" to remove it
in the remote repository. You can run your next fetch with "--prune"
to get rid of remotes/origin/, I think.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Junio C Hamano]

Simon Oosthoek  writes:

> On 09/28/2012 07:58 PM, Junio C Hamano wrote:
>> Simon Oosthoek  writes:
>>
>>> +# __git_ps1_pc accepts 0 arguments (for now)
>>> +# It is meant to be used as PROMPT_COMMAND, it sets PS1
>>> +__git_ps1_pc ()
>>> +{
>>> +   local g="$(__gitdir)"
>>> +   if [ -n "$g" ]; then
>>> +...
>>> +   fi
>>> +}
>>
>> This looks awfully similar to the existing code in __git_ps1
>> function.  Without refactoring to share the logic between them, it
>> won't be maintainable.
>>
>
> I agree that it's ugly. How about the following:
>
> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that
> mode support color hints.
>
> This way there's one function, so no overlap.

I think the logical progression would be

 - there are parts of __git_ps1 you want to reuse for your
   __git_ps1_pc; separate that part out as a helper function,
   and make __git_ps1 call it, without changing what __git_ps1
   does (i.e. no colors, etc.)

 - add __git_ps1_pc that uses the helper function you separated
   out.

 - add whatever bells and whistles that are useful for users of
   either __git_ps1 or __git_ps1_pc to that helper function.

--
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] more meaningful error message in gitk when git binary is not available

[Junio C Hamano]

Josef Assad  writes:

> Signed-off-by: Josef Assad 
> ---
>  gitk-git/gitk |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)

Thanks.

> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..7e2e0a7 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -11680,6 +11680,12 @@ setui $uicolor
>
>  setoptions
>
> +# check that the git executables are available for use
> +if [catch {set gitexists [exec which git]}] {
> +show_error {} . [mc "Cannot find a suitable git executable."]
> +exit 1
> +}
> +
>  # check that we can find a .git directory somewhere...
>  if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
>  show_error {} . [mc "Cannot find a git repository here."]

It is somewhat a stupid solution to add an extra fork that will only
waste cycles in the normal non-error case, especially when we
already have an error codepath that acts on lack of the "git"
command anyway, isn't it?

The "rev-parse" you see in the post-context will fail when we are
not in a git repository, but it will also fail when we do not have
git.

You can add the new check to if {[catch {... git rev-parse }]} block;
before unconditionally saying "cannot find a git repo", you check if
"git" even exists, and give an appropriate error message.  That way,
you do not punish normal use case with an extra useless fork.

Something like this, I presume.


 gitk | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index d93bd99..60794a7 100755
--- a/gitk
+++ b/gitk
@@ -11682,7 +11682,12 @@ setoptions
 
 # check that we can find a .git directory somewhere...
 if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
-show_error {} . [mc "Cannot find a git repository here."]
+# we could have failed because there is no git to begin with
+if {[catch {exec git version}]} {
+show_error {} . [mc "You do not seem to have 'git' command."]
+} else {
+show_error {} . [mc "Cannot find a git repository here."]
+}
 exit 1
 }
 

--
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: "submodule" mistake and a problem

[Jens Lehmann]

Am 01.10.2012 14:05, schrieb Howard Miller:
>>
>> Perhaps:
>>
>>   git rm -f --cached path/to/subdir   # remove from index, keep files
>>   git add path/to/subdir
>>
>> -- Hannes
> 
> Fantastic worked perfectly.  I'll write that down somewhere for
> the next time I do it :)
> 
> Is there a better way of handling sub-modules like that? I've looked
> at git submodules but just got into more of a mess. It would be nice
> to push a project complete with a (git) submodule upstream but it
> seems tricky or impossible.

Git submodules are distinct repositories by design, so you'd have to
create an upstream repository for the submodule too to make that work.
But I have the impression that you want to import another repository
into a directory of your repo, so maybe git subtree is what you want.
--
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: Test failure: Test #3 in t1304-default-acl

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Hi Junio,
>
> Junio C Hamano wrote:
>> Matthieu Moy  writes:
>>
>>> Junio C Hamano  writes:
>>>
 I haven't been paying attention, but does that mean on that system,
 a total stranger kseygold can write, modify, and remove whatever Ram
 owns?  I am hoping that is not the case.
>>>
>>> I can see two reasons for having the same UID for two login names:
>>>
>>> 1) the sysadmin really messed up, and as you say, a total stranger has
>>> complete ownership of your files. Ramkumar, you should check that this
>>> is not your case.
>>>
>>> 2) the sysadmin explicitely gave two login names to the same physical
>>> person, as kinds of aliases for the same UID (e.g. the person got
>>> married, changed her name and login, but expects ~oldlogin to continue
>>> working). I'm not sure how common this is, and to which extend we want
>>> to support this in our test scripts.
>>
>> I've only been assuming (1), but (2) feels like a legitimate (if
>> confusing) way to configure your system.
>>
>> It is a separate issue if it is worth bending backwards to support
>> it in the test, though.
>
> For what it's worth, `sudo` is "broken" on my system.

Not very surprised ;-)
--
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] gitk: Add workaround for system where Shift-F5 mapped to Shift-XF86_Switch_VT_5

[Andrew Wong]

The same workaround was used for Shift-F4 in:
  cea07cf8dc9b3677e0c50433c0d72bce83adbdc7

Signed-off-by: Andrew Wong 
---
 gitk-git/gitk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..698b84a 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2496,6 +2496,7 @@ proc makewindow {} {
 bindkey f nextfile
 bind .  updatecommits
 bind .  reloadcommits
+catch { bind .  reloadcommits }
 bind .  showrefs
 bind .  {newview 0}
 catch { bind .  {newview 0} }
-- 
1.7.12.1.382.gb0576a6

--
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: gitk: can't reload commits with new key binding

[Andrew Wong]

Sorry, my previous "git send-email" screwed up. Resending the email again.

I was running into the same issue too. It turns out that on some machines
Shift-F5 is mapped to Shift-XF86_Switch_VT_5. My patch includes a workaround.
The same workaround was used for Shift-F4.

Andrew Wong (1):
  gitk: Add workaround for system where Shift-F5 mapped to
Shift-XF86_Switch_VT_5

 gitk-git/gitk | 1 +
 1 file changed, 1 insertion(+)

-- 
1.7.12.1.382.gb0576a6

--
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] gitk: Add workaround for system where Shift-F5 mapped to Shift-XF86_Switch_VT_5

[Andrew Wong]

The same workaround was used for Shift-F4 in:
  cea07cf8dc9b3677e0c50433c0d72bce83adbdc7

Signed-off-by: Andrew Wong 
---
 gitk-git/gitk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..698b84a 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2496,6 +2496,7 @@ proc makewindow {} {
 bindkey f nextfile
 bind .  updatecommits
 bind .  reloadcommits
+catch { bind .  reloadcommits }
 bind .  showrefs
 bind .  {newview 0}
 catch { bind .  {newview 0} }
-- 
1.7.12.1.382.gb0576a6

--
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] gitk: Add workaround for system where Shift-F5 mapped to Shift-XF86_Switch_VT_5

[Andrew Wong]

I was running into the same issue too. It turns out that on some machines
Shift-F5 is mapped to Shift-XF86_Switch_VT_5. My patch includes a workaround.
The same workaround was used for Shift-F4.

Andrew Wong (1):
  gitk: Add workaround for system where Shift-F5 mapped to
Shift-XF86_Switch_VT_5

 gitk-git/gitk | 1 +
 1 file changed, 1 insertion(+)

-- 
1.7.12.1.382.gb0576a6

--
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] more meaningful error message in gitk when git binary is not available

[Joachim Schmitz]

Josef Assad wrote:

Hi. I ran across what is a decidedly trivial little issue in gitk. The
TCL/Tk looked simple enough so I am giving you a patch anyhow in case
you want to fix it.

When for whatever reason the git binary is unavailable, gitk would
complain about missing git repository instead, so this patch adds a
check for git binary availability.

In case anyone is curious, I found this issue here:

http://stackoverflow.com/q/11967110/53936



Signed-off-by: Josef Assad 
---
gitk-git/gitk |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..7e2e0a7 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -11680,6 +11680,12 @@ setui $uicolor

setoptions

+# check that the git executables are available for use
+if [catch {set gitexists [exec which git]}] {


I believe 'which' is not portable, you could use 'type' instead.


+show_error {} . [mc "Cannot find a suitable git executable."]
+exit 1
+}
+
# check that we can find a .git directory somewhere...
if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
show_error {} . [mc "Cannot find a git repository here."]


--
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: mailinfo: don't require "text" mime type for attachments

[Don Zickus]

On Sun, Sep 30, 2012 at 03:10:48PM -0700, Linus Torvalds wrote:
> This code goes all the way back to March of 2007, in commit 87ab79923463 
> ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to 
> pass random mbox contents to git. However, the pre-decode vs post-decode 
> logic really shouldn't matter even for that case, and more importantly, "I 
> fed git am crap" is not a valid reason to break *real* patch attachments.
> 
> If somebody really cares, and determines that some attachment is binary 
> data (by looking at the data, not the MIME-type), the whole attachment 
> should be dismissed, rather than fed in random-sized chunks to 
> "handle_filter()".

Heh.  Years ago when I tried using git as a patch-control-management
system instead of a traditional SCM,  I fed my custom git-am script an
internal kernel-mail-archives list to help process the meta data for
patches (acks, nacks, needinfo, bugzillas, etc).  It served its purpose
until we switched to a fork'd copy of patch-work.

So I haven't done 'insane' stuff in years.  :-)  I'm sure this patch is
right, but it doesn't affect me anymore.

Sorry for any problems that arose..

Cheers,
Don
--
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

Deletion of remote branches

[Jens Hausherr]

Hi,

I came across an issue with deleting remote branches: When deleting a
branch using "git branch ­r ­d " the branch is deleted and no
longer shown by "git branch ­r".

"git ls-remote --heads" on the other hand still lists the ref for the last
branch commit.

If I delete the branch using "git push origin :" the branch is
removed completely (i.e. git ls-remote  no longer returns a ref).

Is this a bug or is this behavior intentional? (I am currently using git
1.7.12).

Cheers,
Jens

-- 
Jens Hausherr
Senior Software Engineer QA
jens.haush...@xing.com
 
XING AG
Gaensemarkt 43, 20354 Hamburg, Germany

Tel. +49 40 419131-634, Fax +49 40 419131-11
 

Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 98807
Exec. Board (Vorstand): Dr. Stefan Groß-Selbeck (Vorsitzender), Dr. Thomas
Vollmoeller, Ingo Chu, Dr. Helmut Becker, Jens Pape
Chairman of the Supervisory Board (Aufsichtsratsvorsitzender): Dr. Neil
Sunderland
 

Please join my network on XING


This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden and may be unlawful.




--
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: "submodule" mistake and a problem

[Howard Miller]

>
> Perhaps:
>
>   git rm -f --cached path/to/subdir   # remove from index, keep files
>   git add path/to/subdir
>
> -- Hannes

Fantastic worked perfectly.  I'll write that down somewhere for
the next time I do it :)

Is there a better way of handling sub-modules like that? I've looked
at git submodules but just got into more of a mess. It would be nice
to push a project complete with a (git) submodule upstream but it
seems tricky or impossible.

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: "submodule" mistake and a problem

[Johannes Sixt]

Am 10/1/2012 12:41, schrieb Howard Miller:
> - I have an existing (long standing) project in git with an upstream in github
> - I added a subdirectory which I had forgotten was itself a git
> project (i.e. it has its own .git directory)
> - I committed the subdirectory (git add /path/to/subdir;  git commit -m )
> - I pushed the latest version upstream
> 
> .at this point I realised that only the directory name had been pushed. 
> SO...
> 
> - git rm /path/to/subdir resulted in fatal: pathspec
> '/path/to/subdir/' did not match any files
> - so I deleted it manually, re-copied the directory and removed its
> ..git directory
> 
> I now cannot add or commit the directory. Git just ignores it. I
> have grepped and searched and kind find no reference to this directory
> anywhere. I am completely stumped.
> 
> Can anybody help? I don't want this to be a git subdirectory, I just
> want to be able to add the files (without the .git directory)

Perhaps:

  git rm -f --cached path/to/subdir   # remove from index, keep files
  git add path/to/subdir

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

"submodule" mistake and a problem

[Howard Miller]

Hi,

I did this and now am confused/stuck...

- I have an existing (long standing) project in git with an upstream in github
- I added a subdirectory which I had forgotten was itself a git
project (i.e. it has its own .git directory)
- I committed the subdirectory (git add /path/to/subdir;  git commit -m )
- I pushed the latest version upstream

at this point I realised that only the directory name had been pushed. SO...

- git rm /path/to/subdir resulted in fatal: pathspec
'/path/to/subdir/' did not match any files
- so I deleted it manually, re-copied the directory and removed its
.git directory

...I now cannot add or commit the directory. Git just ignores it. I
have grepped and searched and kind find no reference to this directory
anywhere. I am completely stumped.

Can anybody help? I don't want this to be a git subdirectory, I just
want to be able to add the files (without the .git directory)

Cheers :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 09/28/2012 07:58 PM, Junio C Hamano wrote:

Simon Oosthoek  writes:


+# __git_ps1_pc accepts 0 arguments (for now)
+# It is meant to be used as PROMPT_COMMAND, it sets PS1
+__git_ps1_pc ()
+{
+   local g="$(__gitdir)"
+   if [ -n "$g" ]; then
+...
+   fi
+}


This looks awfully similar to the existing code in __git_ps1
function.  Without refactoring to share the logic between them, it
won't be maintainable.



I agree that it's ugly. How about the following:

I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that 
mode support color hints.


This way there's one function, so no overlap.

Shall I send patches for the two changes separately (to support 
PROMPT_COMMAND mode and another to support color hints) or in one?


And what about zsh support? I doubt the PROMPT_COMMAND thing is 
compatible with zsh, but the command substitution mode should probably 
work, unless it is already broken by the use of % to indicate untracked 
files (when GIT_PS1_SHOWUNTRACKEDFILES is set). Unless it is tested 
further in zsh, I'd say it might be better not to claim zsh is supported.


Cheers

Simon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] gitk: clicking on a connecting line produces can't read "cflist_top"

[Johannes Sixt]

Clicking on a line that connects commit nodes produces this error:

can't read "cflist_top": no such variable
can't read "cflist_top": no such variable
while executing
"$cflist tag remove highlight $cflist_top.0 "$cflist_top.0 lineend""
(procedure "highlightfile" line 4)
invoked from within
"highlightfile 0"
(procedure "highlightfile_for_scrollpos" line 8)
invoked from within
"highlightfile_for_scrollpos $topidx"
(procedure "scrolltext" line 9)
invoked from within
"scrolltext 0.0 1.0"
(vertical scrolling command executed by text)


Bisection points to b967135d (Synchronize highlighting in file view when
scrolling diff).

gitk remains responsive after the error window is closed, so it is not
urgent. A fix would be appreciated nevertheless.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Test failure: Test #3 in t1304-default-acl

[Joachim Schmitz]

Ramkumar Ramachandra wrote:

Hi Junio,

Junio C Hamano wrote:

Matthieu Moy  writes:


Junio C Hamano  writes:


I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever
Ram owns?  I am hoping that is not the case.


I can see two reasons for having the same UID for two login names:

1) the sysadmin really messed up, and as you say, a total stranger
has complete ownership of your files. Ramkumar, you should check
that this is not your case.

2) the sysadmin explicitely gave two login names to the same
physical person, as kinds of aliases for the same UID (e.g. the
person got married, changed her name and login, but expects
~oldlogin to continue working). I'm not sure how common this is,
and to which extend we want to support this in our test scripts.


I've only been assuming (1), but (2) feels like a legitimate (if
confusing) way to configure your system.

It is a separate issue if it is worth bending backwards to support
it in the test, though.


For what it's worth, `sudo` is "broken" on my system.


sudo can't deal properly with multiple users sharing a UID, as it uses 
getpwuid(getuid()) in places.
On my system I've replaced that with getgwnam(getlogin()). which seems to 
work fine here.


Bye, Jojo 



--
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: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi Junio,

Junio C Hamano wrote:
> Matthieu Moy  writes:
>
>> Junio C Hamano  writes:
>>
>>> I haven't been paying attention, but does that mean on that system,
>>> a total stranger kseygold can write, modify, and remove whatever Ram
>>> owns?  I am hoping that is not the case.
>>
>> I can see two reasons for having the same UID for two login names:
>>
>> 1) the sysadmin really messed up, and as you say, a total stranger has
>> complete ownership of your files. Ramkumar, you should check that this
>> is not your case.
>>
>> 2) the sysadmin explicitely gave two login names to the same physical
>> person, as kinds of aliases for the same UID (e.g. the person got
>> married, changed her name and login, but expects ~oldlogin to continue
>> working). I'm not sure how common this is, and to which extend we want
>> to support this in our test scripts.
>
> I've only been assuming (1), but (2) feels like a legitimate (if
> confusing) way to configure your system.
>
> It is a separate issue if it is worth bending backwards to support
> it in the test, though.

For what it's worth, `sudo` is "broken" on my system.

Ram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] more meaningful error message in gitk when git binary is not available

[Josef Assad]

Hi. I ran across what is a decidedly trivial little issue in gitk. The
TCL/Tk looked simple enough so I am giving you a patch anyhow in case
you want to fix it.

When for whatever reason the git binary is unavailable, gitk would
complain about missing git repository instead, so this patch adds a
check for git binary availability.

In case anyone is curious, I found this issue here:

http://stackoverflow.com/q/11967110/53936



Signed-off-by: Josef Assad 
---
 gitk-git/gitk |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..7e2e0a7 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -11680,6 +11680,12 @@ setui $uicolor

 setoptions

+# check that the git executables are available for use
+if [catch {set gitexists [exec which git]}] {
+show_error {} . [mc "Cannot find a suitable git executable."]
+exit 1
+}
+
 # check that we can find a .git directory somewhere...
 if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
 show_error {} . [mc "Cannot find a git repository here."]
-- 
1.7.5.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/2] git-add: -s flag added (silently ignore files)

[Olaf Klischat]

Signed-off-by: Olaf Klischat 
---
 builtin/add.c  |   14 +++---
 t/t3700-add.sh |   17 -
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index e664100..61bb9ce 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -313,7 +313,7 @@ static const char ignore_error[] =
 N_("The following paths are ignored by one of your .gitignore files:\n");
 
 static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;
-static int ignore_add_errors, addremove, intent_to_add, ignore_missing = 0;
+static int ignore_add_errors, addremove, intent_to_add, ignore_missing, 
silent_ignores = 0;
 
 static struct option builtin_add_options[] = {
OPT__DRY_RUN(&show_only, N_("dry run")),
@@ -329,6 +329,7 @@ static struct option builtin_add_options[] = {
OPT_BOOLEAN( 0 , "refresh", &refresh_only, N_("don't add, only refresh 
the index")),
OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, N_("just skip 
files which cannot be added because of errors")),
OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, N_("check if - even 
missing - files are ignored in dry run")),
+   OPT_BOOLEAN('s', "silent-ignores", &silent_ignores, N_("don't fail when 
ignored files are specified on the command line (ignore them silently)")),
OPT_END(),
 };
 
@@ -339,6 +340,11 @@ static int add_config(const char *var, const char *value, 
void *cb)
ignore_add_errors = git_config_bool(var, value);
return 0;
}
+   if (!strcmp(var, "add.silentignores") ||
+   !strcmp(var, "add.silent-ignores")) {
+   silent_ignores = git_config_bool(var, value);
+   return 0;
+   }
return git_default_config(var, value, cb);
 }
 
@@ -346,11 +352,11 @@ static int add_files(struct dir_struct *dir, int flags)
 {
int i, exit_status = 0;
 
-   if (dir->ignored_nr) {
+   if (dir->ignored_nr && !silent_ignores) {
fprintf(stderr, _(ignore_error));
for (i = 0; i < dir->ignored_nr; i++)
fprintf(stderr, "%s\n", dir->ignored[i]->name);
-   fprintf(stderr, _("Use -f if you really want to add them.\n"));
+   fprintf(stderr, _("Use -f if you really want to add them, or -s 
to ignore them silently.\n"));
die(_("no files added"));
}
 
@@ -390,6 +396,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 
if (addremove && take_worktree_changes)
die(_("-A and -u are mutually incompatible"));
+   if (ignored_too && silent_ignores)
+   die(_("-f and -s are mutually incompatible"));
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with 
--dry-run"));
if ((addremove || take_worktree_changes) && !argc) {
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 874b3a6..1e17ae2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -294,7 +294,7 @@ test_expect_success 'git add --dry-run of an existing file 
output' "
 cat >expect.err <<\EOF
 The following paths are ignored by one of your .gitignore files:
 ignored-file
-Use -f if you really want to add them.
+Use -f if you really want to add them, or -s to ignore them silently.
 fatal: no files added
 EOF
 cat >expect.out <<\EOF
@@ -310,4 +310,19 @@ test_expect_success 'git add --dry-run --ignore-missing of 
non-existing file out
test_i18ncmp expect.err actual.err
 '
 
+cat >expect.err <<\EOF
+EOF
+cat >expect.out <<\EOF
+add 'track-this'
+EOF
+
+test_expect_success 'git add --dry-run --silent-ignore --ignore-missing of 
non-existing file' '
+   git add --dry-run --silent-ignore --ignore-missing track-this 
ignored-file >actual.out 2>actual.err
+'
+
+test_expect_success 'git add --dry-run --silent-ignore --ignore-missing of 
non-existing file output' '
+   test_i18ncmp expect.out actual.out &&
+   test_i18ncmp expect.err actual.err
+'
+
 test_done
-- 
1.7.10.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/2] git-add: -s flag: documentation added

[Olaf Klischat]

Signed-off-by: Olaf Klischat 
---
 Documentation/git-add.txt |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..a5a1cd1 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -38,10 +38,12 @@ files have changes that are staged for the next commit.
 
 The `git add` command will not add ignored files by default.  If any
 ignored files were explicitly specified on the command line, `git add`
-will fail with a list of ignored files.  Ignored files reached by
-directory recursion or filename globbing performed by Git (quote your
-globs before the shell) will be silently ignored.  The 'git add' command can
-be used to add ignored files with the `-f` (force) option.
+will fail with a list of ignored files unless the `-s` (silent-ignore)
+option was given.  Ignored files reached by directory recursion or
+filename globbing performed by Git (quote your globs before the shell)
+will always be silently ignored.  The 'git add' command can be used to
+add ignored files with the `-f` (force) option (which is mutually
+exclusive with `-s`).
 
 Please see linkgit:git-commit[1] for alternative ways to add content to a
 commit.
@@ -69,6 +71,11 @@ OPTIONS
 --force::
Allow adding otherwise ignored files.
 
+-s::
+--silent-ignore::
+   Don't fail if ignored files were specified explicitly; ignore them
+   silently and continue.
+
 -i::
 --interactive::
Add modified contents in the working tree interactively to
-- 
1.7.10.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/2] git-add: -s flag (silently ignore files)

[Olaf Klischat]

This adds an -s|--silent-ignore option to git-add, which causes
ignored files that were specified explicitly on the command line to be
silently ignored, rather than abandoning the command. I found this
useful for scenarios where you want to feed the file list into git add
via find or other external commands (`find  | xargs git add'),
which you wouldn't want to carefully tune so they don't output any
ignored files. git ls-files doesn't have find's filtering
capabilities, and using it in place of find would kind of violate "one
job one tool" anyway. I'm not really a git guru, so maybe I'm missing
something, and I'm unsure how useful this new option is for a general
audience. OTOH the patch is trivial. Check it out.

The update applies on top of "master" (261b5119).

Olaf Klischat (2):
  git-add: -s flag added (silently ignore files)
  git-add: -s flag: documentation added

 Documentation/git-add.txt |   15 +++
 builtin/add.c |   14 +++---
 t/t3700-add.sh|   17 -
 3 files changed, 38 insertions(+), 8 deletions(-)

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